Patru întrebări precedă orice modificare de setare: aceeași resursă funcționează cât timp clientul este activ, cât a durat perioada de inactivitate, dispozitivul a adormit sau a schimbat rețeaua, și defecțiunea apare doar în traficul inițiat de cealaltă parte. Răspunsurile separă o mapare NAT expirată de un radio adormit și de o aplicație învechită. Ele spun și dacă un keepalive este măcar relevant. Începeți cu direcția, pentru că aceasta costă o comandă și elimină jumătate din cauzele posibile.

Care direcție eșuează?

O cerere de ieșire nouă a clientului și traficul care sosește spre el după o perioadă liniștită testează diferit echipamentele cu stare. Pachetele de ieșire reconstruiesc o mapare la plecare, în timp ce pachetele de intrare au nevoie ca vechea mapare să fi supraviețuit. Această asimetrie este tot testul. Dacă clientul poate ieși, dar nimic nu intră, maparea probabil a expirat, iar dacă niciuna nu funcționează, tunelul sau accesul la rețea al clientului a dispărut.

Notați cât a durat perioada liniștită și dacă dispozitivul a adormit sau a trecut între timp la altă rețea. Aceste două fapte schimbă diagnosticul înaintea oricărei setări.

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

Rulați cele trei înainte și după perioada liniștită, pentru că fiecare răspunde la o parte diferită a întrebării. Un marcaj de timp handshake care nu s-a mișcat spune că părțile au încetat să vorbească, în timp ce un punct final care s-a schimbat spune că maparea s-a deplasat, nu a murit. Contoarele de transfer arată dacă a sosit ceva, și aceasta este diferența dintre o mapare învechită și o aplicație tăcută. Notați numerele în ambele puncte, pentru că comparația este dovada.

Somn, radio și starea aplicației

Pe un telefon sau laptop, un dispozitiv adormit poate să fi pierdut complet accesul la rețea, iar un keepalive nu poate restabili un radio oprit sau finaliza un portal captiv care nu a fost satisfăcut. Platformele mobile suspendă munca de fundal ca politică, așa că dacă traficul periodic continuă depinde de platformă și de ce a negociat aplicația cu ea. O conexiune din cache este al treilea caz și cel mai înșelător, pentru că întoarcerea tunelului nu este același lucru cu reconectarea aplicației la el.

Redeschideți aplicația după perioada de inactivitate în loc să vă bazați pe fila care a rămas deschisă. Dacă o cerere nouă reușește unde sesiunea veche a eșuat, tunelul nu a fost niciodată problema.

Ce face de fapt un keepalive

PersistentKeepalive trimite periodic un pachet gol autentificat unui peer, ceea ce este suficient pentru a menține vie o mapare NAT între peers și pentru a menține actualizat punctul final al celeilalte părți, așa cum descrie pornirea rapidă a WireGuard. Nu repară un radio adormit, o rută pierdută sau o aplicație care nu mai reîncearcă niciodată. Alegeți intervalul prin setările de client acceptate și nu activați o valoare agresivă peste tot doar pentru că un afișaj de stare devine tăcut.

Majoritatea perioadelor de inactivitate nu sunt defecțiuni. Un tunel care se reconectează după cinci minute de tăcere se comportă corect, iar problema este doar cazul în care ceva trebuia să sosească de la cealaltă parte.

Așteptați intervalul care eșua înainte

Faceți o singură modificare acceptată, apoi lăsați aceeași perioadă de inactivitate să treacă înainte de a retesta resursa. Așteptarea face parte din test, nu este o formalitate. Succesul imediat după o reconectare nu spune nimic despre un simptom de inactivitate lungă, pentru că reconectarea este exact evenimentul care resetează starea. Dacă problema apare și în timpul utilizării active, reveniți la verificările de handshake și de cale a datelor în loc să adăugați mai mult trafic periodic.

Păstrați o singură modificare pe test și notați durata de inactivitate folosită. Fără asta, fiecare comparație ulterioară derivează și nimeni nu poate spune care modificare a contat. Înregistrați cele patru fapte împreună: direcție, durată, stare de somn și comportamentul aplicației.

Articole similare