Naslov IP WAN se je spremenil in tunel je padel: preverjanja po vrsti

Tunel pade, usmerjevalnik zabeleži ponovno povezavo, na lokalnem omrežju pa se ni nič premaknilo. Nov naslov WAN razveljavi zunanjo povezavo, ne da bi znotraj karkoli spremenil: naslov vira odjemalca se je spremenil, staro stanje NAT kaže na vir, ki ne obstaja več, in oddaljeni partner morda še vedno pošilja na prejšnji naslov. Obnovitev je običajno vedenje, uporabno vprašanje pa je, katero stanje se ni posodobilo.

Poimenujte dogodek, preden preberete dnevnik

Preverite, kaj se je dejansko zgodilo na dostopni plasti. Podaljšanje najema pri ponudniku je en dogodek. Znova povezana seja PPPoE je drug. Znova zagnan optični modem ali preklop WAN z enega voda na drugega spremeni zunanji naslov ali njegovo pot na tretji način. To nista ista dogodka in ne puščata istega ostanka.

Vrstica ponovne povezave v dnevniku VPN tudi ni dokaz spremembe WAN. Časovna omejitev nedejavnosti, interval ponovnega preverjanja pristnosti in zaznavanje mrtvega partnerja vsi ustvarjajo ponovne povezave brez kakršne koli spremembe naslova. Preden karkoli sklepate, primerjajte časovne žige iz dnevnika dostopa z dnevnikom VPN in okno primerjave držite dovolj široko, da ujamete spremembo, ki se je zgodila ponoči.

Gostovanje in ponovna povezava sta različna protokola

WireGuard ima preverjeno gostovanje vgrajeno v protokol: ko partner prejme pravilno preverjeno paketno enoto z novega naslova vira, posodobi končno točko tega partnerja. Hitri začetek WireGuard opisuje konfiguracijo partnerja, ki to omogoča, zato si odjemalec na spreminjajočem se naslovu pogosto opomore brez vidnega ponovnega zagona.

OpenVPN se privzeto obnaša drugače. Seja UDP se lahko konča in znova poveže, izbirno vedenje float pa preverjenemu partnerju omogoča nadaljevanje z novega naslova tam, kjer konfiguracija to dovoljuje. Tuneli na osnovi TCP so strožji, ker je sama povezava vezana na par naslovov. Ta razlika odloči, ali bo obnovitev videti nevidna ali se bo vsakič oglasila v dnevniku.

Nobeno od vedenj ne pove nič o aplikacijah znotraj. Obnovljen tunel ne obnovi seje TCP, ki jo je partner že imel za mrtvo.

Stanje, ki ga tunel ne poseduje

Stanje prevajanja in usmerjanja preživi ponovno povezavo na načine, ki ljudi presenetijo. Vnos conntrack, ustvarjen za stari vir, drži pot odgovora zasidrano na naslovu, ki ne obstaja več, in poteče po svojem urniku, ne ko se je tunel vrnil. Ponovni zagon storitve tunela tega čakanja ne skrajša, zato je lahko popravljena povezava še nekaj časa videti pokvarjena.

Poti in pravila politike se lahko sklicujejo na staro prehodno točko ali vmesnik. Nabor pravil, ki je bil pravilen pred preklopom WAN, lahko kaže na napravo, ki je zdaj izklopljena, kar ustvari tunel, ki se prijavi kot povezan, in promet, ki ne pride nikamor. Dinamični DNS za strežnik, ki ga gostite, je ločena težava od odjemalca, ki pridobi nov vir. Zapis je treba posodobiti, da vas oddaljeni odjemalci najdejo, in nobena konfiguracija na strani odjemalca ne nadomesti naslova, ki ga prevajanje višje po poti ne bo posredovalo.

Razporedite preverjanja od zunaj navznoter

Spodnji vrstni red gre od zunanje povezave navznoter, in prav ustavljanje pri prvem neuspešnem koraku ga naredi uporabnega: vsako preverjanje izključi plast nad seboj. Ta vrstni red ohranite tudi, ko je napaka videti očitna.

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

Prvi ukaz pokaže trenutno končno točko in starost rokovanja za vsakega partnerja. Drugi in tretji pokažeta, ali imata zunanji vmesnik in pot do končne točke še smisel. Število conntrack je grobo preverjanje stanja, ki je ostalo od prejšnjega naslova, dnevnik pa je mesto, kjer se zabeleži razlog ponovne povezave.

Nato preizkusite z odjemalca v lokalnem omrežju, ne z usmerjevalnika. Ping ki ga pošlje sam usmerjevalnik uporablja drugačno pot kot posredovani promet, zato uspešen ping z usmerjevalnika dokazuje obstoj tunela in nič o dosegljivosti odjemalca.

Odločite se o pričakovanem vedenju in ga zapišite

Ponovna povezava je pravilno vedenje za večino uvedb, zato cilj ni preprečiti je. Namesto tega odločite, kaj naj se s prometom zgodi med vrzeljo: ustaviti ga, zadržati ali preiti na drugo pot. Ta odločitev spada v požarni zid in usmerjevalno politiko, ne v profil VPN.

Zabeležite dostopne dogodke in čase ponovne povezave skupaj en teden. Ponavljajoče se spremembe brez ustreznega dostopnega dogodka kažejo na dostopno storitev, in zamenjava profila VPN ne bo popravila voda, ki se nenehno znova dogovarja. En sam par vnosov v isti minuti razreši vprašanje za ta incident in naslednjemu da izhodišče.