Вопросы Теги

Почему некоторые iptables DNAT правила не работают до перезагрузки?

Мои iptables DNAT правила не работают до перезагрузки. Если я перезагружаю свой сервер, всю работу правил.

Desciption архитектуры:

Десятки хостов (отправители) отправляют некоторые пакеты UDP (односторонний на определенном порте 9999) к моему маршрутизатору Linux. Этот маршрутизатор Linux использует iptables для передачи тех пакетов к нескольким хостам (получатели).

senderX 10.0.0. X ====> маршрутизатор Linux с iptables ====> receiverY 10.0.1. Y

Маршрутизатор Linux имеет две сетевых платы eth1 10.0.0.1/24 (сторона отправителей) и eth0 10.0.1.1/24 (сторона получателей).

Установка Iptables:

  • ip_forwarding активируется
  • все политики по умолчанию установлены ПРИНЯТЬ
  • правила iptables существуют на отправителя, вот пример:
iptables -t nat -A PREROUTING -s 10.0.0.2 -i eth1 -j DNAT --to-destination 10.0.1.123

Настройка сети:

ip addr show :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 54:9f:35:0a:16:38 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.1/24 brd 10.0.1.255 scope global eth0
    inet6 fe80::569f:35ff:fe0a:1638/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 54:9f:35:0a:16:3a brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 brd 10.0.0.255 scope global eth1
    inet6 fe80::569f:35ff:fe0a:163a/64 scope link
       valid_lft forever preferred_lft forever

Признак:

После добавления ряда правил не работают некоторые правила. И я вижу с tcpdump, что пакеты UDP больше не направляются, и пакеты отклоняются.

tcpdump -n -i eth1 host 10.0.0.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
16:12:58.241225 IP 10.0.0.2.56859 > 10.0.0.1.9999: UDP, length 1464
16:12:58.241285 IP 10.0.0.1 > 10.0.0.2: ICMP 10.0.0.1 udp port 9999 unreachable, length 556
  • Если я сбрасываю все правила и повторно ввожу их в iptables, правила, который не работал все еще работа.
  • Если я перезагружаю свой сервер, все правила хорошо работают.

Анализ сделан:

Я добавил правило зарегистрировать определенного отправителя, который не работает:

iptables -t nat -A PREROUTING -s 10.0.0.2 -i eth1 -j LOG --log-prefix='PREROUTING LOG :'

Но это правило ничего не регистрирует. Пакеты прибывают, потому что я вижу пакеты в tcpdump, но они не зарегистрированы. Также с -v опция в iptables, я не вижу, что счетчики увеличиваются для этого правила.

Если я подаю заявку, то же правило перед ним прекращают работать, у меня есть некоторые журналы.

Вопрос:

  • Есть ли какие-либо пределы на передачу UDP в iptables?
  • Как я могу диагностировать эту проблему?
3
задан 10 March 2015 в 16:03
1 ответ

Описанные вами симптомы соответствуют тем, которые наблюдаются при конфликте между правилом NAT и записью отслеживания соединения.

Например, когда пакет соответствует 

-A PREROUTING -s 10.0.0.2 -i eth1 -j DNAT --to-destination 10.0.1.123

при отслеживании нового соединения. запись должна быть создана. Это сопоставит кортеж IP-адреса источника и назначения и порта на входящей стороне с аналогичным кортежем на исходящей стороне.

Не может быть существующей записи отслеживания соединения, соответствующей входящей стороне, потому что, если бы она была, она была бы использована вместо правила. Однако после замены целевого IP-адреса кортежа для создания кортежа для исходящей стороны этот кортеж может конфликтовать с существующей записью отслеживания соединения.

Если вы установите утилиту conntrack , вы можете ввести conntrack -L , чтобы просмотреть список существующих записей отслеживания соединений. Эта утилита также имеет функции для вывода списка только записей отслеживания соединений, соответствующих определенным критериям, а также для удаления выбранных записей.

Если это действительно проблема, с которой вы столкнулись, то удаление записи отслеживания соединений, вызывающей нарушение, решит проблему. Постоянное исправление обычно включает в себя настройку соответствующих правил NAT для пакетов в обоих направлениях, чтобы вы всегда получали желаемую запись отслеживания соединения, даже если первый пакет отправляется в противоположном направлении, чем обычно.

4
ответ дан 3 December 2019 в 06:05

Теги

Похожие вопросы