☰

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

tag-icon • tag-icon linux networking iptables udp dnat
Почему некоторые правила iptables DNAT не работают до перезагрузки?

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

Описание архитектуры:

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

senderX 10.0.0.X ====> Linux-маршрутизатор с iptables ====> receiveerY 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?
  • Как я могу решить эту проблему?

решение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 для пакетов в обоих направлениях, так что вы всегда получаете желаемую запись отслеживания соединения, даже если первый пакет отправляется в противоположном направлении, чем обычно.

Связанный контент