OpenVPN lähetti DNS-palvelimen, mutta Linux jättää sen huomiotta

Lähetetty DNS-palvelin on lokissa, tunneli on ylhäällä ja sisäiset nimet epäonnistuvat edelleen. Itse lähetyksessä ei ole mitään rikki; asetus saapui ja pysähtyi siihen. Lähetetty DNS-asetus on viesti asiakkaalle, ei ohje käyttöjärjestelmän resolverille, ja niiden välinen luovutus on paikka, johon useimmat näistä tapauksista päättyvät. Viisi tarkistusta järjestyksessä löytävät luovutuksen, jota ei tapahtunut.

Tarkistus yksi: miten yhteys alkaa

Yhteyden omistaja määrää, kuka voi soveltaa resolverin asetuksia. Suora openvpn-komento kuoresta ei omista mitään oman prosessinsa lisäksi, kun taas systemd-yksiköllä, NetworkManagerilla tai toimittajan asiakkaalla on kullakin oma tapansa julkaista DNS. Lue prosessiluettelo ja yksikön nimi ennen kuin oletat mitään niistä.

Komentoriviprosessi ei ole automaattisesti NetworkManager-yhteys, eikä NetworkManager-yhteys ole automaattisesti se, mikä kirjoitti resolv.conf-tiedoston. Nämä kaksi oletusta selittävät suurimman osan tässä tutkimuksessa hukatuista tunneista. Kysy, mikä komponentti julkaisisi DNS:n sille liitännälle, jonka todella näet.

Kirjoita omistaja muistiin ennen jatkamista. Jokainen myöhempi tarkistus riippuu siitä.

Tarkistus kaksi: mitä resolverin linkki todella sisältää

systemd-resolved-isännässä resolvectl status luettelee jokaisen linkin DNS-palvelimineen ja verkkotunnuksineen. Etsi tunnelin linkki ja lue sen merkinnät, äläkä oleta, että liitännän nimi on tun0, koska numerointi seuraa luontijärjestystä. Jos lähetetty osoite puuttuu linkiltä, luovutus epäonnistui eikä kysely.

Jos osoite on läsnä, seuraava kysymys on, mitä verkkotunnuksia linkki vaatii. Linkki ilman verkkotunnusluetteloa vastaa vain nimiin, joista siltä kysytään suoraan, ja sitä split-DNS-käyttöönotto harvoin haluaa. Osoite yksin on välttämätön mutta ei riittävä.

Vertaa linkin nimeä resolverin tulosteessa liitännän nimeen VPN-lokissa ennen minkään johtopäätöksen tekemistä. Epäjohdonmukaisuus siellä tarkoittaa yleensä, että lokirivi tuli toisesta prosessista.

Tarkistus kolme: valitseeko nimiavaruus kyseisen linkin

Resolverilla voi olla oikea palvelin ja silti sitä ei kuulla. Linkkikohtainen verkkotunnus päättää, mitkä kyselyt menevät millekin linkille, ja ilman reititysverkkotunnusta yksityinen nimiavaruus palaa siihen, mitä oletuslinkki sanoo. Siksi resolvectl query voi onnistua sisäiselle nimelle, vaikka sovellus epäonnistuu edelleen. Sovellus saattaa käyttää täysin eri resolver-polkua.

Tarkista verkkotunnuksen osoitus, älä vain palvelimen osoitetta. Verkkotunnus, joka on kirjoitettu muodossa ~corp.example, on reititysverkkotunnus, ja tilde muuttaa sitä, miten nimi täsmäytetään.

Jos sovelluksella on oma resolver, testaa samalla mekanismilla, jota se käyttää, älä järjestelmän työkalulla. Kyselytyökalu, joka ohittaa järjestelmän resolverin, onnistuu linkin tilasta riippumatta.

Tarkistus neljä: yksi omistaja, ei kaksi

Jos NetworkManager jo hallitsee VPN:ää ja resolverin tilaa, liittymättömän koukkuskriptin lisääminen luo kilpailevia kirjoittajia. Paketin tarjoama systemd-resolvedin koukku on tuettu integraatio, ja se odottaa tiettyä elinkaarta: script-security 2, up-polku, up-restart, down-polku ja down-pre. Nämä valinnat saavat rekisteröinnin ja poiston tapahtumaan oikeilla hetkillä eikä vain ensimmäisellä yhteydellä.

Käytä paketista asennettua polkua äläkä oppaasta kopioitua havainnollista polkua. Myös käyttöoikeuksilla on väliä, koska koukku ajetaan sen jälkeen, kun oikeuksia on laskettu.

Jakelun resolver-skriptin muokkaaminen sen tulostekohteen muuttamiseksi kirjaa yhden isännän kierron. Se ei ole yleinen korjaus.

Tarkistus viisi: sama tulos uudelleenyhdistämisen jälkeen

Yhdistä uudelleen ja lue linkki uudelleen. Rekisteröinti, joka ilmestyy kerran ja katoaa seuraavassa siirtymässä, on vika, jonka vuoksi koko tämä tarkistuslista on olemassa. Testaa keskeytyksen jälkeen, pakotetun uudelleenyhdistämisen jälkeen ja resolver-palvelun uudelleenkäynnistyksen jälkeen. Jokainen siirtymä koettelee eri järjestysoletusta.

Vasta kun kaikki viisi tarkistusta läpäisevät uudelleenyhdistämisessä, voit sanoa, että lähetetyt asetukset ovat käytössä. Kaikki sitä aiempi on onnekkaan hetken tilannekuva.