对 IP 转发端口的响应不回来 [英] Response to IP Forwarded Port not coming back

问题描述

tl;dr:我遇到了一个问题，而端口转发无法正常工作.尽管一直看到数据包，但响应似乎永远不会回来(超时).

tl;dr: I have a problem whereas a Port Forwarding is not working properly. The response never seems to come back (times out), despite seeing packets all the way.

简而言之:https://raspberry-ip:5555 应该加载 https://server-ip:9999 但尽管事实上端口转发似乎有效.

In short: https://raspberry-ip:5555 should load https://server-ip:9999 but it doesn't despite the fact that the port forwarding seems to be working.

• 我有一个服务器，它通过一个网站回复端口 9999.我可以直接从我的笔记本电脑访问.

• I have a server which replies to port 9999 with a website. I can access directly from my laptop.

我有一个树莓派，它将流量从本地端口 5555 转发到端口 9999 (详情).

I have a Raspberry Pi, which forwards the traffic to the server from local port 5555 to the port 9999 (details).

我可以看到数据包从服务器返回到我的笔记本电脑.

I can see the packets coming back to my laptop from the server.

但是，请求在浏览器上超时 (ERR_CONNECTION_TIMED_OUT).

However, the request times out on the browser (ERR_CONNECTION_TIMED_OUT).

在 Raspberry Pi 上的端口 5555 上执行 tcpdump，我看到流量传入.示例:

Doing a tcpdump on port 5555 on the Raspberry Pi, I see the traffic incoming. Sample:

16:54:56.447235 IP 192.168.250.18.57300 > 192.168.250.8.5555: Flags [S], seq 691303721, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 280675211 ecr 0,sackOK,eol], length 0

在服务器的 9999 端口上执行 tcpdump 看起来不错，并且直接来自笔记本电脑:

Doing a tcpdump on port 9999 on the server looks fine, and coming directly from the laptop:

16:55:55.710925 IP 192.168.250.18.57315 > 192.168.250.250.9999: Flags [S], seq 2427731411, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 280734035 ecr 0,sackOK,eol], length 0

从服务器到笔记本电脑(在笔记本电脑上)执行 tcpdump，我也可以看到交互:

Doing a tcpdump from the server to the laptop (on the laptop), I can see interactions too:

17:12:43.653411 IP 192.168.250.250.9999 > 192.168.250.18.57998: Flags [S.], seq 1225747155, ack 4067090852, win 65160, options [mss 1460,sackOK,TS val 2493575411 ecr 281722216,nop,wscale 7], length 0

所有 3 台机器(我的笔记本电脑、树莓派和服务器)都在同一个/24 子网上，并且所有路由都配置正确.此外，我可以ping通其中的机器.所以它看起来不像是路由的问题.

All the 3 machines (my laptop, the raspberry and the server) are on the same /24 subnet and all the routes are configured correctly. Additionally, I can ping the machines among them. So it doesn't look like an issue with routes.

推荐答案

问题如下

192.168.250.18    192.168.250.8  192.168.250.250
   [client] ------ [raspberry] ----- [server]

这里发生的事情是服务器从树莓派接收重定向的数据包，但会尝试将数据包直接返回给客户端，因为它们属于同一子网(尽管这是一个假设.你能确认所有设备都有/24 网络?).然后客户端将丢弃它，因为它来自服务器的 IP (192.168.250.250) 地址，并且它不是客户端尝试建立到 192.168.250.8 的初始会话的一部分.

What happens here is that server receives the redirected packet from the raspberry pi, but will try to return the packet directly to the client as they belong to the same subnet (this is an assumption though. can you confirm all devices have /24 network?). The client will then discard it because it's coming from the server's IP (192.168.250.250) address and it's not part of the initial session which client tried to establish to 192.168.250.8.

解决这个问题的一种方法是在树莓派上执行 SNAT

One way to solve this problem is to perform SNAT on raspberry

$ iptables -t nat -I POSTROUTING -p tcp -s 192.168.250.18 -d 192.168.250.250 -j MASQUERADE 

当 raspberry 向服务器发送流量时，这将更改 IP 标头的来源，因此服务器会将流量返回给 raspberry，而不是直接返回给客户端.

This will change the source of the IP header when raspberry is sending traffic to the server , so the server will return the traffic to the raspberry and not directly to the client.

这篇关于对 IP 转发端口的响应不回来的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！