WireGuard neizdodas pēc dīkstāves: vispirms pārbaudiet virzienu
Beigta NAT kartēšana, guļošs radio un novecojusi programma pēc klusuma perioda izskatās vienādi. Pirms pievienot keepalive, pārbaudiet ienākošo un izejošo trafiku atsevišķi.
Pirms jebkuras iestatījuma izmaiņas ir četri jautājumi: vai tas pats resurs darbojas, kamēr klients ir aktīvs, cik ilgi ilga dīkstāves periods, vai ierīce gulēja vai nomainīja tīklu, un vai kļūme parādās tikai trafikā, ko sāk pretējā puse. Atbildes atdala beigtu NAT kartēšanu no guļoša radio un no novecojušas programmas. Tās arī pasaka, vai keepalive vispār ir būtisks. Sāciet ar virzienu, jo tas maksā vienu komandu un izslēdz pusi iespējamo iemeslu.
Kurš virziens neizdodas?
Jauns izejošs klienta pieprasījums un trafiks, kas pēc klusuma perioda pienāk pie tā, dažādi pārbauda stāvokļa aprīkojumu. Izejošās paketes izejot atjauno kartēšanu, bet ienākošajām paketēm ir vajadzīgs, lai vecā kartēšana būtu izdzīvojusi. Šī asimetrija ir viss tests. Ja klients var iziet, bet nekas neienāk, kartēšana, iespējams, ir beigusies, un, ja neviens nedarbojas, tunelis vai klienta tīkla piekļuve ir zudusi.
Pierakstiet, cik ilgi ilga klusuma periods un vai ierīce gulēja vai starplaikā pārgāja uz citu tīklu. Šie divi fakti maina diagnozi pirms jebkura iestatījuma.
wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer
Palaidiet šos trīs pirms klusuma perioda un pēc tā, jo katrs atbild uz citu jautājuma daļu. Neizkustējies handshake laika zīmogs saka, ka puses pārtrauca runāt, bet nomainījies galapunkts saka, ka kartēšana pārvietojās, nevis nomira. Pārsūtīšanas skaitītāji parāda, vai vispār kaut kas pienāca, un tā ir atšķirība starp novecojušu kartēšanu un klusu programmu. Pierakstiet skaitļus abos punktos, jo salīdzinājums ir pierādījums.
Miegs, radio un programmas stāvoklis
Tālrunī vai portatīvajā datorā guļoša ierīce var būt pilnībā zaudējusi tīkla piekļuvi, un keepalive nevar atjaunot izslēgtu radio vai pabeigt neapmierinātu captive portal. Mobilās platformas pēc politikas aptur fona darbu, tāpēc tas, vai periodiskais trafiks turpinās, ir atkarīgs no platformas un no tā, par ko programma ar to vienojusies. Kešatmiņā saglabāts savienojums ir trešais gadījums un visvairāk maldinošais, jo tuneļa atgriešanās nav tas pats, kas programmas atkārtota savienošanās ar to.
Pēc dīkstāves perioda atkārtoti atveriet programmu, nevis paļaujieties uz atvērtu palikušo cilni. Ja jauns pieprasījums izdodas tur, kur vecā sesija neizdevās, tunelis nekad nav bijis problēma.
Ko keepalive patiesībā dara
PersistentKeepalive periodiski sūta autentificētu tukšu paketi partnerim, un ar to pietiek, lai uzturētu NAT kartēšanu starp partneriem dzīvu un pretējās puses galapunktu aktuālu, kā apraksta WireGuard ātrā palaišana. Tas nelabo guļošu radio, zaudētu maršrutu vai programmu, kas nekad nemēģina vēlreiz. Izvēlieties intervālu ar atbalstītajiem klienta iestatījumiem un neiespējojiet agresīvu vērtību visur tikai tāpēc, ka statusa displejs kļūst kluss.
Lielākā daļa dīkstāves periodu nav kļūmes. Tunelis, kas pēc piecām minūtēm klusuma atkal pievienojas, uzvedas pareizi, un problēma ir tikai gadījums, kad kaut kam bija jāpienāk no pretējās puses.
Nogaidiet intervālu, kas agrāk neizdevās
Veiciet vienu atbalstītu izmaiņu, pēc tam ļaujiet paiet tam pašam dīkstāves periodam, pirms atkārtoti pārbaudāt šo resursu. Gaidīšana ir testa daļa, nevis formalitāte. Tūlītēji panākumi pēc atkārtotas pievienošanās neko neizsaka par ilgas dīkstāves simptomu, jo atkārtota pievienošanās ir tieši tas notikums, kas atiestata stāvokli. Ja problēma parādās arī aktīvas lietošanas laikā, atgriezieties pie handshake un datu ceļa pārbaudēm, nevis pievienojiet vairāk periodiska trafika.
Turiet vienu izmaiņu vienā testā un pierakstiet izmantoto dīkstāves ilgumu. Bez tā katrs vēlākais salīdzinājums noslīd un neviens nevar pateikt, kura izmaiņa bija svarīga. Pierakstiet četrus faktus kopā: virzienu, ilgumu, miega stāvokli un programmas uzvedību.