OpenVPNin DNS jää jäljelle SIGKILLin jälkeen: tarkista ensin omistaja

DNS lakkaa ratkaisemasta, kun OpenVPN-asiakas tapetaan, ja ensimmäinen vaisto on kirjoittaa uudelleen /etc/resolv.conf. Tämä muutos voi rikkoa toimivan resolverin, kun varsinainen vanhentunut tila on jossakin muualla. Ensimmäisenä ratkaistava kysymys on, kuka omistaa DNS-asetukset, jotka tunneli asensi, ja oliko siivouksen ohittaneella poistumisella todella merkitystä.

Kolme ehtoa ratkaisee korjauksen: prosessin päättänyt signaali, asetukset vastaanottanut resolverin osa ja se, onko tunnelin linkki yhä olemassa. Vastaa niihin tässä järjestyksessä, niin korjaus seuraa yleensä koskematta globaaliin tiedostoon.

Päätä, millainen poistuminen tapahtui

Community-julkaisussa OpenVPN sekä SIGINT että SIGTERM ovat pyyntöjä hallittuun poistumiseen. SIGKILLiä ei voi siepata: sitä ei voi estää eikä käsitellä, joten mikään sammutusrutiini ei saa tilaisuutta käynnistyä. Tavallinen Ctrl+C etualan päätteessä tuottaa SIGINTin, kun taas odottamisen lopettava valvoja yltyy yleensä SIGKILLiin. Ero on merkityksellinen, koska vain toinen tapaus takaa, että koukut ohitettiin.

Ajaminen screenin tai tmuxin sisällä ei muuta sitä, minkä signaalin Ctrl+C lähettää. Tarkista, mitä prosessi todella vastaanotti, älä sitä, mitä pääte yleensä tekee.

Kun palvelu tai yhteyksien hallinta ajaa tunnelia, pysäytä se yksi yhteys sen omistajan kautta sen sijaan että tappaisit pidin. Hallinta voi nostaa prosessin uudelleen, jolloin jäljelle jää tuore tunneli ja sekava resolverin tila. Itsenäinen prosessi tarvitsee siivouksen käynnistymiseen vain tavallisen lopetuspynnön.

Päätä, kuka omistaa resolverin

systemd-resolved, resolvconf-tyylinen skripti ja pelkkä tiedoston uudelleenkirjoitus ovat kolme eri omistajaa. Ensimmäinen pitää linkkikohtaiset asetukset muistissa ja pudottaa ne, kun liitäntä katoaa. Toinen pitää tietueita, jotka säilyvät, kunnes jokin poistaa ne. Kolmas kirjoittaa tiedoston ja jättää palautuksen sen tekijälle.

Tunnista omistaja ennen korjauskomennon valintaa. Samalla oireella on kolme eri oikeaa vastausta riippuen siitä, kumpi on käytössä.

NetworkManagerin hallitsema VPN voi jo omistaa resolverin muutokset. Toisen apurin lisääminen päälle luo kaksi omistajaa, jotka kilpailevat samasta linkistä, ja häviäjän tila palaa seuraavassa uudelleenyhdistämisessä. Jos hallinta on vastuussa, korjaa asetus hallinnassa eikä skriptissä.

Mitä down-koukku voi tehdä ja mitä ei

Skripti down ajetaan kerran, kun TUN/TAP-laite on suljettu. Lisääminen down-pre kääntää tämän järjestyksen ja ajaa skriptin, kun laite on vielä olemassa, mitä elävää linkkiä tarvitsevat apurit vaativat.

Kumpikaan direktiivi ei saa koukkua ajautumaan SIGKILLin jälkeen. Oikeuksia ei myöskään palauteta down-pre: jos daemon laskeutuu user tai group tasolle tai astuu chroot sisään, koukku ajetaan sillä käyttöoikeudella, jonka se sille jättää. Kutsuttu koukku voi silti epäonnistua resolverin päivittämisessä. OpenVPN-viite kattaa signaalit ja callbackin elinkaaren.

Tarkista koukun oma virhe prosessin poistumistilan vieressä. Puuttuva siivous ja epäonnistunut siivous näyttävät resolverissa samalta ja lokeissa erilaiselta.

Tarkista tila, joka todella jää jäljelle

Järjestelmässä, joka käyttää systemd-resolvedia, resolvectl status näyttää, mikä linkki yhä kantaa VPN:n DNS-palvelimia tai reititysalueita. Tämä linkki voi kuulua yhteydelle, joka on poissa, tai toiselle tunnelille, joka on yhä pystyssä.

Katoava liitäntä vie mukanaan linkkikohtaisen kokoonpanonsa, joten ohitettu koukku voi esiintyä puhtaan DNS:n rinnalla. Jos linkki on yhä rekisteröity ja yksinomaan pysäytetyn yhteyden omistuksessa, sen omistavan hallinnan pitäisi poistaa se. Jos vanhempi skripti kirjoitti globaalin resolver-tiedoston uudelleen, etsi sen sijaan kyseisen skriptin dokumentoitu palautusvaihe.

Palauta varastamatta toista linkkiä

Kun linkkikohtaiset asetukset ovat sinun hallittavissasi, resolvectl revert ottaa linkin nimen ja tyhjentää kyseisen liitännän ajonaikaisen DNS-kokoonpanon. Se on ajonaikainen toimi eikä profiilin muokkaus, joten pysyvä yhteysasetus pysyy koskemattomana. Nimeä väärä linkki ja tyhjennät toimivan tunnelin DNS:n, siksi nimi tulee tilan tulosteesta.

Varmista, että /etc/resolv.conf on hallittu symbolinen linkki ennen sen muokkaamista, pysäytä asiakas sitten vielä kerran normaalisti ja katso DNS:ää uudelleen. Jos toinen pysäytys siivoaa, aiempi ongelma oli pakotettu poistuminen eikä kokoonpano.