OpenVPN je poslal strežnik DNS, a Linux ga ignorira

Poslani strežnik DNS je v dnevniku, tunel je vzpostavljen, notranja imena pa še vedno ne uspejo. Pri samem pošiljanju ni nič pokvarjeno; nastavitev je prispela in se tam ustavila. Poslana možnost DNS je sporočilo odjemalcu, ne navodilo razreševalniku operacijskega sistema, in prav predaja med njima je mesto, kjer se konča večina teh primerov. Pet preverjanj po vrsti najde predajo, ki se ni zgodila.

Prvo preverjanje: kako se povezava začne

Lastnik povezave določa, kdo lahko uporabi nastavitve razreševalnika. Neposreden ukaz openvpn iz lupine ne poseduje ničesar razen svojega procesa, medtem ko imajo enota systemd, NetworkManager ali odjemalec ponudnika vsak svoj način objavljanja DNS. Preden katero od tega predpostavite, preberite seznam procesov in ime enote.

Proces iz ukazne vrstice ni samodejno povezava NetworkManager in povezava NetworkManager ni samodejno tisto, kar je zapisalo resolv.conf. Ti dve predpostavki pojasnjujeta večino izgubljenih ur v tej preiskavi. Vprašajte, katera komponenta bi objavila DNS za vmesnik, ki ga dejansko vidite.

Preden nadaljujete, zapišite lastnika. Vsako naslednje preverjanje je odvisno od njega.

Drugo preverjanje: kaj povezava razreševalnika dejansko vsebuje

Na gostitelju s systemd-resolved resolvectl status navaja vsako povezavo z njenimi strežniki DNS in domenami. Poiščite povezavo tunela in preberite njene vnose, in ne predpostavljajte, da se vmesnik imenuje tun0, ker številčenje sledi vrstnemu redu ustvarjanja. Če poslanega naslova na povezavi ni, je spodletela predaja, ne poizvedba.

Če je naslov prisoten, je naslednje vprašanje, katere domene zahteva ta povezava. Povezava brez seznama domen odgovarja le na imena, po katerih se sprašuje neposredno, in to je redko tisto, kar želi uvedba split-DNS. Sam naslov je potreben, a ne zadosten.

Preden sklepate karkoli, primerjajte ime povezave v izhodu razreševalnika z imenom vmesnika v dnevniku VPN. Neujemanje tam običajno pomeni, da je vrstica dnevnika prišla iz drugega procesa.

Tretje preverjanje: ali imenski prostor izbere to povezavo

Razreševalnik ima lahko pravi strežnik in ga kljub temu nihče ne vpraša. Domena na povezavo določa, katere poizvedbe gredo na katero povezavo, brez usmerjevalne domene pa zasebni imenski prostor pade nazaj na tisto, kar pravi privzeta povezava. Zato lahko resolvectl query za notranje ime uspe, medtem ko aplikacija še vedno ne uspe. Aplikacija morda uporablja povsem drugo pot razreševalnika.

Preverite dodelitev domene, ne le naslova strežnika. Domena, zapisana kot ~corp.example, je usmerjevalna domena, in tilda spremeni, kako se ime ujema.

Če ima aplikacija svoj razreševalnik, preizkusite z istim mehanizmom, ki ga uporablja ona, in ne s sistemskim orodjem. Orodje za poizvedbe, ki obide sistemski razreševalnik, bo uspelo ne glede na stanje povezave.

Četrto preverjanje: en lastnik, ne dva

Če NetworkManager že upravlja VPN in stanje razreševalnika, dodajanje nepovezane hook skripte ustvari tekmece pri pisanju. Hook, ki ga paket zagotavlja za systemd-resolved, je podprta integracija in pričakuje določen življenjski cikel: script-security 2, pot up, up-restart, pot down in down-pre. Te možnosti poskrbijo, da se registracija in odstranitev zgodita ob pravih trenutkih, ne le ob prvi povezavi.

Uporabite nameščeno pot iz paketa, ne ilustrativne, prepisane iz vodnika. Tudi dovoljenja štejejo, ker se hook izvede po znižanju pravic.

Urejanje skripte razreševalnika distribucije za spremembo njenega izhodnega cilja zabeleži obhod za enega gostitelja. To ni splošno popravilo.

Peto preverjanje: enak rezultat po ponovni povezavi

Ponovno se povežite in znova preberite povezavo. Registracija, ki se pojavi enkrat in izgine ob naslednjem prehodu, je napaka, zaradi katere obstaja ves ta kontrolni seznam. Preizkusite po mirovanju, po prisilni ponovni povezavi in po ponovnem zagonu storitve razreševalnika. Vsak prehod preizkusi drugo predpostavko o vrstnem redu.

Šele ko pri ponovni povezavi uspe vseh pet preverjanj, lahko rečete, da so poslane nastavitve v uporabi. Vse prej je posnetek srečnega trenutka.