ntpd Invalid-NAK error

Dan Lukes dan at obluda.cz
Thu Jun 15 18:19:47 CEST 2017


(ted jsem si vsimnul, ze jsem odpovedel jen primo Mirkovi, tak to 
preposilam jeste jednou ve verejny plen)

> ntpd[95529]: Invalid-NAK error at 73632 192.168.23.2<-192.168.23.253


> Frame 11: 94 bytes on wire (752 bits), 94 bytes captured (752 bits)
> Internet Protocol Version 4, Src: 192.168.23.253, Dst: 192.168.23.2
> User Datagram Protocol, Src Port: 123, Dst Port: 123
>     Length: 60
> Network Time Protocol (NTP Version 3, client)
>     Flags:
>         11.. .... = Leap Indicator: unknown (clock unsynchronized) (3)
>         ..01 1... = Version number: NTP Version 3 (3)
>         .... .011 = Mode: client (3)
>     Peer Clock Stratum: unspecified or invalid (0)
>     Peer Polling Interval: 6 (64 sec)
>     Peer Clock Precision: 0.000004 sec
>     Root Delay:    0.0000 sec
>     Root Dispersion:    0.0000 sec
>     Reference ID: NULL
>     Reference Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
>     Origin Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
>     Receive Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
>     Transmit Timestamp: Aug  3, 2000 06:14:09.324232000 UTC
>     Key ID: 00000000

Tak jo. Tohle je NTPv3 (RFC1305) klientsky request. Ten ale v 
nejednodussi podobe konci polozkou Transmit Timestamp. Tenhle je ale 
delsi, to znamena autentizaci (RFC1305 Annex C), ergo validaci prijateho 
paketu. To, ze by byl uspesny i dotaz bez autentizace nehraje roli, 
jakmile se klient rozhodne autentizaci uvest, pak se validuje.

KeyID ma delku 4. Podle delky se rozpoznava pouzita autentizace. Ctyrka 
znamena crypto-NAK, coz ale muze nastat jen v odpovedi na autentizovany 
request kde overeni autentizace selze.

V dotazu nema crypto-NAK co delat, ergo, je to bez ohledu na dalsi 
okolnosti neplatny NAK (v tomhle kontextu). Paket se zahodi.

Pokud to nedokazes vyresit na strane klienta (napriklad tak, ze 
autentizaci nakonfigurujes - je duvod cekat, ze problem nastava jen v 
rezimu bez autentizace) budes muset sahnout do zdrojaku na serveru, 
konkretne ntpd/ntp_proto.c

Najdes
>         /*
>          * Is this a potential NAK?
>          */
>         if (remainder_size != 4) {
>                 return NONAK;
>         }

a ten 'if' prepises na

> if (remainder_size != 4 || (hismode == MODE_CLIENT && ntohl(((u_int32 *)(&rbufp->recv_pkt))[base_packet_length / 4]) == 0))

Bez zaruky, pochopitelne ...

>> Ja bych asi nebral cas z neznameho zdroje, vybiraneho podle ne prilis
>> zrejmych kriterii.
>
> Driv jsem pouzival jeden "znamy bezpecny" zdroj, ale ten uz neni,
> takze rozhodnout se pro nejaky jiny verejny je skoro stejne,
> jako tam nechat tuhle defaultni konfiguraci.


'si nemyslim. Porad znacne bezpecnejsi 'pouziju verejny NTP server 
provozovany me znamou osobou/organizaci' (jakkoli nemam garantovany jeho 
sluzby nebo presnost) pred 'pouziju nahodny zdroj ze seznamu, kam se 
dostane v podstate kazdy, kdo o to pozada'.

Ja prestal defaultni konfiguraci pouzivat, kdyz jsem jednou zjistil, ze 
obsahem aktualniho seznamu bylo v te chvili sest stroju, z nichz tri 
byly zcela nedostupne, jeden mel cas o skoro deset minut vedle a jen dva 
fungovaly jak maji.

Dan


More information about the Users-l mailing list