OpenVPN katkeb pärast DHCP uuendust: hoidke lõpp-punkti marsruut alles

Tunnel ühendub, seejärel tapab juurdepääsulüli liisingu uuendus selle, ja logi süüdistab marsruudi asemel ajalõppu. VPN-i konfiguratsioonis pole miski muutunud, ja see ongi vihje: midagi väljaspool seda muutus. DHCP sündmus kirjutas üle aadressi või lüüsi, ja hostimarsruut, mis hoidis tunneli lõpp-punkti kättesaadavana, osutab nüüd järgmisele hüppele, mida enam ei ole. See on omandiprobleem enne, kui see on marsruutimisprobleem.

Võrrelge sümptomit poolvaikimisi marsruutidega

redirect-gateway def1 korral paigaldab OpenVPN 0.0.0.0/1 ja 128.0.0.0/1, selle asemel et vaikimisi marsruuti asendada. Koos katavad need kaks kogu aadressiruumi ja löövad 0.0.0.0/0 üksnes prefiksi pikkusega. Seetõttu läheb iga sihtkoht ilma täpsema vasteta tunnelisse.

Lõpp-punkt vajab erandit. OpenVPN lisab hostimarsruudi serveri aadressini algse juurdepääsulüüsi kaudu enne, kui poolvaikimisi marsruudid lisatakse, et kapseldatud paketid saaksid välja minna. Kui see erand kaob või hoiab järgmist hüpet, mida enam ei ole, langevad tunneli enda välispaketid poolvaikimisi marsruudile ja saadetakse tagasi tunnelisse. Tulemuseks on ühendus, mis sureb järgmisel keepalive'il või käepigistusel, ilma et logis oleks midagi marsruutimisvea moodi.

Kinnitage tabeli kuju enne, kui midagi muud puutute. ip route show peaks loetlema mõlemad pooled pluss hostimarsruut serveri aadressile; kui hostimarsruut puudub, on uurimise ülejäänud osal ilmne alguspunkt.

Miks poolvaikimisi marsruudid võidavad ilma mõõdiku muutmiseta

Väiksem mõõdik ei võida pikemat prefiksit. Marsruudid /1 võidavad, sest kernel sobitab esmalt kõige spetsiifilisema marsruudi, nii et vaikimisi marsruudi mõõdiku tõstmine ei muuda midagi selles, kuhu tunnelisse suunduv liiklus läheb. Mõõdikute tagaajamine on selles diagnoosis kõige tavalisem vale pööre.

Kontrollige valikut ip route get 203.0.113.10 abil, asendades selle tegeliku serveri aadressiga. Vastus nimetab liidese ja järgmise hüppe, mida kernel tegelikult kasutaks, mis on informatiivsem kui tabeli lugemine ja selle üle arutlemine.

Käivitage see käsk enne tunneli algust, selle töötamise ajal ja pärast liisingusündmust. Kolm vastust ühest käsust ja lahknevuspunkt muutub nähtavaks.

Tehke kolm hetktõmmist, mitte üks

Koguge juurdepääsuaadress, juurdepääsulüüs, lõpp-punkti sihtkoht, valitud marsruut ja kõik poliitikareeglid kolmel hetkel: pärast juurdepääsulüli seadistamist, pärast VPN-i ühendumist ja pärast liisingu- või operaatorisündmust. Iga hetktõmmis on peotäis käske ja neil on tähendus ainult koos. Üksik hetktõmmis pärast riket jäädvustab oleku, mitte ülemineku. Kirjutage käsud väikesesse skripti, et iga hetktõmmis tehtaks ühtemoodi.

Hoidke hetktõmmiseid ühes failis ajatemplitega, sest huvitav küsimus on hiljem järjekord. Kas DHCP sündmus saabus enne või pärast seda, kui OpenVPN oma marsruudi värskendas? Vastus otsustab, kes peab selle parandama. Vale kella ajatempel on hullem kui üldse mitte, seega võtke see hostilt, kellele marsruutimistabel kuulub.

Kui lõpp-punkt on seadistatud nime, mitte aadressina, lahendage see ka igas hetktõmmises. DNS-i muudatus juurdepääsulülil võib lõpp-punkti liigutada, ilma et ühtegi marsruuti puudutataks.

Otsustage, milline komponent erandit värskendab

dhcpcd-süsteemis käivituvad konksud konksukataloogist ja väljumiskonksust ning haldurirežiim erineb ulatuselt liidesepõhisest režiimist. Mida iganes konks teeb, see peab olema idempotentne, sest uuendused võivad saabuda purskete kaupa.

Usaldusväärne omanik on integratsioon, mis teab juba mõlemat poolt: võrguhaldur, mis haldab VPN-ühendust, või unit, mis on järjestatud pärast juurdepääsulüli tõusmist. Konksuga lisatud staatiline marsruut töötab kuni järgmise lüüsini, ja siis ebaõnnestub täpselt samamoodi. Kui te konksu siiski kasutate, pange see käitusajal praegust lüüsi lugema, selle asemel et kõvasti kodeerida see, mida täna nägite.

Kirjutage omanik konfiguratsiooni sisse. Järgmine inimene, kes taasthendust silub, peab teadma, et erandmarsruudi eest vastutab konks, mitte VPN.

Testige elutsüklit, mitte ainult taasthendust

Sundige uuendus dhcpcd -n eth0 abil või liisingut vabastades ja uuesti võttes, seejärel kontrollige lõpp-punkti jaoks uuesti ip route get. Tehke seda kaks korda, sest teine käivitus püüab konksud, mis lisavad duplikaatmarsruute. Seejärel taaskäivitage, sest püsivus on teine omadus kui korrektsus.

Tunnelil, mis elab üle uuenduse ja taaskäivituse, on omanik ja töötav erand. Sellel, mis elab üle ainult käsitsi taaskäivituse, pole kumbagi, ja see ebaõnnestub järgmisel sündmusel, mida te planeerida ei saa.