VPN morta post dormo: perdita tunelo aŭ kaduka aplikaĵo?

La kovrilo malfermiĝas, la sendrata ikono revenas, kaj la VPN ankoraŭ montriĝas konektita. La unua interna paĝo tiam pendas ĝis ĝi tempolimas, kaj nova langeto faras same. Tri malsamaj aferoj povas krei tiun bildon, kaj ili bezonas tri malsamajn riparojn: tunelo, kiu ne postvivis la dormon, profilo, kiun neniu petis reaktivigi, aŭ aplikaĵo, kiu ankoraŭ tenas seancon mortintan antaŭ horoj. Kompari ilin estas pli rapide ol reinstali ion ajn.

Tri aferoj povas rompiĝi post vekiĝo

La unua kandidato estas la tunelo mem. La interfaco povas ankoraŭ ekzisti kun adreso dum la ligo al la samtavolano malaperis, tial indikila lumo ne estas pruvo de funkcianta vojo. Manpremo pli malnova ol la dormo estas la signo, kaj unu komando sufiĉas por vidi ĝin.

La dua estas la aktivigo. Multaj klientoj rekonektiĝas mem; kelkaj ne, kaj profilo, kiun neniu petas reveni, sidas tie kaj aspektas agordita. Tiu malsukceso estas silenta laŭdezajne, ĉar nenio raportis eraron.

La tria estas la aplikaĵo. Retumila langeto, SSH-seanco aŭ datumbaza konekto povas postvivi retan ŝanĝon kiel dosierpriskribilo dum la transporto sub ĝi estas morta. Nova seanco tiam funkcias perfekte, kio diras al vi, ke la tunelo estis en ordo la tutan tempon.

Komparu la tri antaŭ ol ŝanĝi ion, ĉar la riparoj ne interkovriĝas. Restartigi klienton, kiun oni neniam petis restartigi, malŝparas la pruvon, kiun vi bezonis. Notu, al kiu kandidato la simptomo konvenas, antaŭ ol tuŝi agordon. Tiu unu frazo kutime decidas la restaĵon de la esploro.

Unue: ĉu la tunelo revenis?

Rigardu la interfacon kaj la staton de la samtavolano anstataŭ la statusan tekston de la kliento. Interfaco kun adreso kaj sen lastatempa manpremo estas tunelo, kiu ekzistas nur nome.

ip -brief addr show
wg show
ip route show table all | head -20

Se la interfaco tute mankas, la tunelo ne postvivis kaj la demando fariĝas, kiu devintus revenigi ĝin. Se ĝi ekzistas sed la manpremo estas malnova, la ligo al la samtavolano devas esti restarigita, kaj la kliento eble atendas trafikon por ekigi ĝin.

Kontrolu ankaŭ la itinerojn kaj la DNS-agordon. Tunelo povas reveni sen siaj itineroj, kio kreas la konfuzan staton, en kiu la interfaco funkcias kaj internaj nomoj ankoraŭ solviĝas per la malĝusta servilo.

Due: ĉu io petis ĝin reveni?

Ĉi tie la komparo valoras sian prezon. OpenVPN-kromaĵa profilo kaj denaska WireGuard-konekto estas traktataj malsame de NetworkManager, kaj la referenco pri konektaj agordoj klare diras, ke connection.autoconnect ne aktivigas VPN-profilojn; la mekanismo por levi VPN kun konekto estas connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Se permana rekonekto riparas la problemon ĉiufoje, tio estas la spuro de mankanta aktivigo, ne de rompita tunelo. La protokolo kutime montros la interfacon falantan kaj nenion revenigantan ĝin.

Rezistu la impulson aldoni dorman hokon tuj. Hoko, kiu ekfunkcias antaŭ ol la reto resaniĝis, vetkuras kun la sama procezo, kiun ĝi provas helpi, kaj transformas ripeteblan problemon en intermitan.

Trie: ĉu la aplikaĵo tenas malnovan staton?

Malfermu tute novan seancon al la sama celo antaŭ ol tuŝi la VPN. Se la nova seanco funkcias kaj la malnova ne, la tunelo estas en ordo kaj la aplikaĵo tenas mortan konekton.

Ĉi tio estas la plej malmultekosta el la tri kontroloj kaj la plej ofte preterlasata, ĉar la malsukcesa fenestro estas ĝuste sur la ekrano. Fermu ĝin, remalfermu ĝin, kaj notu, ĉu la problemo postvivas. Se la nova seanco funkcias, tute ĉesigu la esploradon de la tunelo. Se ĝi ankaŭ malsukcesas, la aplikaĵo estas simptomo, ne kaŭzo.

Kelkaj aplikaĵoj resaniĝas mem post tempolimo, tial povas ŝajni, ke la simptomo riparas sin post kelkaj minutoj. Tiu konduto montras al la aplikaĵo, ne al la tunelo, kaj indas noti ĝin aparte. Kolego, kiu diras, ke ĝi simple riparis sin, priskribas ĉi tiun ŝablonon, ne bonŝancon.

Faru la komparon ripetebla

Tenu la variablojn malgrandaj: unu alirreto, unu dormodaŭro kaj la sama unua peto ĉiufoje. Poste registru du rezultojn: ĉu permana rekonekto riparas ĝin, kaj ĉu plia dormo revenigas la malsukceson.

Tiu lasta observo estas la plej fidinde apartiganta la tri kandidatojn. Funkcianta nova seanco post malsukcesinta malnova ne estas tunela problemo, kaj neniu reinstalo de la kliento ŝanĝos tion.

La daŭra keepalive de WireGuard apartenas al ĉi tiu bildo nur kiel keepalive por NAT-mapado. Ĝi sendas pakaĵojn por teni mapadon malfermita; ĝi ne malhelpas la maŝinon dormi kaj ne povas daŭre sendi dum la procezo estas suspendita.

Notu en la bileto, kion vi trovis: kiu el la tri estis rompita, kio riparis ĝin kaj kiel vi reproduktis tion. La sekva persono, kiu lundon malfermos kovrilon, dankos vin, kaj la respondo ne devos esti retrovita de nulo.