WireGuard fiaskas post senaktiveco: unue testu la direkton

Kvar demandoj antaŭas ĉiun ŝanĝon de agordo: ĉu la sama resurso funkcias dum la kliento estas aktiva, kiom longe daŭris la senaktiveco, ĉu la aparato dormis aŭ ŝanĝis reton, kaj ĉu la fiasko aperas nur por trafiko iniciatita de la kontraŭa flanko. La respondoj apartigas eksvalidiĝintan NAT-mapadon de dormanta radio kaj de malaktuala aplikaĵo. Ili ankaŭ diras, ĉu keepalive entute gravas. Komencu per la direkto, ĉar ĝi kostas unu komandon kaj forigas duonon de la eblaj kaŭzoj.

Kiu direkto fiaskas?

Nova elvenanta peto de la kliento kaj trafiko alvenanta al ĝi post kvieta periodo malsame ŝarĝas statan ekipaĵon. Elvenantaj pakaĵoj rekonstruas mapadon dum ili foriras, dum envenantaj pakaĵoj bezonas, ke la malnova mapado pluvivis. Tiu asimetrio estas la tuta testo. Se la kliento povas atingi eksteren sed nenio alvenas enen, la mapado verŝajne eksvalidiĝis, kaj se neniu el ili funkcias, la tunelo aŭ la reta aliro de la kliento malaperis.

Notu, kiom longe daŭris la kvieta periodo, kaj ĉu la aparato dormis aŭ transiris al alia reto dum tio. Tiuj du faktoj ŝanĝas la diagnozon antaŭ ol iu ajn agordo tion faras.

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

Rulu tiujn tri antaŭ kaj post la kvieta periodo, ĉar ĉiu respondas al malsama parto de la demando. Handshake-temposigno, kiu ne moviĝis, diras, ke la partneroj ĉesis paroli, dum finpunkto, kiu ŝanĝiĝis diras, ke la mapado moviĝis anstataŭ morti. La transigaj nombriloj montras, ĉu io ajn alvenis, kaj tio estas la diferenco inter eksvalidiĝinta mapado kaj silenta aplikaĵo. Skribu la nombrojn ĉe ambaŭ punktoj, ĉar la komparo estas la pruvo.

Dormo, radio kaj stato de la aplikaĵo

Sur telefono aŭ tekkomputilo, dormanta aparato eble tute perdis retan aliron, kaj keepalive ne povas restarigi malŝaltitan radion nek fini captive-portalon, kiun oni ne plenumis. Movoblaj platformoj suspendas fonan laboron laŭ politiko, do ĉu perioda trafiko daŭras dependas de la platformo kaj de tio, pri kio la aplikaĵo interkonsentis kun ĝi. Kaŝmemorita konekto estas la tria kazo kaj la plej trompa, ĉar la reveno de la tunelo ne samas al rekonekto de la aplikaĵo al ĝi.

Remalfermu la aplikaĵon post la senaktiveco anstataŭ fidi la langeton, kiu restis malferma. Se freŝa peto sukcesas tie, kie la malnova seanco fiaskis, la tunelo neniam estis la problemo.

Kion keepalive fakte faras

PersistentKeepalive periode sendas aŭtentigitan malplenan pakaĵon al partnero, kio sufiĉas por teni NAT-mapadon viva inter partneroj kaj por teni la finpunkton de la kontraŭa flanko aktuala, kiel priskribas la rapida komenco de WireGuard. Ĝi ne riparas dormantan radion, perditan itineron aŭ aplikaĵon, kiu neniam reprovos. Elektu la intervalon per la subtenataj klientaj agordoj, kaj ne ebligu agreseman valoron ĉie nur ĉar statusa montrilo silentas.

Plej multaj senaktivecaj periodoj ne estas fiaskoj. Tunelo, kiu rekonektiĝas post kvin minutoj da silento, kondutas ĝuste, kaj la problemo estas nur la kazo, kiam io devintus alveni de la kontraŭa flanko.

Atendu la intervalon, kiu antaŭe fiaskis

Faru unu subtenatan ŝanĝon, poste lasu la saman senaktivecan periodon pasi antaŭ ol retesti tiun resurson. Atendado estas parto de la testo, ne formaleco. Tuja sukceso post rekonekto diras nenion pri longa senaktiveca simptomo, ĉar rekonekto estas ĝuste la okazaĵo, kiu resetas la staton. Se la problemo aperas ankaŭ dum aktiva uzo, revenu al kontroloj de handshake kaj datenvojo anstataŭ aldoni plian periodan trafikon.

Tenu unu ŝanĝon por testo kaj skribu la uzitan senaktivecan daŭron. Sen tio ĉiu posta komparo drivas kaj neniu povas diri, kiu ŝanĝo gravis. Notu la kvar faktojn kune: direkton, daŭron, dormostaton kaj konduton de la aplikaĵo.