Zataknjen VPN po ponovnem zagonu usmerjevalnika: tri stvari, ki so se spremenile

Usmerjevalnik konča zagon, prenosnik se znova pridruži istemu SSID, VPN pa ostane v stanju povezano, ne da bi se karkoli premikalo. Shranjena konfiguracija je nedotaknjena. Kar je pod njo poteklo, je bila pot, in odjemalec še vedno drži stanje, ki ga je zgradil za staro.

Popravek določajo trije pogoji. Preverite jih po vrsti, ker so poznejši izgubljeno delo, če prvi že pojasni zastoj.

Prvi pogoj: lokalni naslov se je spremenil

Ponovni zagon lahko stroju dodeli drug naslov. VPN, nastavljen s fiksno lokalno končno točko, potem še naprej uporablja povezavo, ki ne obstaja več. Enako velja za odjemalca, ki je svoj vtič povezal s starim naslovom. Vmesnik tunela lahko ostane dvignjen, medtem ko gre vsak paket, ki ga ustvari, nekam nekoristno.

Primerjajte naslov, ki ga uporablja odjemalec, z naslovom, ki ga ima vmesnik zdaj. Privzeta pot, ki kaže na prehod, ki se je prav tako spremenil, je ista vrsta težave pod drugim imenom.

ip -4 addr show
ip route show default
ip route get 203.0.113.10

Drugi pogoj: prevedena preslikava je izginila

Domači usmerjevalniki prevajajo odhodne tokove in te preslikave živijo v pomnilniku. Ponovni zagon izbriše vsako od njih. To je neškodljivo za novo povezavo in usodno za tunel, ki verjame, da je njegov obstoječi tok še veljaven. Takrat druga stran ne vidi ničesar, zato odjemalec nikoli ne prejme napake, na katero bi se lahko odzval.

Tu se tunel brez keepalive tiho ustavi, namesto da bi hrupno propadel. Dokumentirane omejitve WireGuarda opisujejo enako obliko okvare. Napačno stanje končne točke ustvari zavržene pakete namesto diagnoze.

Trajni keepalive 25 sekund je običajno ublažitev, ker osveži preslikavo, preden lahko poteče časovna omejitev mirovanja. Ne popravi preslikave, ki je že izginila. Keepalive povežite z logiko ponovnega povezovanja, namesto da bi ga obravnavali kot popravek.

Tretji pogoj: javni naslov se je spremenil

Če se je spremenil lastni zunanji naslov usmerjevalnika, vse na drugi strani, kar filtrira po izvornem naslovu, zdaj vidi drugega partnerja. Tunel se lahko dvigne in strežnik lahko še vedno zavrača promet; to je videti kot pokvarjen odjemalec, v resnici pa je politika na drugem koncu.

Zabeležite zunanji naslov pred ponovnim zagonom in po njem. Ko se oba razlikujeta, se vprašanje premakne z odjemalca na tistega, ki vzdržuje seznam dovoljenih, in ponastavitev poverilnic na prenosniku ne more pomagati.

Obnovite v pravilnem vrstnem redu

Najprej dokončajte zahtevano prijavo v ujemalnem portalu, nato pustite odjemalcu, da se znova poveže s svojim podprtim postopkom, namesto da bi ubili proces. Opazujte, ali se obnovita tako identiteta kot podatkovni promet, ker sta to dve različni stopnji iste povezave.

Predpomnjena stran ne dokaže ničesar, prav tako ne klepetalna aplikacija, ki se je sama znova povezala. Preizkusite končno točko, ki vam je res pomembna, z novo zahtevo. Med prekinitvijo ohranite politiko neposrednega prometa, ker poskus ponovnega povezovanja ni blokada.

Ko se to ponavlja po vsakem ponovnem zagonu, je zapis pomembnejši od poskusa. Zabeležite lokalni naslov, prehod, zunanji naslov in stanje odjemalca pred in po, nato primerjajte oba stolpca. To spremeni nejasno pritožbo v napako življenjskega cikla, ki jo lahko nekdo odpravi, in ustavi tretjo zamenjavo potrdil zaradi časovne omejitve preslikave.