WireGuard zataji po mirovanju: najprej preizkusite smer

Pred vsako spremembo nastavitve stojijo štiri vprašanja: ali isto sredstvo deluje, dokler je odjemalec aktiven, kako dolgo je trajalo obdobje mirovanja, ali je naprava spala ali zamenjala omrežje, in ali se napaka pojavi samo v prometu, ki ga začne nasprotna stran. Odgovori ločijo poteklo preslikavo NAT od spečega radia in od zastarele aplikacije. Povedo tudi, ali je keepalive sploh pomemben. Začnite s smerjo, ker stane en ukaz in izloči polovico možnih vzrokov.

Katera smer zataji?

Nova odhodna zahteva odjemalca in promet, ki po tihem obdobju prihaja proti njemu, različno obremenjujeta opremo s stanjem. Odhodni paketi ob odhodu obnovijo preslikavo, medtem ko dohodni paketi potrebujejo, da je stara preslikava preživela. Ta asimetrija je celoten test. Če odjemalec lahko pride ven, a nič ne pride noter, je preslikava verjetno potekla, in če ne deluje nobeno, je tunel ali omrežni dostop odjemalca izginil.

Zabeležite, kako dolgo je trajalo tiho obdobje in ali je naprava spala ali se medtem preselila v drugo omrežje. Ti dve dejstvi spremenita diagnozo prej kot katera koli nastavitev.

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Zaženite tiste tri pred tihim obdobjem in po njem, ker vsak odgovarja na drug del vprašanja. Časovni žig handshake, ki se ni premaknil, pravi, da sta strani prenehali govoriti, medtem ko spremenjena končna točka pravi, da se je preslikava premaknila, ne umrla. Števci prenosa pokažejo, ali je sploh kaj prispelo, in to je razlika med poteklo preslikavo in tiho aplikacijo. Zapišite številke na obeh točkah, ker je primerjava dokaz.

Spanje, radio in stanje aplikacije

V telefonu ali prenosniku je speča naprava morda popolnoma izgubila omrežni dostop, keepalive pa ne more obnoviti izklopljenega radia ali dokončati captive portala, ki ni bil izpolnjen. Mobilne platforme po pravilniku ustavijo delo v ozadju, zato je nadaljevanje občasnega prometa odvisno od platforme in od tega, kar se je aplikacija z njo dogovorila. Predpomnjena povezava je tretji primer in najbolj zavajajoč, ker vrnitev tunela ni isto kot ponovna povezava aplikacije z njim.

Po obdobju mirovanja znova odprite aplikacijo, namesto da bi zaupali zavihku, ki je ostal odprt. Če nova zahteva uspe tam, kjer je stara seja spodletela, tunel nikoli ni bil težava.

Kaj keepalive v resnici počne

PersistentKeepalive redno pošilja overjen prazen paket partnerju, kar zadošča za ohranjanje preslikave NAT med partnerji in za ohranjanje aktualne končne točke druge strani, kot opisuje hitri začetek WireGuard. Ne popravi spečega radia, izgubljene poti ali aplikacije, ki nikoli ne poskusi znova. Interval izberite v podprtih nastavitvah odjemalca in ne vklopite agresivne vrednosti povsod samo zato, ker statusni prikaz utihne.

Večina obdobij mirovanja ni napak. Tunel, ki se po petih minutah tišine znova poveže, se obnaša pravilno, in težava je le primer, ko bi z nasprotne strani moralo priti nekaj.

Počakajte interval, ki je prej zatajil

Naredite eno podprto spremembo, nato počakajte, da preteče isto obdobje mirovanja, preden to sredstvo znova preizkusite. Čakanje je del testa, ne formalnost. Takojšen uspeh po ponovni povezavi ne pove ničesar o simptomu dolgega mirovanja, ker je ponovna povezava prav tisti dogodek, ki ponastavi stanje. Če se težava pojavi tudi med aktivno uporabo, se vrnite k preverjanjem handshake in podatkovne poti, namesto da dodajate več občasnega prometa.

Obdržite eno spremembo na test in zapišite uporabljeno trajanje mirovanja. Brez tega vsaka poznejša primerjava zanese in nihče ne more reči, katera sprememba je bila pomembna. Zapišite štiri dejstva skupaj: smer, trajanje, stanje spanja in vedenje aplikacije.