Sha*_*nu4 2 nat iptables ip-routing iproute2
我有一台 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
Run Code Online (Sandbox Code Playgroud)
问题:出口流量似乎在 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
Run Code Online (Sandbox Code Playgroud)
谁能指出我缺少什么?谢谢。
更新:
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
Run Code Online (Sandbox Code Playgroud)
客户端有 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
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
3168 次 |
| 最近记录: |