OpenVPN padne po obnovení DHCP: udržte trasu ku koncovému bodu

Tunel sa pripojí, potom ho obnovenie prenájmu na prístupovom spoji zabije a log viní timeout, nie trasu. V konfigurácii VPN sa nič nezmenilo, a to je tá stopa: zmenilo sa niečo mimo nej. Udalosť DHCP prepísala adresu alebo bránu, a hostiteľská trasa, ktorá držala koncový bod tunela dostupný, teraz ukazuje na ďalší skok, ktorý už neexistuje. Toto je problém vlastníctva skôr, než je problém routovania.

Porovnajte príznak s polovicami predvolených trás

S redirect-gateway def1 nainštaluje OpenVPN 0.0.0.0/1 a 128.0.0.0/1 namiesto nahradenia predvolenej trasy. Obe spolu pokrývajú celý adresný priestor a porážajú 0.0.0.0/0 už len dĺžkou prefixu. Preto každé cieľové miesto bez konkrétnejšej zhody vstúpi do tunela.

Koncový bod potrebuje výnimku. OpenVPN pridá hostiteľskú trasu k adrese servera cez pôvodnú prístupovú bránu skôr, než sa polovice predvolených trás zapíšu, aby zapuzdrené pakety mohli odísť. Keď táto výnimka zmizne, alebo si podrží ďalší skok, ktorý už neexistuje, vlastné vonkajšie pakety tunela zodpovedajú polovici predvolenej trasy a pošlú sa späť do tunela. Výsledkom je spojenie, ktoré umrie pri ďalšom keepalive alebo handshake, a v logu nie je nič, čo by vyzeralo ako chyba routovania.

Potvrďte tvar tabuľky, než sa dotknete čohokoľvek iného. ip route show by mal vypísať obe polovice plus hostiteľskú trasu k adrese servera; keď hostiteľská trasa chýba, zvyšok vyšetrovania má zrejmý východiskový bod.

Prečo polovice predvolených trás vyhrajú bez zmeny metriky

Nižšia metrika neprekoná dlhší prefix. Trasy /1 vyhrajú, pretože jadro najprv spáruje najkonkrétnejšiu trasu, takže zvýšenie metriky na predvolenej trase nič nemení na tom, kam ide prevádzka smerujúca do tunela. Honenie metrík je v tejto diagnostike najčastejšie nesprávne odbočenie.

Skontrolujte voľbu pomocou ip route get 203.0.113.10, dosaďte skutočnú adresu servera. Odpoveď pomenuje rozhranie a ďalší skok, ktoré by jadro skutočne použilo, čo je informatívnejšie než čítať tabuľku a uvažovať o nej.

Spustite ten príkaz pred štartom tunela, keď beží, a po udalosti prenájmu. Tri odpovede z jedného príkazu a bod rozdielu je viditeľný.

Urobte tri snímky, nie jednu

Zozbierajte prístupovú adresu, prístupovú bránu, cieľ koncového bodu, zvolenú trasu a všetky pravidlá politiky v troch okamihoch: po konfigurácii prístupového spoja, po pripojení VPN a po udalosti prenájmu alebo operátora. Každá snímka je hrsť príkazov a zmysel majú len spoločne. Jediná snímka po zlyhaní zaznamená stav, nie prechod. Zapíšte príkazy do malého skriptu, aby sa každá snímka robila rovnako.

Držte snímky v jednom súbore s časovými značkami, pretože zaujímavá otázka neskôr je poradie. Prišla udalosť DHCP predtým, alebo potom, čo OpenVPN obnovil svoju trasu? Odpoveď rozhoduje, kto to musí opraviť. Časová značka z nesprávnych hodín je horšia než žiadna, takže ju berte z hostiteľa, ktorý vlastní routovaciu tabuľku.

Keď je koncový bod nakonfigurovaný ako meno namiesto adresy, rozlíšte ho aj v každej snímke. Zmena DNS na prístupovom spoji môže posunúť koncový bod bez toho, aby sa čo i len jedna trasa dotkla.

Rozhodnite, ktorý komponent výnimku obnovuje

V systéme s dhcpcd sa háčiky spúšťajú z adresára háčikov a z výstupného háčika, a režim správcu sa rozsahom líši od režimu pre jednotlivé rozhranie. Čokoľvek háčik robí, musí byť idempotentné, pretože obnovenia môžu prichádzať v dávkach.

Spoľahlivý vlastník je integrácia, ktorá už pozná obe strany: správca siete, ktorý spravuje pripojenie VPN, alebo unit zoradený po nadvihnutí prístupového spoja. Statická trasa pridaná háčikom funguje do ďalšej zmeny brány, a potom zlyhá úplne rovnakým spôsobom. Ak háčik predsa použijete, prinúťte ho čítať aktuálnu bránu za behu, namiesto pevného zakódovania tej, ktorú ste videli dnes.

Zaznamenajte vlastníka vnútri konfigurácie. Ďalší človek, ktorý bude ladiť opätovné pripojenie, musí vedieť, že za výnimkovú trasu zodpovedá háčik, nie VPN.

Testujte životný cyklus, nie len opätovné pripojenie

Vynúťte obnovenie pomocou dhcpcd -n eth0 alebo uvoľnením a novým získaním prenájmu, potom znova skontrolujte ip route get pre koncový bod. Urobte to dvakrát, pretože druhý beh zachytí háčiky, ktoré pridávajú duplicitné trasy. Potom reštartujte, pretože trvalosť je iná vlastnosť než správnosť.

Tunel, ktorý prežije obnovenie aj reštart, má vlastníka a fungujúcu výnimku. Ten, ktorý prežije len ručný reštart, nemá ani jedno, a zlyhá pri ďalšej udalosti, ktorú nedokážete naplánovať.