VPN i vdekur pas gjumit: tunel i humbur apo aplikacion i vjetruar?

Kapaku hapet, ikona pa tel kthehet dhe VPN vazhdon të shfaqet si i lidhur. Faqja e parë e brendshme më pas ngec derisa të skadojë koha, dhe një skedë e re bën të njëjtën gjë. Tri gjëra të ndryshme mund të krijojnë atë pamje dhe kërkojnë tre rregullime të ndryshme: një tunel që nuk i mbijetoi gjumit, një profil që askush nuk kërkoi ta riaktivizojë, ose një aplikacion që ende mban një sesion që vdiq orë më parë. Krahasimi i tyre është më i shpejtë se riinstalimi i çdo gjëje.

Tri gjëra mund të prishen pas zgjimit

Kandidati i parë është vetë tuneli. Ndërfaqja mund të ekzistojë ende me një adresë ndërsa lidhja me homologun ka humbur, prandaj një dritë treguese nuk është provë e një rruge funksionale. Një shtrëngim duarsh më i vjetër se gjumi është shenja, dhe mjafton një komandë për ta parë.

E dyta është aktivizimi. Shumë klientë rilidhen vetë; disa jo, dhe një profil që askush nuk e fton të kthehet qëndron aty dhe duket i konfiguruar. Ai dështim është i heshtur nga dizajni, sepse asgjë nuk raportoi gabim.

E treta është aplikacioni. Një skedë shfletuesi, një sesion SSH ose një lidhje me bazë të dhënash mund t'i mbijetojnë një ndryshimi rrjeti si përshkrues skedari ndërsa transporti poshtë tyre është i vdekur. Atëherë një sesion i ri funksionon në mënyrë të përsosur, gjë që ju tregon se tuneli ishte në rregull gjatë gjithë kohës.

Krahasoni të treja përpara se të ndryshoni çdo gjë, sepse rregullimet nuk mbivendosen. Rinisja e një klienti që nuk u ftua kurrë të nisej përsëri harxhon provën që ju duhej. Shkruani se cilit kandidat i përshtatet simptoma përpara se të prekni një konfigurim. Ai një fjali e vendos zakonisht pjesën tjetër të hetimit.

Së pari: a u kthye tuneli?

Shikoni ndërfaqen dhe gjendjen e homologut në vend të tekstit të statusit të klientit. Një ndërfaqe me adresë dhe pa shtrëngim duarsh të fundit është një tunel që ekziston vetëm me emër.

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

Nëse ndërfaqja mungon plotësisht, tuneli nuk mbijetoi dhe pyetja bëhet kush duhej ta kthente. Nëse është aty por shtrëngimi i duarve është i vjetër, lidhja me homologun duhet rikrijuar, dhe klienti mund të presë trafik që ta aktivizojë.

Kontrolloni gjithashtu rrugët dhe konfigurimin DNS. Tuneli mund të kthehet pa rrugët e tij, gjë që krijon gjendjen konfuze ku ndërfaqja është aktive dhe emrat e brendshëm zgjidhen ende përmes serverit të gabuar.

Së dyti: a kërkoi diçka kthimin e tij?

Këtu krahasimi e fiton vendin e vet. Një profil shtojce OpenVPN dhe një lidhje vendase WireGuard trajtohen ndryshe nga NetworkManager, dhe referenca e cilësimeve të lidhjes thotë qartë se connection.autoconnect nuk aktivizon profile VPN; mekanizmi për të ngritur një VPN bashkë me një lidhje është connection.secondaries.

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

Nëse rilidhja manuale e rregullon problemin çdo herë, ky është nënshkrimi i një aktivizimi që mungon dhe jo i një tuneli të prishur. Regjistri zakonisht tregon ndërfaqen duke rënë dhe asgjë që e kthen atë.

Rezistoni impulsit për të shtuar menjëherë një grep gjumi. Një grep që aktivizohet përpara se rrjeti të jetë rikuperuar garon me të njëjtin proces që përpiqet të ndihmojë, dhe e shndërron një problem të riprodhueshëm në një të herëpashershëm.

Së treti: a mban aplikacioni gjendje të vjetër?

Hapni një sesion krejt të ri drejt të njëjtit destinacion përpara se të prekni VPN. Nëse sesioni i ri funksionon dhe ai i vjetri jo, tuneli është në rregull dhe aplikacioni mban një lidhje të vdekur.

Ky është më i lirë nga tre kontrollet dhe ai që anashkalohet më shpesh, sepse dritarja që dështon është pikërisht në ekran. Mbylleni, rihapeni dhe vini re nëse problemi mbijeton. Nëse sesioni i ri funksionon, ndaloni plotësisht hetimin e tunelit. Nëse edhe ai dështon, aplikacioni është simptom dhe jo shkak.

Disa aplikacione rikuperohen vetë pas një afati, prandaj simptoma mund të duket se rregullohet vetë pas disa minutash. Ajo sjellje tregon aplikacionin dhe jo tunelin, dhe ia vlen të regjistrohet veçmas. Një koleg që thotë se u rregullua thjesht vetë po përshkruan këtë model, jo fat.

Bëjeni krahasimin të riprodhueshëm

Mbajini variablat të vegjël: një rrjet aksesi, një kohëzgjatje gjumi dhe i njëjti kërkesë e parë çdo herë. Pastaj regjistroni dy rezultate: nëse rilidhja manuale e rregullon, dhe nëse një gjumë tjetër e kthen dështimin.

Pikërisht vëzhgimi i fundit i ndan tre kandidatët në mënyrën më të besueshme. Një sesion i ri që funksionon pas një të vjetri të dështuar nuk është problem tuneli, dhe asnjë riinstalim i klientit nuk do ta ndryshojë atë.

Keepalive i vazhdueshëm i WireGuard përfshihet në këtë pamje vetëm si keepalive i mapimit NAT. Ai dërgon paketa për të mbajtur një mapim të hapur; nuk e pengon makinën të flejë dhe nuk mund të vazhdojë dërgimin ndërsa procesi është i pezulluar.

Regjistroni në tiketë çfarë gjetët: cila nga të treja ishte e prishur, çfarë e rregulloi dhe si e riprodhove. Personi tjetër që hap një kapak të hënën do t'ju falënderojë, dhe përgjigja nuk do të duhet të zbulohet përsëri nga e para.