IP-ja e WAN ndryshoi dhe tuneli ra: kontrollet me radhë

Tuneli bie, router-i regjistron një rilidhje dhe asgjë në LAN nuk është lëvizur. Një adresë e re WAN e bën të pavlefshme lidhjen e jashtme pa ndryshuar asgjë brenda: adresa e burimit të klientit ka ndryshuar, gjendja e vjetër e NAT tregon një burim që nuk ekziston më dhe kolegu i largët mund të vazhdojë të dërgojë në adresën e mëparshme. Rikuperimi është sjellje normale dhe pyetja e dobishme është cila gjendje nuk u përditësua.

Emërtoni ngjarjen përpara se të lexoni regjistrin

Kontrolloni çfarë ndodhi në të vërtetë në shtresën e aksesit. Rinovimi i qirasë nga ofruesi është një ngjarje. Një sesion PPPoE që u rilidh është një tjetër. Një modem fibër që u rindez, ose një kalim dështimi i WAN nga një lidhje në tjetrën, ndryshon adresën e jashtme ose rrugën e saj në një mënyrë të tretë. Nuk janë e njëjta ngjarje dhe nuk lënë të njëjtat mbetje.

Një rresht rilidhjeje në regjistrin e VPN nuk është as provë e një ndryshimi WAN. Një afat i paveprimit, një interval riautentikimi dhe zbulimi i kolegut të vdekur prodhojnë të gjitha rilidhje pa asnjë ndryshim adrese. Krahasoni vulat kohore nga regjistri i aksesit me regjistrin e VPN përpara se të nxirrni ndonjë përfundim dhe mbani dritaren e krahasimit mjaft të gjerë për të kapur një ndryshim që ndodhi gjatë natës.

Roaming dhe rilidhja janë protokolle të ndryshme

WireGuard ka roaming të autentikuar të ndërtuar në protokol: kur një koleg merr një paketë të autentikuar saktë nga një adresë e re burimi, ai përditëson pikën fundore të atij kolegu. Fillimi i shpejtë i WireGuard përshkruan konfigurimin e kolegut që e bën këtë të mundur, prandaj një klient në një adresë që ndryshon shpesh rikuperohet pa një rindezje të dukshme.

OpenVPN sillet ndryshe si parazgjedhje. Një sesion UDP mund të përfundojë dhe të rilidhet, dhe sjellja opsionale float lejon një koleg të autentikuar të vazhdojë nga një adresë e re aty ku konfigurimi e lejon. Tunelet e bazuara në TCP janë më të rrepta, sepse vetë lidhja është e lidhur me çiftin e adresave. Ky ndryshim vendos nëse rikuperimi duket i padukshëm ose njoftohet në regjistër çdo herë.

Asnjëra sjellje nuk thotë asgjë për aplikacionet brenda. Një tunel i rikuperuar nuk rikthen një sesion TCP që kolegu tashmë e konsideronte të vdekur.

Gjendja që tuneli nuk e zotëron

Gjendja e përkthimit dhe e rrugëtimit i mbijeton rilidhjes në mënyra që i befasojnë njerëzit. Një zë conntrack i krijuar për burimin e vjetër e mban rrugën e përgjigjes të ankoruar në një adresë që nuk ekziston më dhe skadon sipas orarit të vet, jo kur u kthye tuneli. Rindezja e shërbimit të tunelit nuk e shkurton atë pritje, prandaj një lidhje e riparuar mund të duket ende e prishur për një kohë.

Rrugët dhe rregullat e politikës mund të referojnë gateway-in ose ndërfaqen e vjetër. Një grup rregullash që ishte i saktë përpara një ndryshimi WAN mund të tregojë një pajisje që tani është jashtë funksionit, gjë që prodhon një tunel që raportohet si i lidhur dhe trafik që nuk shkon askund. DNS dinamik për një server që e strehoni është një problem i veçantë nga ai i një klienti që merr një burim të re. Regjistrimi duhet përditësuar që klientët e largët t'ju gjejnë, dhe asnjë konfigurim në anën e klientit nuk e kompenson një adresë që përkthimi në rrjedhën e sipërme nuk do ta përçojë.

Renditni kontrollet nga jashtë brenda

Rendi më poshtë shkon nga lidhja e jashtme nga brenda, dhe ndalimi në hapin e parë që dështon është ajo që e bën të dobishëm: çdo kontrolle përjashton shtresën sipër. Mbani këtë rend edhe kur defekti duket i qartë.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Komanda e parë tregon pikën fundore aktuale dhe moshën e shtrëngimit të duarve për çdo koleg. E dyta dhe e treta tregojnë nëse ndërfaqja e jashtme dhe rruga drejt pikës fundore ende kanë kuptim. Numri i conntrack është një kontrolle e përafërt për gjendjen e mbetur nga adresa e mëparshme, dhe ditari është vendi ku regjistrohet arsyeja e rilidhjes.

Pastaj provoni nga një klient i LAN-it dhe jo nga router-i. Një ping i dërguar nga vetë router-i përdor një rrugë të ndryshme nga trafiku i përçuar, kështu që një ping i suksesshëm nga router-i provon se tuneli ekziston dhe asgjë për arritshmërinë e klientit.

Vendosni sjelljen e pritur dhe shkruajeni atë

Rilidhja është sjellja e saktë për shumicën e vendosjeve, prandaj qëllimi nuk është ta parandalosh atë. Vendosni në vend të kësaj çfarë duhet të ndodhë me trafikun gjatë hendekut: ta ndaloni, ta mbani ose të kaloni në një rrugë tjetër. Ky vendim i përket firewall-it dhe politikës së rrugëtimit, jo profilit të VPN.

Regjistroni ngjarjet e aksesit dhe kohët e rilidhjes së bashku për një javë. Ndryshimet e përsëritura pa një ngjarje aksesi që përputhet tregojnë shërbimin e aksesit, dhe zëvendësimi i profilit të VPN nuk do të rregullojë një lidhje që rinegocion vazhdimisht. Një palë e vetme zërash në të njëjtën minutë e zgjidh çështjen për atë incident dhe i jep një vijë bazë të tjetrit.