OpenVPN saatis DNS-serveri, kuid Linux eirab seda

Saadetud DNS-server on logis, tunnel on üleval ja sisemised nimed ikka ei tööta. Saatmises endas pole midagi katki; seade jõudis kohale ja peatus seal. Saadetud DNS-valik on sõnum kliendile, mitte korraldus operatsioonisüsteemi resolverile, ja nendevaheline üleandmine on koht, kus enamik neist juhtudest lõpeb. Viis kontrolli järjekorras leiavad üleandmise, mis jäi tegemata.

Kontroll üks: kuidas ühendus algab

Ühenduse omanik määrab, kes saab resolveri seadeid rakendada. Otsene openvpn-käsk kestast ei oma midagi peale oma protsessi, samas kui systemd-üksus, NetworkManager või tarnija klient on igaühel oma viis DNS-i avaldada. Enne nende eeldamist loe protsesside loendit ja üksuse nime.

Käsurea protsess ei ole automaatselt NetworkManageri ühendus ja NetworkManageri ühendus ei ole automaatselt see, mis kirjutas resolv.conf. Need kaks eeldust seletavad enamikku selles uurimises raisatud tundidest. Küsi, milline komponent avaldaks DNS-i selle liidese jaoks, mida te tegelikult näete.

Kirjuta omanik enne edasiliikumist üles. Iga hilisem kontroll sõltub sellest.

Kontroll kaks: mida resolveri link tegelikult sisaldab

systemd-resolved hostis loetleb resolvectl status iga lingi koos selle DNS-serverite ja domeenidega. Leia tunneli link ja loe selle kirjed, ning ära eelda, et liides kannab nime tun0, sest numereerimine järgib loomise järjekorda. Kui saadetud aadress lingil puudub, ebaõnnestus üleandmine, mitte päring.

Kui aadress on olemas, on järgmine küsimus, milliseid domeene see link nõuab. Domeeniloendita link vastab ainult nimedele, mille kohta temalt otse küsitakse, ja seda tahab split-DNS juurutus harva. Aadress üksi on vajalik, kuid mitte piisav.

Enne mis tahes järelduse tegemist võrdle lingi nime resolveri väljundis liidese nimega VPN-i logis. Sealne lahknevus tähendab tavaliselt, et logirida tuli teisest protsessist.

Kontroll kolm: kas nimeruum valib selle lingi

Resolver võib hoida õiget serverit ja ikkagi mitte olla küsitav. Lingipõhine domeen otsustab, millised päringud millisele lingile lähevad, ja ilma marsruutimisdomeenita langeb privaatne nimeruum tagasi sellele, mida ütleb vaikimisi link. Seetõttu võib resolvectl query sisemise nime jaoks õnnestuda, samal ajal kui rakendus ikka ebaõnnestub. Rakendus võib kasutada hoopis teist resolveri teed.

Kontrolli domeeni määramist, mitte ainult serveri aadressi. Domeen, mis on kirjutatud kujul ~corp.example, on marsruutimisdomeen ja tild muudab nime sobitamise viisi.

Kui rakendusel on oma resolver, testi sama mehhanismiga, mida tema kasutab, mitte süsteemivahendiga. Päringutööriist, mis läheb süsteemi resolverist mööda, õnnestub sõltumata lingi olekust.

Kontroll neli: üks omanik, mitte kaks

Kui NetworkManager juba haldab VPN-i ja resolveri olekut, tekitab mitteseotud hook-skripti lisamine konkureerivad kirjutajad. Paketi pakutav systemd-resolvedi hook on toetatud integratsioon ja eeldab kindlat elutsüklit: script-security 2, up tee, up-restart, down tee ja down-pre. Need valikud panevad registreerimise ja eemaldamise toimuma õigetel hetkedel, mitte ainult esimesel ühendusel.

Kasuta paketist paigaldatud teed, mitte juhendist kopeeritud näitlikku. Õigused loevad samuti, sest hook töötab pärast privileegide langemist.

Distributsiooni resolveri skripti muutmine selle väljundsihtmärgi muutmiseks dokumenteerib ühe hosti möödaraja. See ei ole üldine parandus.

Kontroll viis: sama tulemus pärast uuesti ühendamist

Ühendu uuesti ja loe link uuesti. Registreerimine, mis ilmub korra ja kaob järgmisel üleminekul, on tõrge, mille jaoks kogu see kontrollnimekiri on. Testi pärast peatamist, pärast sunnitud uuestiühendust ja pärast resolveri teenuse taaskäivitamist. Iga üleminek kontrollib erinevat järjekorraeeldust.

Alles siis, kui kõik viis kontrolli uuesti ühendamisel läbivad, saad öelda, et saadetud seaded on kasutusel. Kõik varasem on õnneliku hetke hetktõmmis.