OpenVPN katkeaa DHCP-uudistuksen jälkeen: säilytä päätepisteen reitti

Tunneli yhdistyy, sitten käyttöliittymän vuokran uudistus tappaa sen, ja loki syyttää reitin sijaan aikakatkaisua. VPN:n asetuksissa mikään ei muuttunut, ja se on vihje: jokin sen ulkopuolella muuttui. DHCP-tapahtuma kirjoitti osoitteen tai yhdyskäytävän uudelleen, ja isäntäreitti, joka piti tunnelin päätepisteen saavutettavana, osoittaa nyt seuraavaan hyppyyn, jota ei enää ole. Tämä on omistajuusongelma ennen kuin se on reititysongelma.

Vertaa oiretta puolioletusreitteihin

redirect-gateway def1-asetuksella OpenVPN asentaa 0.0.0.0/1 ja 128.0.0.0/1 sen sijaan, että korvaisi oletusreitin. Yhdessä ne kaksi kattavat koko osoiteavaruuden, ja ne voittavat 0.0.0.0/0:n pelkällä etuliitteen pituudella. Siksi mikä tahansa kohde ilman tarkempaa osumaa menee tunneliin.

Päätepiste tarvitsee poikkeuksen. OpenVPN lisää isäntäreitin palvelimen osoitteeseen alkuperäisen käyttöyhdyskäytävän kautta ennen kuin puolioletukset asennetaan, jotta kapseloidut paketit pääsevät lähtemään. Kun tuo poikkeus katoaa tai pitää seuraavan hypyn, jota ei enää ole, tunnelin omat ulommat paketit osuvat puolioletusreittiin ja ne lähetetään takaisin tunneliin. Tuloksena on yhteys, joka kuolee seuraavassa keepalivessa tai kättelyssä, eikä lokissa ole mitään reititysvirheeltä näyttävää.

Vahvista taulun muoto ennen kuin kosket mihinkään muuhun. ip route show:n pitäisi listata molemmat puolikkaat sekä isäntäreitti palvelimen osoitteelle; kun isäntäreitti puuttuu, tutkinnan loppuosalla on ilmeinen aloituspiste.

Miksi puolioletukset voittavat ilman metriikan muutosta

Pienempi metriikka ei voita pidempää etuliitettä. Reitit /1 voittavat, koska ydin sovittaa ensin tarkimman reitin, joten oletusreitin metriikan nostaminen ei muuta mitään siinä, minne tunneliin menevä liikenne kulkee. Metriikkojen perässä juokseminen on tämän diagnoosin yleisin väärä käännös.

Tarkista valinta komennolla ip route get 203.0.113.10 ja korvaa se palvelimen todellisella osoitteella. Vastaus nimeää rajapinnan ja seuraavan hypyn, joita ydin todella käyttäisi, mikä on valaisevampaa kuin taulun lukeminen ja sen pohtiminen.

Suorita tuo komento ennen tunnelin alkua, sen ollessa käynnissä ja vuokratapahtuman jälkeen. Kolme vastausta yhdestä komennosta, ja eroamispiste tulee näkyväksi.

Ota kolme tilannekuvaa, älä yhtä

Kerää käyttöosoite, käyttöyhdyskäytävä, päätepisteen kohde, valittu reitti ja kaikki käytäntösäännöt kolmena hetkenä: kun käyttöliittymä on määritetty, kun VPN on yhdistynyt ja vuokra- tai operaattoritapahtuman jälkeen. Jokainen tilannekuva on kourallinen komentoja, ja ne merkitsevät jotain vain yhdessä. Yksi vian jälkeinen tilannekuva tallentaa tilan, ei siirtymää. Kirjoita komennot pieneen skriptiin, jotta jokainen tilannekuva otetaan samalla tavalla.

Pidä tilannekuvat yhdessä tiedostossa aikaleimoineen, sillä kiinnostava kysymys on myöhemmin järjestys. Tuliko DHCP-tapahtuma ennen vai sen jälkeen, kun OpenVPN päivitti reittinsä? Vastaus ratkaisee, kenen se on korjattava. Väärän kellon aikaleima on huonompi kuin ei mitään, joten ota se isännältä, joka omistaa reititystaulun.

Kun päätepiste on määritetty nimeksi eikä osoitteeksi, selvitä se myös jokaisessa tilannekuvassa. DNS-muutos käyttöliittymällä voi siirtää päätepistettä koskematta yhteenkään reittiin.

Päätä, mikä komponentti päivittää poikkeuksen

dhcpcd-järjestelmässä koukut ajetaan koukkuhakemistosta ja poistumiskoukusta, ja hallintatilan laajuus eroaa rajapintakohtaisesta tilasta. Mitä tahansa koukku tekee, sen on oltava idempotentti, koska uudistukset voivat saapua ryöppyinä.

Luotettava omistaja on integraatio, joka tuntee jo molemmat puolet: verkkohallinta, joka hallinnoi VPN-yhteyttä, tai unit, joka on järjestetty käyttöliittymän noustua. Koukun lisäämä staattinen reitti toimii seuraavaan yhdyskäytävän muutokseen ja epäonnistuu sitten täsmälleen samalla tavalla. Jos kuitenkin käytät koukkua, anna sen lukea nykyinen yhdyskäytävä ajonaikaisesti sen sijaan, että kovakoodaisit tänään näkemäsi.

Kirjaa omistaja asetuksiin. Seuraavan uudelleenyhdistämistä debuggaavan on tiedettävä, että poikkeusreitistä vastaa koukku, ei VPN.

Testaa elinkaari, älä vain uudelleenyhdistämistä

Pakota uudistus komennolla dhcpcd -n eth0 tai vapauttamalla ja uusimalla vuokra, ja tarkista sitten päätepiste uudelleen komennolla ip route get. Tee se kahdesti, koska toinen kierros nappaa koukut, jotka lisäävät kaksoisreittejä. Käynnistä sitten uudelleen, koska pysyvyys on eri ominaisuus kuin oikeellisuus.

Tunnelilla, joka selviää uudistuksesta ja uudelleenkäynnistyksestä, on omistaja ja toimiva poikkeus. Sillä, joka selviää vain manuaalisesta uudelleenkäynnistyksestä, ei ole kumpaakaan, ja se epäonnistuu seuraavassa tapahtumassa, jota et voi aikatauluttaa.