iptables 非同步 NAT。預路由表後丟包

我有一個 Centos 伺服器在我的網路中充當 NAT。該伺服器有一個外部（後來是 ext1）介面和三個內部（後來是 int1、int2 和 int3）介面。出口流量通過 int1 來自使用者，在 MASQUERADE 通過 ext1 之後。入口流量來自 ext1、MASQUERADE，並根據靜態路由通過 int2 或 int3。

                      | ext1
                      | x.x.x.x/24
            +---------|----------------------+
            |                                |
            |  Centos server  (NAT)          |
            |                                |
            +---|------|---------------|-----+
                |      |               |
           int1 |      | int2          | int3
  10.30.1.10/24 |      | 10.30.2.10/24 | 10.30.3.10/24
                ^      v               v
   10.30.1.1/24 |      | 10.30.2.1/24  | 10.30.3.1/24
            +---|------|---------------|-----+
            |   |      |               |     |
            |   |      v               v     |
            |   ^      -Traffic policer-     |
            |   |_____________ |             |
            |                  |             |
            +------------------|-------------+
                               | 192.168.0.1/16
                               |
                               |
                            Clients         
                            192.168.0.0/16

問題：出口流量似乎在 PREROUTING 表之後被丟棄。POSTROUTING 中的 MASQUERADE 規則上的數據包計數器不會改變。如果我更改通往客戶端的路由，導致流量通過 int1 返回 - 一切正常。

目前的 iptable 配置非常簡單：

# 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
x.x.x.0/24 dev ext1  proto kernel  scope link  src x.x.x.x 
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 x.x.x.y dev ext1  

客戶端將 192.168.0.1 作為網關，將它們重定向到 10.30.1.1

我懷疑您可能遇到了反向路徑過濾器的問題。它旨在執行一些檢查以確保在給定介面上接收到的數據包實際上屬於該介面。

# 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

引用自：https://serverfault.com/questions/374748