WireGuard misluk ná rus: toets eers die rigting

Vier vrae kom voor enige instellingsverandering: werk dieselfde bron terwyl die kliënt aktief is, hoe lank was die onaktiewe tydperk, het die toestel geslaap of van netwerk verander, en verskyn die fout slegs by verkeer wat van die oorkant begin is. Die antwoorde skei ’n vervalle NAT-kaart van ’n slapende radio en van ’n verouderde toepassing. Hulle sê ook of ’n keepalive hoegenaamd tersaaklik is. Begin met die rigting, want dit kos een opdrag en skakel die helfte van die moontlike oorsake uit.

Watter rigting misluk?

’n Nuwe uitgaande versoek van die kliënt en verkeer wat ná ’n stil tydperk na hom toe aankom, belas staatvolle toerusting verskillend. Uitgaande pakkette bou ’n kaart op terwyl hulle vertrek, terwyl inkomende pakkette nodig het dat die ou kaart oorleef het. Dié asimmetrie is die hele toets. As die kliënt kan uitreik maar niks inkom, het die kaart waarskynlik verval, en as nie een werk nie, is die tonnel of die kliënt se netwerktoegang weg.

Let op hoe lank die stil tydperk geduur het, en of die toestel geslaap het of intussen na ’n ander netwerk oorgeskakel het. Dié twee feite verander die diagnose voordat enige instelling dit doen.

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

Voer daardie drie voor en ná die stil tydperk uit, want elkeen beantwoord ’n ander deel van die vraag. ’n Handshake-tydstempel wat nie beweeg het nie, sê die eweknieë het opgehou praat, terwyl ’n eindpunt wat verander het sê die kaart het geskuif eerder as om te sterf. Die oordragtellers wys of enigiets hoegenaamd aangekom het, wat die verskil is tussen ’n verouderde kaart en ’n stille toepassing. Skryf die getalle by albei punte neer, want die vergelyking is die bewys.

Slaap, radio en toestand van die toepassing

Op ’n selfoon of skootrekenaar het ’n slapende toestel dalk heeltemal netwerktoegang verloor, en ’n keepalive kan nie ’n radio wat af is herstel of ’n captive portal voltooi wat nie bevredig is nie. Mobiele platforms staak agtergrondwerk as ’n beleidsaak, so of periodieke verkeer voortduur hang af van die platform en van wat die app daarmee onderhandel het. ’n Gekasde verbinding is die derde geval en die mees misleidende, want die tonnel wat terugkom is nie dieselfde as die toepassing wat weer daaraan koppel nie.

Maak die toepassing ná die onaktiewe tydperk weer oop in plaas daarvan om die oopgetekende oortjie te vertrou. As ’n nuwe versoek slaag waar die ou sessie gefaal het, was die tonnel nooit die probleem nie.

Wat ’n keepalive werklik doen

PersistentKeepalive stuur ’n periodieke geauthentiseerde leë pakket na ’n eweknie, wat genoeg is om ’n NAT-kaart tussen eweknieë lewendig te hou en om die eweknie se eindpunt aktueel te laat bly, soos die vinnige begin van WireGuard beskryf. Dit herstel nie ’n slapende radio, ’n verlore roete of ’n toepassing wat nooit weer probeer nie. Kies die interval deur die ondersteunde kliëntinstellings, en moenie ’n aggressiewe waarde oral aktiveer net omdat ’n statusvertoning stil word nie.

Die meeste onaktiewe tydperke is nie foute nie. ’n Tonnel wat ná vyf minute van stilte weer koppel, gedra hom korrek, en die probleem is slegs die geval waar iets van die oorkant moes aankom.

Wag deur die interval wat vroeër gefaal het

Maak een ondersteunde verandering, en laat dan dieselfde onaktiewe tydperk verbygaan voordat jy daardie bron weer toets. Wag is deel van die toets eerder as ’n formaliteit. Onmiddellike sukses ná ’n herkoppeling sê niks oor ’n lang-onaktiewe simptoom nie, want herkoppeling is juis die gebeurtenis wat die toestand terugstel. As die probleem ook tydens aktiewe gebruik verskyn, gaan terug na handshake- en datapadkontroles eerder as om meer periodieke verkeer by te voeg.

Hou een verandering per toets en skryf die gebruikte onaktiewe duur neer. Sonder dit dryf elke latere vergelyking weg en niemand kan sê watter verandering saak gemaak het nie. Teken die vier feite saam aan: rigting, duur, slaaptoestand en gedrag van die toepassing.