У меня следующая установка:
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.
Я нахожусь на той стадии, когда верно следующее:
tcpdump udp
на коробке Linux показывает правильный трафик из окно OpenBSD, когда я запускаю ntpd -d -s
ntpd -d -s
в окне OpenBSD трафик появляется с использованием tcpdump udp
на сервере NTPНо ничего не возвращается - нет движения ни на одной из машин в другом направлении.
Правила 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
вывод.
Теперь у меня есть следующие записи 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 или аналогичная.