Zauważyłem, że synchronizacja czasu coś nie do końca mi działa tak jak powinna. I nie chodziło o kilka sekund, ale o kilka dni różnicy między czasem na urządzeniu, a tym rzeczywistym. Trochę dziwne, bo urządzenie ma na sobie ntpd i powinno się synchronizować z pool.ntp.org. Po sprawdzeniu logów okazało się, że nie ma odpowiedzi od serwerów. Dziwne...
By skrócić potencjalnie długą historię - jeśli pakiet ma ustawiony port źródłowy na 123 to nie ma odpowiedzi od serwera. Jeśli natomiast port źródłowy jest inny (np. ntpdate -u), wówczas wszystko działa jak należy. Zapewne ISP blokuje takie pakiety...
Oczywiście opcja masquerade nie zmienia portu 123 na inny, więc trzeba było dorobić dodatkową regułę src-nat i wszystko zaczęło działać prawidłowo. Nie zmienia to faktu, że jestem nieco zirytowany zaistniałą sytuacją. Przy okazji - niestety, nie mam możliwości zainstalowania OpenNTPD, tam tego problemu nie ma bo usługa nie jest przywiązana do portu 123 (źródło).
A teraz pytanie - dlaczego? Zgaduję - zapewne dlatego: Understanding and mitigating NTP-based DDoS attacks.
DZIĘ-KU-JE-MY!
W skrócie - genialny pomysł, nie ma to jak wylać dziecko z kąpielą, prawda?
Do końca też nie wiem, z którym ISP się kontaktować. Muszę sprawdzić gdzie pakiety UDP na port 123 są zabijane w drodze do mojego IP.
Zacząłbym od swojego. Stawiam, że jakiś mały i popełnił wynalazek. Duzi raczej takich cyrków nie robią, a jak robią to z głową.
Nawiasem, popatrz raczej na to, czy nie chodzi o rozmiar pakietu.
Ponieważ nie mam ochoty marnować czasu na dyskusje z ISP problem obszedłem tak:
1. Serwer NTP na routerze, snat by zmienić port źródłowy;
2. Z wewnętrznej sieci przekierowanie na serwer na routerze (jeśli port źródłowy to 123).
Działa wystarczająco dobrze.