WAN IP se promijenio i tunel je pao: provjere po redu

Tunel padne, ruter zabilježi ponovno povezivanje, a na LAN-u se ništa nije pomjerilo. Nova WAN adresa poništava vanjsku vezu bez ikakve promjene unutra: izvorna adresa klijenta se promijenila, staro NAT stanje pokazuje na izvor koji više ne postoji, a udaljeni partner možda još šalje na prethodnu adresu. Oporavak je normalno ponašanje, a korisno pitanje je koje stanje nije ažurirano.

Imenujte događaj prije nego što pročitate dnevnik

Provjerite šta se zaista dogodilo na pristupnom sloju. Obnova ISP zakupa je jedan događaj. PPPoE sesija koja se ponovo povezala je drugi. Fiber modem koji se restartovao, ili WAN prebacivanje s jednog uplinka na drugi, mijenja vanjsku adresu ili njen put na treći način. To nije isti događaj i ne ostavljaju isti talog.

Linija ponovnog povezivanja u VPN dnevniku takođe nije dokaz WAN promjene. Taimaut mirovanja, interval ponovne autentifikacije i otkrivanje mrtvog partnera svi proizvode ponovna povezivanja bez ikakve promjene adrese. Uporedite vremenske oznake iz pristupnog dnevnika s VPN dnevnikom prije nego što bilo šta zaključite, i držite prozor poređenja dovoljno širokim da uhvatite promjenu koja se dogodila tokom noći.

Roaming i ponovno povezivanje su različiti protokoli

WireGuard ima ugrađeni autentificirani roaming: kada partner primi ispravno autentificiran paket s nove izvorne adrese, ažurira krajnju točku tog partnera. WireGuard brzi početak opisuje konfiguraciju partnera koja to omogućava, zbog čega se klijent na promjenljivoj adresi često oporavlja bez vidljivog restarta.

OpenVPN se po defaultu ponaša drugačije. UDP sesija može završiti i ponovo se povezati, a opcionalno float ponašanje omogućava autentificiranom partneru da nastavi s nove adrese tamo gdje konfiguracija to dopušta. Tuneli zasnovani na TCP-u su stroži, jer je sama veza vezana za par adresa. Ta razlika odlučuje hoće li oporavak izgledati nevidljivo ili će se svaki put najaviti u dnevniku.

Ni jedno ponašanje ne govori ništa o aplikacijama unutra. Oporavljeni tunel ne vraća TCP sesiju koju je partner već smatrao mrtvom.

Stanje koje tunel ne posjeduje

Stanje prevođenja i usmjeravanja preživljava ponovno povezivanje na načine koji iznenađuju ljude. conntrack unos stvoren za stari izvor drži put odgovora usidrenim na adresu koja više ne postoji, i istječe po vlastitom rasporedu, a ne kada se tunel vratio. Restartovanje tunel servisa ne skraćuje to čekanje, pa popravljena veza još neko vrijeme može izgledati pokvareno.

Rute i pravila politike mogu referencirati stari gateway ili interfejs. Skup pravila koji je bio ispravan prije WAN prebacivanja može pokazivati na uređaj koji je sada isključen, što stvara tunel koji se prijavljuje kao povezan i saobraćaj koji nikuda ne ide. Dinamički DNS za server koji hostujete odvojen je problem od klijenta koji dobija novi izvor. Zapis treba ažurirati da bi vas udaljeni klijenti našli, a nijedna konfiguracija na strani klijenta ne nadoknađuje adresu koju prevođenje dalje uzvodno neće proslijediti.

Poredajte provjere od vanjskog prema unutrašnjem

Redoslijed ispod ide od vanjske veze prema unutra, i zaustavljanje na prvom koraku koji ne uspije je ono što ga čini korisnim: svaki prolaz isključuje sloj iznad sebe. Držite taj redoslijed čak i kada kvar izgleda očigledno.

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

Prva naredba pokazuje trenutnu krajnju točku i starost rukovanja za svakog partnera. Druga i treća pokazuju da li vanjski interfejs i ruta do krajnje točke još imaju smisla. conntrack broj je gruba provjera stanja zaostalog od prethodne adrese, a dnevnik je mjesto gdje se bilježi razlog ponovnog povezivanja.

Zatim testirajte s LAN klijenta, a ne s rutera. Ping koji šalje sam ruter koristi drugačiji put od proslijeđenog saobraćaja, pa uspješan ping s rutera dokazuje da tunel postoji i ništa o dostupnosti klijenta.

Odredite očekivano ponašanje i zapišite ga

Ponovno povezivanje je ispravno ponašanje za većinu postavki, pa cilj nije spriječiti ga. Umjesto toga odlučite šta treba da se dogodi sa saobraćajem tokom prekida: zaustaviti ga, zadržati ili prebaciti na drugi put. Ta odluka pripada firewallu i politici usmjeravanja, a ne VPN profilu.

Bilježite pristupne događaje i vremena ponovnog povezivanja zajedno nedjelju dana. Ponovljene promjene bez odgovarajućeg pristupnog događaja ukazuju na pristupnu uslugu, a zamjena VPN profila neće popraviti uplink koji stalno iznova pregovara. Jedan par unosa u istoj minuti rješava pitanje za taj incident i daje sljedećem osnovnu liniju.