Назад | Перейти на главную страницу

Получение IPTables для правильной пересылки трафика NTP

У меня следующая установка:

    NTP
  10.21.3.169
    |
    |
  10.21.3.160 (eth1)
   Linux
  10.0.0.67 (eth0)
    |
    |
  10.0.0.65 (pcn1)
   OpenBSD

Идея состоит в том, чтобы позволить клиенту NTPD (не OpenNTP) в окне OpenBSD получать время от сервера NTP, используя переадресацию портов в окне OpenBSD и iptables в окне Linux.

Я нахожусь на той стадии, когда верно следующее:

Но ничего не возвращается - нет движения ни на одной из машин в другом направлении.

Правила iptables, которые я использую на машине Linux, следующие:

iptables -A PREROUTING -t nat -i eth0 -p udp --dport 123 -j DNAT --to-destination 10.21.3.169:123
iptables -A FORWARD -t filter -p udp -d 10.21.3.169 --dport 123 -j ACCEPT

Что мне кажется правильным. В конфигурации IPTables есть также правило «принять состояние, СВЯЗАННОЕ / УСТАНОВЛЕННОЕ», которое было до того, как я начал эту работу.

Что я делаю не так? Чего-то не хватает? Может быть, какие-то дополнительные правила для ответа?

редактировать

Я последовал советам в ответе @ gromit и комментариях @ MadHatter, и мне нужно добавить следующую информацию:

В системе Linux запущен cat /proc/sys/net/ipv4/ip_forward дает 1. Бег ntpd -d -s на коробке OpenBSD с tcpdump мониторинг eth0 и "eth1 на коробке Linux (в разных терминалах одновременно) дает следующий вывод.

OpenBSD

[root@OpenBSDBox ~]# ntpd -d -s
ntp engine ready
no reply received in time, skipping initial time setting
no reply from 10.0.0.67 received in time, next query 3227s

Linux Box

tcpdump -n -n -i eth0 port 123

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
10:05:26.448943 IP 10.0.0.65.63822 > 10.0.0.67.123: NTPv4, Client, length 48

tcpdump -n -n -i eth1 port 123

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
10:05:26.449220 IP 10.21.3.160.63822 > 10.21.3.169.123: NTPv4, Client, length 48
10:05:26.449148 IP 10.21.3.169.123 > 10.21.3.160.63822: NTPv4, Server, length 48

Таким образом, похоже, что маршрутизация по-прежнему не правильная в окне Linux - ответ возвращается из окна NTP, но не отправляется в OpenBSD.

Для наглядности добавленная мной маршрутизация iptables выглядит так:

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 123 -j DNAT --to-destination 10.21.3.169:123
iptables -t filter -A FORWARD -p udp -d 10.21.3.169 --dport 123 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -p udp --dport 123 -j MASQUERADE
//for the final line, I changed @gromit's suggestion slightly, as the --from option wasn't recognised
iptables -t nat -A POSTROUTING -p udp --sport 123 -j SNAT --to-source 10.21.3.169

Оставив этот последний iptables линия, кажется, не имеет значения tcpdump вывод.

Редактировать 2

Теперь у меня есть следующие записи IPtables, и я могу обновить часы в окне OpenBSD:

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 123 -j DNAT --to-destination 10.21.3.169:123
iptables -t nat -A PREROUTING -i eth1 -p udp --sport 123 -j DNAT --to-destination 10.0.0.65:123
iptables -t filter -A FORWARD -p udp -d 10.21.3.169 --dport 123 -j ACCEPT
iptables -t filter -A FORWARD -p udp -d 10.0.0.65 --sport 123 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -p udp --dport 123 -j MASQUERADE
iptables -t nat -A POSTROUTING -p udp --sport 123 -j SNAT --to-source 10.21.3.169

Однако команды второй предварительной маршрутизации и второго фильтра кажутся мне излишними, поскольку, насколько я понимаю, они пересылают все пакеты UDP с порта 123 на сервере NTP. У меня есть ощущение, что это означает, что все ответы NTP, которые поступают в ящик Linux (то есть в том числе, когда сам ящик Linux запрашивает время), будут перенаправлены в ящик OpenBSD.

похоже, у вас проблема с маршрутизацией.

Знает ли система, обслуживающая время (3.169), как подключиться к запрашивающей системе?

Если нет, добавьте следующее в iptables окна Linux:

// this rule, redirects the packets for NTP to the NTP server on the host
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 123 -j DNAT --to 10.21.3.169

// this rule make it look for the ntp server as if the linux box is requesting the packets, which
// makes routing not necessary and lets the packet flow back to the linux box
iptables -t nat -A POSTROUTING -o eth1 -p udp --dport 123 -j MASQUERADE

// now the linux box has to check, that the packets coming back are looking like they are from the
// main source
iptables -t nat -A POSTROUTING -i eth1 -p udp --sport 123 -j SNAT --from $ip_the_client_requested_the_time_from

Теперь похоже, что пакеты ntp возвращаются, и время синхронизировано.

Было бы проще, если бы демон ntp и перенаправление работали в одной системе. Затем вы можете использовать функцию iptables «-j REDIRECT», которая делает за вас всю магию, но работает только на локальном хосте.

КР,

Громит

Самый быстрый способ узнать, блокирует ли запрос правило iptables: запустите «watch iptables -L -n -v» в правой таблице (с -t nat / в зависимости от того, что), затем повторно запустите команду ntpdate на клиенте. Вы должны увидеть, что счетчики iptables увеличиваются в строке, блокирующей пакеты, если это действительно проблема iptables BLOCK или аналогичная.