 |
1
trepwq Aug 8, 2018 via iPhone
client-1 会丢弃 vps2 的 tcp 数据包的吧
|
 |
3
mt7620 Aug 8, 2018 via Android
prerouting 做 DNAT 试试
|
|
4
mt7620 Aug 8, 2018 via Android
VPS1 上开来一个
iptables -t nat -A PREROUTING -p tcp --dport 12306 -j DNAT --to-destination 222.222.222.222:12315 |
 |
5
oott123 Aug 8, 2018 via Android
听说很多机房防火墙会丢掉 src 不对的包。
|
 |
6
dorothyREN Aug 8, 2018
这。。。随便写个转发就行了吧
|
 |
7
ThirdFlame Aug 8, 2018
这不就是 目的地址转换么？
|
 |
9
ivyliner Aug 8, 2018
如果 VPS_2 可以直接访问 Client 的话, 可以直接添加路由表就好了.
|
 |
10
ShadowStar Aug 8, 2018
和 TCP/UDP 无关，和什么机房的防火墙也无关。
对于 Client 来说，发送的五元组信息是 Client_1:Rand_Port -> VPS_1:Port_A，接收到的五元组信息是 VPS_2:Port_B -> Client_1:Rand_Port，socket 根本对不上。 |
 |
11
LGA1150 Aug 8, 2018 via Android
|
 |
12
yingtl OP @ShadowStar UDP 监听的话就不用在乎这个了
|
 |
13
Austing Aug 9, 2018  1
@ShadowStar
@yingtl 和发送回复对不对的上以及 UDP 无关. 了解一下 BCP 38/RFC 2827. 如果 VPS_A 直接 DNAT 到 VPS_B 不不改变 SRC, 那么理论上就是伪造发送源进行 IP 欺骗, 99% 的 VPS 都不可能没开启 uRPF 和 ACL 来防止伪造的. 并且很多不是自有 transit 的服务商在其上游就已经被开启了 uRPF, 你可以直接在 VPS_A 尝试用 client 或其他任意 IP 直接向 B/其他服务器发包看一下, 然后接受 server tcpdump 抓包一下, 我相信对面是根本收不到的. |
|
14
Austing Aug 9, 2018 1
如果你想做到不改变发送源, 那你可以在 VPS_A 和 VPS_B 之间另外建立一条隧道来实现.
纯公网基本不太可能, 如果你不缺钱, 那你可以找没有开 uRPF 的机房或者自己买条 transit 做 bgp 吧 :) |
|
15
ShadowStar Aug 9, 2018
@yingtl 胡扯，你以为 UDP 就不需要 IP 了？
|
|
16
ShadowStar Aug 9, 2018
@Austing 你说的这些都是外围的安全防护措施，当然可以有各种的方式。
我说的是最基础的 TCP/IP 通信基础，在什么防护措施都没有的情况下，本身就无法双向通信。 |
|
17
Austing Aug 9, 2018
@ShadowStar 双向无法通信的前提是, 只是在客户端不进行任何操作的前提下, 当然无法通信, 你大可客户端 hook 再进行一次包修改.
没有任何问题, 而且使用情况也很多, 各大云的 LB 几乎全是如此. |
|
20
Austing Aug 9, 2018 2
@yingtl 一般来讲是不行的, 因为一般 VPS 服务商是在宿主机就过滤, 现在 VPS 商家常用的 solusvm openstack 之类的默认防止欺骗什么的都是最基本的- -
如果它是租用的其他服务商的服务器, 那么他的上游服务商很可能也会有过滤. 所以很多时候可能会有很多层的... 不过你可以自己试试啊, 随便用 hping 什么的发包然后抓包看看, 能收到就是能发呗. 但是你要是同机房同网络的话, IPIP 隧道正常应该也没多少性能衰减吧. |
|
22
ShadowStar Aug 9, 2018
@Austing 再 Hook 修改一次？
按照题主的描述，Client_1 是如何得知自己访问 VPS_1:PORT_A 的链接实际访问的是 VPS_2:PORT_B 的呢？ Client_1 只是看到了一个 VPS_2:PORT_B 访问自己的报文，凭什么修改啊？ VPS_2 也无法得知 Client_1 的报文是从 VPS_1:PORT_A 修改过的啊。 VPS_2 也只是看到了 Client_1 访问自己的报文。 你所说的 Hook 修改，要不就是访问是完全固定的，只存在 3 台主机，并且关系固定；要不就需要另外的实时消息通知机制。 |
|
23
Austing Aug 10, 2018
@ShadowStar
您真的了解 TCP/IP 和 netfilter? 没有任何操作的下 Client_1 和 VPS_2 当然不知道, 但是这和我说的有什么关系吗? 题主所说的不就是三台主机的固定关系? 即便不固定, Client 的处理也不会说只能针对一个地址. 即便不针对地址, 同样可以 connmark 一个特定状态或者数据包标识来标记用来匹配. @yingtl 如果可以伪装 src 确实可以达到此目的, 但是你要想要比较满意的达到这个目的, 成本不会亚于你多买几台机器的. |
|
24
yingtl OP @Austing #19 代码改起来是非常简单的, 就是把发送的部分改成用 raw socket 发送, 自己加上伪造的 ip 头.
问题是按照你说的常见的 vps 构架都过滤这种情况了 |
|
25
ShadowStar Aug 10, 2018
@Austing 10 年前我就是做某国产防火墙的内核开发的，用的就是 Linux 的 netfilter 基础，写的就是 netfilter 模块，当时用的内核版本还是 2.6.24 呢。
目前，我是做 Cavium 平台数据通信安全产品的底层开发。天天写代码玩的就是网络数据。 connmark 的前提是要双向命中相同的 conntrack，按照正向 Client_1:Rand_Port -> VPS_1:Port_A ；反向 VPS_2:Port_B -> Client_1:Rand_Port 这个会话，在 Client_1 上根本命中不了同一个 conntrack ！ |
 |
26
Themyth Feb 8, 2019
无意中看到这个，我大概知道楼主想干什么
楼主是不是想在强 内发送数据包出去，用一台 VPS 勾住然后伪造 src port 发到强 外？ Client_1:Rand_Port -> VPS_1:Port_A ；返程 VPS_2:Port_B -> Client_1:Rand_Port 是肯定不行的。 但是 Client_1:Rand_Port -> VPS_1:Port_A ；返程 VPS_2:Port_A -> Client_1:Rand_Port 是可行的。 可行的前提是，你的那台返回数据的 VPS，必须加白名单，这个难度相当大，从最开始的服务商，到机房，到上游运营商都允许才行，成本很高，我以前的解决方案是购买自己的 ASN 和 IP space，然后和机房做 bgp session。 如果有兴趣，我们可以交流 |
Select Language