IP adresa WAN sa zmenila a tunel spadol: kontroly v poradí

Tunel spadne, router zaprotokoluje opätovné pripojenie a v miestnej sieti sa nič nepohlo. Nová adresa WAN zneplatní vonkajšie spojenie bez zmeny čohokoľvek vnútri: zdrojová adresa klienta sa zmenila, starý stav NAT ukazuje na zdroj, ktorý už neexistuje, a vzdialený partner môže stále posielať na predchádzajúcu adresu. Obnova je normálne správanie a užitočná otázka je, ktorý stav sa neaktualizoval.

Pomenujte udalosť, skôr než začnete čítať log

Skontrolujte, čo sa skutočne stalo na prístupovej vrstve. Obnovenie nájmu od poskytovateľa je jedna udalosť. Opäť pripojená relácia PPPoE je iná. Reštartovaný optický modem alebo prepnutie WAN z jedného spojenia na druhé mení vonkajšiu adresu alebo jej cestu tretím spôsobom. Nie sú to rovnaké udalosti a nezanechávajú rovnaké zvyšky.

Riadok opätovného pripojenia v logu VPN tiež nie je dôkazom zmeny WAN. Časový limit nečinnosti, interval opätovného overenia a detekcia mŕtveho partnera všetky vytvárajú opätovné pripojenia bez akejkoľvek zmeny adresy. Pred akýmkoľvek záverom porovnajte časové značky z prístupového logu s logom VPN a okno porovnania držte dosť široké, aby zachytilo zmenu, ktorá nastala v noci.

Roaming a opätovné pripojenie sú rôzne protokoly

WireGuard má overený roaming zabudovaný v protokole: keď partner dostane správne overený paket z novej zdrojovej adresy, aktualizuje koncový bod tohto partnera. Rýchly štart WireGuard opisuje konfiguráciu partnera, ktorá to umožňuje, a preto sa klient na meniacej sa adrese často zotaví bez viditeľného reštartu.

OpenVPN sa predvolene správa inak. Relácia UDP sa môže skončiť a znovu pripojiť a voliteľné správanie float umožňuje overenému partnerovi pokračovať z novej adresy tam, kde to konfigurácia dovoľuje. Tunely založené na TCP sú prísnejšie, pretože samotné spojenie je viazané na dvojicu adries. Ten rozdiel rozhoduje o tom, či obnova vyzerá neviditeľne, alebo sa v logu vždy ohlási.

Ani jedno správanie nehovorí nič o aplikáciách vnútri. Obnovený tunel neobnoví reláciu TCP, ktorú partner už považoval za mŕtvu.

Stav, ktorý tunel nevlastní

Stav prekladu a smerovania prežije opätovné pripojenie spôsobmi, ktoré ľudí prekvapia. Záznam conntrack vytvorený pre starý zdroj drží cestu odpovede ukotvenú na adrese, ktorá už neexistuje, a vyprší podľa vlastného harmonogramu, nie vtedy, keď sa tunel vrátil. Reštart služby tunela toto čakanie neskráti, takže opravené spojenie môže ešte chvíľu vyzerať pokazené.

Trasy a pravidlá politiky môžu odkazovať na starú bránu alebo rozhranie. Sada pravidiel, ktorá bola správna pred prepnutím WAN, môže ukazovať na zariadenie, ktoré je teraz vypnuté, čo vytvára tunel, ktorý hlási pripojenie, a prevádzku, ktorá nikam nejde. Dynamické DNS pre server, ktorý hostujete, je samostatný problém od klienta, ktorý získava nový zdroj. Záznam treba aktualizovať, aby vás vzdialení klienti našli, a žiadna konfigurácia na strane klienta nevykompenzuje adresu, ktorú preklad vyššie v sieti neprepošle.

Zoraďte kontroly zvonku dovnútra

Poradie nižšie ide od vonkajšieho spojenia dovnútra a práve zastavenie na prvom neúspešnom kroku ho robí užitočným: každá kontrola vylučuje vrstvu nad sebou. Toto poradie dodržte, aj keď porucha vyzerá zjavne.

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

Prvý príkaz ukazuje aktuálny koncový bod a vek handshake pre každého partnera. Druhý a tretí ukazujú, či vonkajšie rozhranie a trasa ku koncovému bodu ešte dávajú zmysel. Počet conntrack je hrubá kontrola stavu, ktorý zostal z predchádzajúcej adresy, a log je miesto, kde sa zaznamenáva dôvod opätovného pripojenia.

Potom testujte z klienta v miestnej sieti, nie z routera. Ping odoslaný samotným routerom používa inú cestu než preposielaná prevádzka, takže úspešný ping z routera dokazuje existenciu tunela a nič o dostupnosti klienta.

Rozhodnite o očakávanom správaní a zapíšte ho

Opätovné pripojenie je správne správanie pre väčšinu nasadení, takže cieľom nie je mu zabrániť. Rozhodnite namiesto toho, čo sa má diať s prevádzkou počas medzery: zastaviť ju, podržať alebo prejsť na inú cestu. Toto rozhodnutie patrí firewallu a politike smerovania, nie profilu VPN.

Zaznamenávajte prístupové udalosti a časy opätovného pripojenia spolu týždeň. Opakované zmeny bez zodpovedajúcej prístupovej udalosti ukazujú na prístupovú službu a výmena profilu VPN neopraví spojenie, ktoré stále znovu vyjednáva. Jediná dvojica záznamov v tej istej minúte vyrieši otázku pre tento incident a dá ďalšiemu základnú líniu.