Obtendo IPTables para encaminhar corretamente o tráfego NTP

Question

Eu tenho a seguinte configuração:

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

A idéia é permitir que o cliente NTPD (não OpenNTP) na caixa do OpenBSD obtenha o tempo do servidor NTP usando o encaminhamento de porta na caixa do OpenBSD e o iptables na caixa Linux.

Estou no estágio em que o seguinte é verdadeiro:

• O pf.conf da caixa do OpenBSD foi configurado corretamente, de modo que a execução de tcpdump udp na caixa do Linux mostre o tráfego correto da caixa do OpenBSD quando eu executar ntpd -d -s
• A configuração do iptables da caixa do Linux foi configurada corretamente, de modo que, executando ntpd -d -s na caixa do OpenBSD, o tráfego aparece usando tcpdump udp no servidor NTP

Mas nada volta - não há tráfego em nenhuma das máquinas na outra direção.

As regras do iptables que estou usando na máquina Linux são:

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

O que parece correto para mim. Existe também uma regra "aceitar estado RELATED / ESTABLISHED" na configuração do IPTables que estava lá antes de começar este trabalho.

O que estou fazendo de errado? Há algo faltando? Talvez algumas regras extras para a resposta?

Editar

Eu segui o conselho na resposta do @ gromit e nos comentários do @ MadHatter, e tenho as seguintes informações para adicionar:

Na caixa Linux, a execução de cat /proc/sys/net/ipv4/ip_forward dá 1 . A execução de ntpd -d -s na caixa do OpenBSD com tcpdump monitoring eth0 e "eth1 na caixa do Linux (em terminais diferentes, ao mesmo tempo) fornece a seguinte saída.

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

Portanto, parece que o roteamento ainda não está correto na caixa do Linux - a resposta está voltando da caixa NTP, mas não está sendo enviada para o OpenBSD.

Apenas para esclarecer, o roteamento do iptables que eu adicionei agora é assim:

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

Deixar essa linha final iptables parece não fazer diferença para a saída tcpdump .

Editar 2

Agora tenho as seguintes entradas do IPtables, e posso atualizar o relógio na caixa do 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

No entanto, os comandos second prerouting e second filter parecem um exagero para mim, pois, pelo que entendi, eles encaminham todos os pacotes UDP da porta 123 no servidor NTP. Eu tenho a sensação de que isso significa que todas as respostas do NTP que vão para a caixa do Linux (ou seja, incluindo quando a própria caixa do Linux pede o tempo) serão encaminhadas para a caixa do OpenBSD.

    

Answer 1

parece que você tem um problema de roteamento.

O sistema que atende a hora (3,169) sabe como se conectar ao sistema solicitante?

Se não adicionar o seguinte ao iptables da caixa do 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

Agora parece que os pacotes ntp estão voltando e o tempo está sincronizado.

Seria mais fácil se o daemon ntp e o redirecionamento fossem executados no mesmo sistema. Então você poderia usar o recurso "-j REDIRECT" do iptables que faz toda a mágica para você, mas funciona apenas no host local.

KR

Gromit

    

Answer 2

A maneira mais rápida de descobrir se é uma regra iptables bloqueando a solicitação: Execute "watch iptables -L -n -v" na tabela à direita (com -t nat / whatever) e execute o comando ntpdate repetidamente no cliente. Você deve ver os contadores de iptables incrementando na linha bloqueando os pacotes, se é de fato um problema de iptables BLOCK ou similar.