collectd não pode monitorar ntpd 4.2.8 (Ubuntu 16.04)

Question

Eu tenho um contêiner Docker baseado no Ubuntu 16.04 que executa o serviço ntpd 4.2.8. Após a instanciação do contêiner, eu publiquei a porta 123 / udp.

Do host ou outro computador na LAN, posso usar ntpq -p <container_host> para obter a lista de peers e o status de sincronização. Mas monitorando-o usando collectd ou executando ntpdc -c kerninfo <container_host> fail / timeouts. E isso está me intrigando!

Eu testei dentro do contêiner com algumas declarações restrict razoáveis e também sem nenhuma. Mas em ambos os casos eu terminei. Executar o tcpdump no contêiner (depois de elevá-lo para o contêiner privilegiado) mostra que o pacote UDP chega, mas nada é respondido. É claro que, usando o tcpdump, vejo o pedido e a resposta ao usar o ntpq que está funcionando.

Se eu executar o servidor ntpd diretamente no host, usando o mesmo arquivo ntp.conf, o ntpdc -c kerninfo <container_host> e o collectd terão êxito no host e em outros computadores da LAN que eu autorizei! No entanto, o host ainda está executando uma versão mais antiga do Ubuntu (14.04) que vem com o ntp 4.2.6.

Portanto, as únicas diferenças são as redes Docker (NAT até onde eu entendi) e a versão ntp (4.2.6 vs 4.2.8). Mas a documentação do ntp.org não menciona nada realmente sobre o NAT nem sobre as atualizações do 4.2.8. Então, é o meu comando time-outing apenas porque o cliente está em uma sub-rede diferente do servidor (devido ao NAT)? Ou como algo mudou em 4.2.8?

Observação: minha imagem do contêiner é baseada no ubuntu: 16.04 que executa o ntpd [email protected] (dos repositórios oficiais do Ubuntu). O host executa o Ubuntu 14.04 que executa o 4.2.6p5.

PS: Collectd envia um comando equivalente ao ntpdc -c kerninfo <container_host> e timeout quando o ntpd é executado no container, mesmo que toda a declaração restrita esteja correta.

Atualização : esqueci de mencionar que também executei o ntpd dentro do contêiner com a opção -ddd para obter uma saída mais detalhada. Os únicos dados relevantes que foram registrados são:

read_network_packet: fd=19 length 192 from 192.168.1.3
receive: at 26 172.17.0.2<-192.168.1.3 flags 19 restrict 000

Update2 : Depois de descobrir a solução, mudei a pergunta na esperança de que outros tropeços no mesmo problema pudessem encontrar melhor a pergunta / resposta ao procurá-la. Eu também corrigi um erro, achei que o host estava rodando o Ubuntu 16.04, mas ele ainda estava rodando 14.04.

    

Answer 1

Eu resolvi meu problema. O erro se deve ao fato de o ntp 4.2.8 descartar (e desabilitar por padrão) a ferramenta ntpdc e o modo de comunicação que estava usando (também conhecido como mode7).

Do ntp 4.2.8 e versão mais recente, a ferramenta ntpq deve ser usada no lugar de ntpdc. Agora suporta os mesmos comandos do ntpdc. Então eu posso rodar ntpq -c kerninfo <container_host> com sucesso. O comando ntpq usa um modo diferente (também conhecido como modo6) para a comunicação.

Com o ntp 4.2.8, ainda é possível reativar o mode7 para suportar a compatibilidade com ferramentas que ainda não migraram. Deve-se adicionar a seguinte linha no /etc/ntp.conf :

enable mode7

No entanto, deve-se ter muito cuidado com a restrição. Como parece que o modo de ativação7 e a saída do servidor ntpd muito abertos, poderiam ser usados para conduzir ataques de amplificação de DDoS. Atualmente estou usando a restrição padrão para IPv4 e IPv6 no Ubuntu, que - eu acho que - bloqueia o uso desse modo:

restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

Como collectd suporta apenas mode7 (veja issue # 932 ), eu decidi reativar este modo em minha configuração dentro do contêiner. Contanto que o ntp suporte a reativação deste modo, esta mudança deve corrigir o problema que o collectd não pode monitorar o ntpd no Ubuntu 16.04 (ou qualquer distro usando o ntp 4.2.8 +).

Observação: para que as pessoas encontrem uma solução melhor se encontrarem esse problema, irei editar a pergunta para que ela seja menos enganosa em relação ao NAT, que, embora inicialmente, fosse a causa raiz.