У меня есть сервер 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. Счетчики пакетов не меняются в правиле MASQUERADE в POSTROUTING. Если я изменю маршруты к клиентам, вызывающие возврат трафика через 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