[GTER] servidor ntp atrás de rede filtrada - como?

[João Vitor S]

Em 9 de março de 2015 16:23, Danton Nunes <danton.nunes at inexo.com.br>
escreveu:

> On Mon, 9 Mar 2015, João Vitor S wrote:
>
>  Boa tarde,
>>
>> Uso oi/telemar e eles estão bloqueando UDP/123, desde que isso começou
>> acontecer estou sem ntpd/ntpdate
>>
>
> hã? e pode isso, Arnaldo?


Pois é. Temos aqui os conselheiros do Marco Civil, pode isso GTER? Não sei
se essa é pro Arnaldo que depende "da regra clara"... se não puder escalo
na ANATEL :) Mas pelo que percebo com Net Virtua, OI, GVT, mesmo quando
empresariam, tem uma série de bloqueios de portas pre marco civil que
continuam a pleno vapor.

Mas não quer desvirtuar o assunto.


>  Uso servidores internos mas os internos estão sem referência e já somam
>> algum atraso
>>
>> Fora brigar com a operadora, que por ser formal é algo moroso e por ser
>> telemar é mais moroso ainda, o que posso fazer?
>>
>
> um jeito porco é abrir um túnel teredo para a huricane electric e aceder a
> algum servidor público de ntp por ele, por exemplo, os do observatório
> naval dos USA, mas latência de túnel nunca é lá essas coisas.


Pois é, nessa linha que eu não queria atuar, tunelando e mantendo serviço
de pé só pra sincronizar horário.

Ja tentei rodar um servidor ntp proprio em outra porta, mas é incrível
>> nenhum daemon ntpd tem opção de ouvir em outra porta senão 123, absurdo
>> isso, mas se tivesse fui olhar no ntpdate ou em um daemon em modo cliente
>> e
>> eles também não permitem declarar a porta pra consulta, isso é restrição
>> rfc ou falta de boa vontade de melhorar um protocolo velho mesmo?
>>
>
> isso não é nenhum absurdo, 123/UDP é número de porta oficialmente
> designado pelo IANA. Normas técnicas e boas práticas estão aí por um motivo.


Tão comum quanto uma norma técnica (no caso, especificação) ou melhores
práticas, como é o caso de portas e protocolos WKS, é a necessidade de
fugir à regra e as vezes colocar o serviço em outra combinação não WKS.
O sentido do "absurdo" que me referi não foi existir a prática, mas achei
muito estranho não haver opção pra variar isso. Desde velharia como gopher,
whoisd, telnet, ftp, rcp, os daemons podem ouvir em outras portas e os
clientes acessa-las. Esperava a mesma trivialidade pro NTP que ja teria
resolvido meu problema!



>  No momento estou fazendo um tunel sobre ssh que me leva pra um servidor
>> fora da minha rede e la eu tenho um ntpd que sincroniza com ntp.br e eu
>> sincronizo com ele e sirvo minha rede, no entanto não gosto da ideia e
>> quero usar algo publico
>>
>
> não é a melhor coisa do mundo, mas serve. teu servidor interno fica um
> estrato abaixo do servidor intermediário, mas o erro no tempo deve ficar
> pequeno. qual é o maior erro que você pode aceitar?
>

Não acho que faria diferença pra mim, se tiver uma referência, mesmo que
ela demore pra chegar por estar tunelada, será suficiente pra manter o ntpd
sincronizado.


> através desse túnel você não tem acesso direto aos *.ntp.br?


Sim tenho, é uma VM na Digital Ocean de 10 dólares, pessoal, la rodo NTPD
consultando isc.org e ntp.br, limito acesso a poucos clientes um deles meu
setor de pesquisa aqui na universidade.
O que eu tentei foi colocar esse daemon em outra porta, digamos 12300 e
consultar essa porta. Foi o que não deu certo. Li algo sobre sincronizar
horário usando https e pesquisei a questão do OpenNTP. Mas não consegui
fazer funcionar ainda.


>
>
>  A opção do OpenNTPd que permite usar uma URL https resolve meu problema?
>> ele sincroniza horario por HTTPS? se sim alguem pode me ajudar pois não
>> consegui, sempre que dou ntpctl status ficam clock unsynced
>>
>
> que eu saiba, não.
>
> -- Danton.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter