WireGuard dështon pas pasivitetit: provoni së pari drejtimin

Katër pyetje vijnë përpara çdo ndryshimi të cilësimit: funksionon i njëjti burim ndërsa klienti është aktiv, sa zgjati periudha e pasivitetit, a fjeti pajisja apo ndryshoi rrjet, dhe a shfaqet dështimi vetëm në trafikun që fillon ana tjetër. Përgjigjet ndajnë një hartë NAT të skaduar nga një radio në gjumë dhe nga një aplikacion i vjetruar. Ato gjithashtu thonë nëse një keepalive është fare i rëndësishëm. Filloni me drejtimin, sepse kushton një komandë dhe eliminon gjysmën e shkaqeve të mundshme.

Cili drejtim dështon?

Një kërkesë e re dalëse nga klienti dhe trafiku që mbërrin drejt tij pas një periudhe të qetë testojnë ndryshe pajisjet me gjendje. Paketat dalëse rindërtojnë një hartë ndërsa largohen, ndërsa paketat hyrëse kanë nevojë që harta e vjetër të ketë mbijetuar. Kjo asimetri është i gjithë testi. Nëse klienti mund të dalë por asgjë nuk hyn, harta ndoshta ka skaduar, dhe nëse asnjëra nuk funksionon, tuneli ose aksesi në rrjet i klientit ka humbur.

Vini re sa zgjati periudha e qetë dhe nëse pajisja fjeti ose kaloi ndërkohë në një rrjet tjetër. Këto dy fakte ndryshojnë diagnozën përpara çdo cilësimi.

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

Ekzekutoni ata tre përpara dhe pas periudhës së qetë, sepse secili përgjigjet një pjese tjetër të pyetjes. Një vulë kohore handshake që nuk është lëvizur thotë që palët ndaluan së foluri, ndërsa një pikë fundore që ka ndryshuar thotë që harta u zhvendos në vend që të vdiste. Numëruesit e transferimit tregojnë nëse mbërriti gjë, dhe ky është ndryshimi midis një harte të vjetruar dhe një aplikacioni të heshtur. Shkruani numrat në të dyja pikat, sepse krahasimi është prova.

Gjumi, radio dhe gjendja e aplikacionit

Në një telefon ose laptop, një pajisje në gjumë mund të ketë humbur plotësisht aksesin në rrjet, dhe një keepalive nuk mund të rivendosë një radio të fikur ose të përfundojë një portë captive që nuk është plotësuar. Platformat mobile pezullojnë punën në sfond sipas politikës, prandaj nëse trafiku periodik vazhdon varet nga platforma dhe nga ajo që aplikacioni ka negociuar me të. Një lidhje e ruajtur në cache është rasti i tretë dhe më mashtruesi, sepse kthimi i tunelit nuk është i njëjtë me rilidhjen e aplikacionit me të.

Rihapni aplikacionin pas periudhës së pasivitetit në vend që t'i besoni skedës që mbeti e hapur. Nëse një kërkesë e re ka sukses atje ku sesioni i vjetër dështoi, tuneli nuk ishte kurrë problemi.

Çfarë bën në të vërtetë keepalive

PersistentKeepalive dërgon periodikisht një paketë boshe të vërtetuar te një palë, që mjafton për të mbajtur gjallë një hartë NAT midis palëve dhe për ta mbajtur pikën fundore të anës tjetër të përditësuar, siç përshkruan nisja e shpejtë e WireGuard. Nuk riparon një radio në gjumë, një rrugë të humbur ose një aplikacion që nuk provon kurrë përsëri. Zgjidhni intervalin përmes cilësimeve të mbështetura të klientit dhe mos aktivizoni një vlerë agresive kudo vetëm sepse një ekran statusi hesht.

Shumica e periudhave të pasivitetit nuk janë dështime. Një tunel që rilidhet pas pesë minutash heshtjeje sillet saktë, dhe problemi është vetëm rasti kur diçka duhej të mbërrinte nga ana tjetër.

Prisni intervalin që dështonte më parë

Bëni një ndryshim të mbështetur, pastaj lërini të kalojë e njëjta periudhë pasiviteti përpara se ta testoni përsëri atë burim. Pritja është pjesë e testit dhe jo formalitet. Suksesi i menjëhershëm pas një rilidhjeje nuk thotë asgjë për një simptom të pasivitetit të gjatë, sepse rilidhja është pikërisht ngjarja që rivendos gjendjen. Nëse problemi shfaqet edhe gjatë përdorimit aktiv, kthehuni te kontrollet e handshake dhe të rrugës së të dhënave në vend që të shtoni më shumë trafik periodik.

Mbani një ndryshim për test dhe shkruani kohëzgjatjen e pasivitetit të përdorur. Pa këtë, çdo krahasim i mëvonshëm devijon dhe askush nuk mund të thotë cili ndryshim kishte rëndësi. Regjistroni katër faktet së bashku: drejtimi, kohëzgjatja, gjendja e gjumit dhe sjellja e aplikacionit.