Iptables:从网关以外的其他服务器转发端口

发布于 2024-11-18 15:39:15 字数 469 浏览 3 评论 0原文

情况是这样的。 我们的内网有多个服务器 192.168.1.0/24 其中之一是所有网关的默认网关,并具有两个接口($GATEWAY_INTERNAL_IP 和 $GATEWAY_EXTERNAL_IP)。

我们还有另一个服务器 PUBLICHOST2,它有两个 IP,以及 $PUBLICHOST_EXTERNAL_IP 和 $PUBLICHOST_INTERNAL_IP。

我们有第三台服务器 SERVER,它只有一个 IP $PRIVIP 并绑定在端口 $PORT 上。

我们想要的是能够将 $PUBLICHOST_EXTERNAL_IP 上的端口 $PORT 转发到 $PRIVIP 上的主机 SERVER。

但是当我们在 PUBLICHOST2 上使用 iptables 进行端口转发时,SERVER 收到请求,但响应经过网关,连接不成功。

我们如何正确进行设置,以便响应可以通过 PUBLICHOST2 返回?

谢谢

Here is the situation.
We have multiple server on our intranet 192.168.1.0/24
One of them is the default gateway for all of them and have two interfaces ($GATEWAY_INTERNAL_IP and $GATEWAY_EXTERNAL_IP).

We have also another server PUBLICHOST2 which has two IP as well $PUBLICHOST_EXTERNAL_IP and $PUBLICHOST_INTERNAL_IP.

We have a third server SERVER which have only one IP $PRIVIP and bind on port $PORT.

What we want is to be able to forward port $PORT on $PUBLICHOST_EXTERNAL_IP to host SERVER on $PRIVIP.

But when we do the port forwarding using iptables on PUBLICHOST2, SERVER receive the request but the response goes through the gateway and the connection is not successfull.

How can we properly do the setup so that the response can go back through PUBLICHOST2 ?

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

我喜欢麦丽素 2024-11-25 15:39:15

您可能需要为接口设置转发。尝试 tne 命令。

sysctl -w net.ipv4.conf.eth0.forwarding=1

如果您需要其他帮助,请查找有关路由的文档或 Shorewall 常见问题解答

You may need to set forwarding on for the interface. Try tne command.

sysctl -w net.ipv4.conf.eth0.forwarding=1

If you need additional help look for documentation on routeback or the Shorewall FAQ.

舞袖。长 2024-11-25 15:39:15

发生了什么:

  • Client1 向 PublicHost 发送请求 请求
  • 到达,iptables 规则将流量 (PAT) 重定向到正确 AppPort 上的服务器 服务器
  • 向 Client1 发回回复,该回复将由网关路由
  • 网关正在执行 NAT 并替换具有自己的
  • Client1 或 Client1sGateway 的源 IP 接收以 Gateway 作为源的 IP 数据包,但它期望 IP 数据包的源字段中包含 PublicHost 的 IP。
  • 最终,Client1 将 SYN/ACK(除非您使用同步代理)重新发送到 PublicHost,然后在任何与网络相关的计时器到期时断开连接。

现在,如果您想解决此问题,您应该将所有从服务器发出并使用 AppPort 源端口的 TCP 流量路由到 PublicHost。

如果这不起作用,则说明 PublicHost 未正确配置。请务必使用 tcpdump 测试配置。

Well here what happens:

  • Client1 sends a request to PublicHost
  • The requests arrives and the iptables rules redirects the traffic (PAT) to the Server on the correct AppPort
  • Server sends back a reply to Client1 which will be routed by Gateway
  • Gateway is doing NAT and replaces the source IP with it's own
  • Client1 or Client1sGateway receives the IP packet with Gateway as the source but it expected PublicHost's IP in the source field of the IP packet.
  • Eventually Client1 resends the SYN/ACK (except if you're using a synproxy) to PublicHost and then drops the connection when whatever network related timer expires.

Now if you want to fix this, you should route all TCP traffic going OUT of Server and with a source port of AppPort to PublicHost.

If this doesn't work, PublicHost is not properly configured. Be sure to test the configuration with tcpdump.

肩上的翅膀 2024-11-25 15:39:15

我一直在尝试做类似的事情。在运行了一堆似乎从未起作用的教程之后,直到我对连接进行 Wireshark 发现目标地址仍然设置为外部 IP 地址(正如您所描述的那样),我尝试使用 POSTROUTING 链来更改源 IP 地址到服务器的 IP 地址:

iptables -t nat -A POSTROUTING -p <tcp/udp> --dport <destination_port> -j SNAT --to <$PUBLICHOST_INTERNAL_IP>

添加该规则后,连接被转发到专用网络,并且响应数据包沿着相同的路径返回到客户端,而不是通过网络网关。我不确定是什么允许响应数据包通过防火墙服务器返回,但我认为这是因为我在 INPUT 链上已经有了允许建立连接的规则:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

使用此解决方案时一定要记住的事情是:如果您更改了防火墙服务器的内部 IP 地址,那么您将需要更新上述 POSTROUTING 规则。 (不用说,如果防火墙服务器有一个静态分配的内部 IP 地址可能是最好的)。

I've been trying to do something similar. After running through a bunch of tutorials that never seemed to work until I Wiresharked the connection to discover that the destination address was still set to the external IP address, (exactly like you've described), I tried using the POSTROUTING chain to change the source IP address to that of the server:

iptables -t nat -A POSTROUTING -p <tcp/udp> --dport <destination_port> -j SNAT --to <$PUBLICHOST_INTERNAL_IP>

After I added that rule, the connection was forwarded into the private network and the response packets retraced the same path back to the client, rather than through the network gateway. I'm not positive what allowed the response packets back out through the firewall server, but I think it was because of the rule I already had on the INPUT chain to allow established connections:

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

The thing to be sure to keep in mind with this solution is: if you ever change the firewall server's internal IP address, then you will need to update the above POSTROUTING rule. (Needless to say, it's probably best if the firewall server has a statically assigned internal IP address).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文