OpenVPN pade po obnovitvi DHCP: obdržite pot do končne točke

Tunel se poveže, nato ga obnovitev najema na dostopni povezavi ubije, in dnevnik obtožuje časovno omejitev namesto poti. V konfiguraciji VPN se ni nič spremenilo, in to je namig: spremenilo se je nekaj zunaj nje. Dogodek DHCP je prepisal naslov ali prehodno postajo, in pot do gostitelja, ki je držala končno točko tunela dosegljivo, zdaj kaže na naslednji skok, ki ne obstaja več. To je problem lastništva preden je problem usmerjanja.

Primerjajte simptom s polovičnimi privzetimi potmi

S redirect-gateway def1 OpenVPN namesti 0.0.0.0/1 in 128.0.0.0/1, namesto da bi zamenjal privzeto pot. Skupaj ti dve pokrivata ves naslovni prostor in premagata 0.0.0.0/0 že samo z dolžino predpone. Zato vsak cilj brez natančnejšega ujemanja vstopi v tunel.

Končna točka potrebuje izjemo. OpenVPN doda pot do gostitelja na naslov strežnika skozi prvotno dostopno prehodno postajo, preden vstopijo polovične privzete poti, da lahko zapakirani paketi odidejo. Ko ta izjema izgine, ali obdrži naslednji skok, ki ne obstaja več, se lastni zunanji paketi tunela ujemajo s polovično privzeto potjo in se pošljejo nazaj v tunel. Rezultat je povezava, ki umre ob naslednjem keepalive ali rokovanju, in v dnevniku ni ničesar, kar bi bilo videti kot napaka usmerjanja.

Potrdite obliko tabele, preden se česar koli drugega dotaknete. ip route show bi moral navesti obe polovici plus pot do gostitelja za naslov strežnika; ko pot do gostitelja manjka, ima preostanek preiskave očitno izhodišče.

Zakaj polovične privzete poti zmagajo brez spremembe metrike

Nižja metrika ne premaga daljše predpone. Poti /1 zmagajo, ker jedro najprej ujame najbolj specifično pot, zato dvig metrike na privzeti poti ne spremeni ničesar glede tega, kam gre promet, namenjen tunelu. Preganjanje metrik je najpogostejša napačna ovinka v tej diagnostiki.

Preverite izbiro z ip route get 203.0.113.10, z vstavljenim pravim naslovom strežnika. Odgovor navede vmesnik in naslednji skok, ki bi ju jedro dejansko uporabilo, kar je bolj poučno kot branje tabele in razmišljanje o njej.

Zaženite ta ukaz pred začetkom tunela, med njegovim delovanjem in po dogodku najema. Trije odgovori iz enega ukaza, in točka razhajanja postane vidna.

Naredite tri posnetke, ne enega

Zberite dostopni naslov, dostopno prehodno postajo, cilj končne točke, izbrano pot in vsa pravila politike v treh trenutkih: po konfiguraciji dostopne povezave, po povezavi VPN in po dogodku najema ali operaterja. Vsak posnetek je pest ukazov, in smisel imajo le skupaj. En sam posnetek po okvari zabeleži stanje, ne prehoda. Zapišite ukaze v majhno skripto, da se vsak posnetek naredi na enak način.

Posnetke hranite v eni datoteki s časovnimi žigi, ker je zanimivo vprašanje pozneje vrstni red. Je dogodek DHCP prišel prej ali potem, ko je OpenVPN osvežil svojo pot? Odgovor odloči, kdo mora to popraviti. Časovni žig z napačne ure je slabši od nobenega, zato ga vzemite z gostitelja, ki ima usmerjevalno tabelo.

Ko je končna točka konfigurirana kot ime namesto naslova, jo razrešite tudi v vsakem posnetku. Sprememba DNS na dostopni povezavi lahko premakne končno točko, ne da bi se dotaknila katera koli pot.

Odločite, katera komponenta osveži izjemo

V sistemu dhcpcd se kljuke izvajajo iz imenika kljuk in iz izhodne kljuke, in način upravitelja se po obsegu razlikuje od načina na vmesnik. Karkoli kljuka počne, mora biti idempotentno, ker lahko obnovitve prihajajo v sunkih.

Zanesljivi lastnik je integracija, ki že pozna obe strani: omrežni upravitelj, ki upravlja povezavo VPN, ali enota, razvrščena po dvigu dostopne povezave. Statična pot, ki jo doda kljuka, deluje do naslednje spremembe prehodne postaje, nato pa spodleti na popolnoma enak način. Če kljuko vseeno uporabljate, naj ob izvajanju bere trenutno prehodno postajo, namesto da trdo kodira tisto, ki ste jo videli danes.

Zabeležite lastnika znotraj konfiguracije. Naslednja oseba, ki bo razhroščevala ponovno povezavo, mora vedeti, da je za izjemno pot odgovorna kljuka, ne VPN.

Preizkusite življenjski cikel, ne le ponovne povezave

Vsilite obnovitev z dhcpcd -n eth0 ali z sprostitvijo in ponovno pridobitvijo najema, nato znova preverite ip route get za končno točko. Naredite to dvakrat, ker drugi tek ujame kljuke, ki dodajajo podvojene poti. Nato znova zaženite, ker je trajnost druga lastnost kot pravilnost.

Tunel, ki preživi obnovitev in ponovni zagon, ima lastnika in delujočo izjemo. Tisti, ki preživi le ročni ponovni zagon, nima nobenega od obeh, in bo spodletel ob naslednjem dogodku, ki ga ne morete načrtovati.