Miks resolv.conf näitab teie VPN-i DNS-i, aga päringud eiravad seda

Logides ei paista midagi valesti: liides on üleval, resoluutija teatab VPN-i DNS-serverist ja kettal olev fail loetleb selle. Ometi lahendatakse sisemine hostinimi endiselt kohaliku ruuteri kaudu. Need kolm väidet ei ole vastuolus, sest fail, iga lingi olek ja päringu teekond on erinevad objektid, mis juhtumisi jagavad nime. Järgnev kirjeldab teekonda, mille päring systemd-resolvediga hostis tegelikult läbib.

Kolm objekti nimega resolv.conf

Resolvediga hostis on /etc/resolv.conf tavaliselt sümboolne link /run/systemd/resolve/stub-resolv.conf-ile. See sihtkoht sisaldab kohaliku stub-kuulaja aadressi, 127.0.0.53, pluss otsingudomeenid, mille resolved on arvutanud. See on oleku vaade, mitte olek ise.

Olek elab resolvedi lingipõhises konfiguratsioonis, mistõttu võib resolvectl status failiga vastuolus olla ja ikkagi õige olla. Iga link kannab oma servereid ja oma marsruutimisdomeene, ning stub konsulteerib neid andmeid, kui päring saabub. Systemd-resolvedi käsiraamat kirjeldab genereeritud faile ja lingipõhist mudelit; vaate ja oleku eraldamine on osa, mida tasub meeles pidada. Sümboolse lingi sihtmärgi muutmine muudab seda, mida loevad traditsioonilised kliendid, mitte seda, mida resoluutija teab.

Kolmas objekt, /run/systemd/resolve/resolv.conf, lapitab iga lingi üheks serverite loendiks. Sellele failile suunatud programm saadab päringud otse loetletud serveritele ja jätab stubi vahele, nii et lingipõhine poliitika ei kehti selle kohta enam. Seega võivad kaks programmi samas masinas sama nime erinevalt vastata ja kumbki pole katki.

Jälgige üht päringut läbi NSS-i

glibc loeb /etc/nsswitch.conf, et otsustada, kes nimele vastab. Hosts-rida, mis sisaldab resolve, suunab küsimuse nss-resolve-ile, mis küsib resolvedi D-Busi kaudu ja saab lingipõhise vastuse. Rida ainult files dns-ga saadab päringu aadressile, mida hoiab /etc/resolv.conf.

See üks rida selgitab enamikku lahkhelisid brauseri ja dig-i vahel. dig loeb resolv.conf-i otse ega puuduta kunagi NSS-i, seega testib see stubi või ülemvoolu serverit, mitte rakenduse kasutatavat teed. getent hosts internal.example läbib NSS-i, ja selle vastuse võrdlemine dig-i omaga on esimene kasulik mõõtmine.

Rakendused, mis toovad kaasa oma resoluutija või räägivad DNS-i üle HTTPS-i fikseeritud lõpp-punktiga, mööduvad mõlemast teest. Miski resolv.conf-s ega resolvedi olekus ei piira neid.

Kontrollige, kellele fail kuulub ja kuhu see osutab

Lugege linkide ahelat enne mis tahes muutmist, sest omandiõigus otsustab, milline fail on autoriteetne. Iga allolev käsk loeb ainult olekut.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Esimene rida trükib lingi ja selle sihtmärgi koos, ning VPN-skriptile kuuluv tavaline fail tähendab, et resoluutija ei käsitle seda kirjet kunagi sisendina. Olekutrükk loetleb lingipõhised serverid pluss marsruutimisdomeenid, mis otsustavad, kuhu iga päring läheb. nsswitch-rida ütleb, kas stubi üldse konsulteeritakse, seega stub-aadress failis ilma resolve-ta tähendab, et päringud jõuavad kohaliku kuulajani, samal ajal kui miski ei halda jagunemist. Ka viimane loend loeb, sest host ilma stub-resolv.conf-ta ei käita siin kirjeldatud lahendust.

Kui ahel lõpeb failis, mida haldab teine pakett, on VPN-klient ja see pakett kaks omanikku, keda tuleb lepitada. Lingi asendamine viskab ära ühe omaniku töö ja jätab teise oma kohale.

Parandage lingi omaniku juures

VPN-ühendus peaks registreerima oma serverid ja domeenid oma lingil ning seejärel need lahtiühendamisel tagasi võtma. NetworkManageri resolvedi integratsioon ja kliendi enda abiline töötavad mõlemad nii; skript, mis ainult kirjutab üle resolv.conf-i, ei tee seda.

Juba olemasoleval lingil näitab mehhanismi käitusaegne seadistus. resolvectl dns tun0 10.40.0.53 kinnitab serveri ja resolvectl domain tun0 '~corp.example' kinnitab marsruutimisdomeeni. Tilde on kandev märk: see piirab selle sufiksi päringud selle lingiga ja jätab kõik muu rahule, samas kui sama väärtus ilma selleta muutub otsingudomeeniks ja jagunemine aurustub. Need aadressid on laborinäited, mitte püsiv konfiguratsioon. Kinnitage resolvectl query host.corp.example-ga ja lugege, milline link vastas.

Registreeritud server vajab siiski marsruuti. Kui päring jõuab õigele lingile ja aegub, on viga tunneliläbivas kättesaadavuses, mitte resoluutija omandis.

Kuidas töötav olek välja näeb

Terve tulemus on järjekindel kõigis kolmes vaates: lingipõhised serverid vastavad sellele, mida VPN väljastas, marsruutimisdomeenid katavad ainult sisemisi sufikseid ja oluline rakendus lahendab sisemise nime, samal ajal kui avalik nimi järgib endiselt kohalikku teed. Üks edukas päring tõestab vähem kui see kooskõla.

Seejärel katkestage ühendus ja korrake mõlemat päringut. Klient, mis jätab oma domeenid pärast lammutamist registreerituks, tekitab masina, mis ebaõnnestub sisemistes päringutes tunde hiljem, ilma avatud tunnelita ja ilma ilmse põhjuseta.