☰

iptables 异步 NAT。预路由表后数据包被丢弃

tag-icon • tag-icon iptables nat ip-routing iproute2
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

答案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

相关内容