我的networking中有一个Centos服务器充当NAT。 该服务器有一个外部（稍后的ext1）接口和三个内部（稍后int1，int2和int3）。 出口stream量来自用户通过int1和MASQUERADE通过ext1后。 入口stream量来自ext1，MASQUERADE，并根据静态路由通过int2或int3。
| ext1 | xxxx/24 +---------|----------------------+ | | | Centos server (NAT) | | | +---|------|---------------|-----+ | | | int1 | | int2 | int3 10.30.1.10/24 | | 10.30.2.10/24 | 10.30.3.10/24 ^ vv 10.30.1.1/24 | | 10.30.2.1/24 | 10.30.3.1/24 +---|------|---------------|-----+ | | | | | | | vv | | ^ -Traffic policer- | | |_____________ | | | | | +------------------|-------------+ | 192.168.0.1/16 | | Clients 192.168.0.0/16 问题：在PREROUTING表之后，出口stream量似乎下降了。 数据包计数器在POSTROUTING中的MASQUERADE规则上没有改变。 如果我改变路由到客户端导致stream量通过int1返回 – 一切工作完美。
目前的iptableconfiguration很简单：
# cat /etc/sysconfig/iptables *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -I INPUT 1 -i int1 -j ACCEPT -A FORWARD -j ACCEPT COMMIT *nat -A POSTROUTING -o ext1 -j MASQUERADE # COMMIT
任何人都可以指出我错过了什么？ 谢谢。
更新：
192.168.100.60 via 10.30.2.1 dev int2 proto zebra # routes to clients ... 192.168.100.61 via 10.30.3.1 dev int3 proto zebra # ... I have a lot of them xxx0/24 dev ext1 proto kernel scope link src xxxx 10.30.1.0/24 dev int1 proto kernel scope link src 10.30.1.10 10.30.2.0/24 dev int2 proto kernel scope link src 10.30.2.10 10.30.3.0/24 dev int3 proto kernel scope link src 10.30.3.10 169.254.0.0/16 dev ext1 scope link metric 1003 169.254.0.0/16 dev int1 scope link metric 1004 169.254.0.0/16 dev int2 scope link metric 1005 169.254.0.0/16 dev int3 scope link metric 1006 blackhole 192.168.0.0/16 default via xxxy dev ext1
客户端有192.168.0.1作为网关，将它们redirect到10.30.1.1
我怀疑你可能会遇到反向pathfilter的问题。 其中的目的是执行一些检查，以确保在给定的接口上收到的数据包实际上属于该接口。
# from linux-doc-nnn/Documentation/networking/ip-sysctl.txt rp_filter - INTEGER 0 - No source validation. 1 - Strict mode as defined in RFC3704 Strict Reverse Path Each incoming packet is tested against the FIB and if the interface is not the best reverse path the packet check will fail. By default failed packets are discarded. 2 - Loose mode as defined in RFC3704 Loose Reverse Path Each incoming packet's source address is also tested against the FIB and if the source address is not reachable via any interface the packet check will fail. Current recommended practice in RFC3704 is to enable strict mode to prevent IP spoofing from DDos attacks. If using asymmetric routing or other complicated routing, then loose mode is recommended. conf/all/rp_filter must also be set to non-zero to do source validation on the interface