☰

前言

tag-icon • tag-icon networking iptables forwarding
前言

前言

我们有一个测试设置，其中多个组件连接到自己的网络。该网络的地址如下：172.25.1.0/24。大多数（如果不是全部）组件都具有静态 IP 地址，因为它们是由多个标准和文档定义的。

由于显而易见的原因，我们公司的网络与该机器网络分开，但对于不同的测试场景，机器网络内的某些组件必须能够与互联网通信。

设置

对于我们的设置，我们通过 USB 以太网适配器 (10/100/1000T) 将机器网络连接到 RaspberryPi 4 (8GiB)，并将内置网络适配器连接到可访问 WAN 的公司网络。

这个想法是，Pi 伪装从 172.25.1.0/24 到 <任何地方> 的流量。

该设置已经工作了相当长的一段时间，但最近它只是停止路由流量。我不知道为什么。

知识产权规则

我们有一个设置 iptables 规则的脚本，这之前一直有效到周末（上周末）：

#!/bin/bash

IPTABLES=/sbin/iptables

WANIF='eth0'
LANIF='eth1'

# enable ip forwarding in the kernel
echo 'Enabling Kernel IP forwarding...'
/bin/echo 1 > /proc/sys/net/ipv4/ip_forward

# flush rules and delete chains
echo 'Flushing rules and deleting existing chains...'
$IPTABLES -F
$IPTABLES -X

# enable masquerading to allow LAN internet access
echo 'Enabling IP Masquerading and other rules...'
$IPTABLES -t nat -A POSTROUTING -o $LANIF -j MASQUERADE
$IPTABLES -A FORWARD -i $LANIF -o $WANIF -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A FORWARD -i $WANIF -o $LANIF -j ACCEPT

$IPTABLES -t nat -A POSTROUTING -o $WANIF -j MASQUERADE
$IPTABLES -A FORWARD -i $WANIF -o $LANIF -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
$IPTABLES -A FORWARD -i $LANIF -o $WANIF -j ACCEPT

$IPTABLES -A INPUT -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT

echo 'Done.'

生成的 iptables 规则如下所示：

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate NEW,RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state NEW,RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             state NEW,RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

据我所知，这应该将所有流量从 eth1 (LAN) 路由到 eth0 (WAN) - 这正是它之前所做的。但显然，当我尝试 ping Google 的 DNS 时，我得到以下信息：

ping -I eth0 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
^C
--- 8.8.8.8 ping statistics ---
1317 packets transmitted, 0 packets received, 100% packet loss

任何有关此事的帮助将不胜感激。如果没有数据包转发/伪装，我们最关键的测试就无法运行。谢谢！

编辑

根据请求的输出ip route：

0.0.0.0/24 via 10.0.101.1 dev eth0 
default via 10.0.101.1 dev eth0 
10.0.101.0/24 dev eth0 proto kernel scope link src 10.0.101.160 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.25.1.0/24 dev eth1 proto kernel scope link src 172.25.1.160

编辑：第二个

RasPi 的接口上有以下 IP： eth0 = 10.0.101.160 eth1 = 172.25.1.160

平： Ping 172.25.1.160 按预期工作。平均。 ping时间为0.5ms。

Ping Pi 的传出接口 (10.0.101.160) 也可以。平均。 ping 时间为 0.667 毫秒。

这意味着我可以假设一些流量至少到达接口并返回 LAN。但是，我仍然不明白为什么流量没有离开“WAN”（公司网络）的接口。运行 tcpdump -i eth1 可以看到，在公司网络中 ping 客户端时，ARP 请求到达该接口：

13:12:39.660173 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 172.25.1.57 tell 172.25.1.3, length 46
2 packets captured
492 packets received by filter
484 packets dropped by kernel

然而，在 eth0 上调用 tcpdump 不会从 eth1 产生任何消息。对我来说，这表明问题出在 iptables 规则上，这些规则以前是有效的，但现在不再是这样了；这意味着我又回到了原来的问题。

答案1

我发现问题了

所以我的具体问题的解决方案非常简单。要么我在其他论坛帖子中忽略了它，要么我根本没有找到任何包含此建议的帖子。 iptables 规则都很好，但是我缺少以下命令：

echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp

执行此命令立即解决了问题，现在一切正常。

不过还是感谢所有评论的人！

相关内容