Kial resolv.conf montras la DNS de via VPN sed serĉoj ignoras ĝin

Nenio en la protokoloj aspektas malĝusta: la interfaco estas aktiva, la solvilo raportas la DNS-servilon de la VPN, kaj la dosiero sur la disko listigas ĝin. Tamen interna gastigantnomo ankoraŭ solviĝas per la loka enkursigilo. Tiuj tri asertoj ne kontraŭdiras sin, ĉar la dosiero, la stato laŭ ligilo kaj la serĉvojo estas malsamaj objektoj, kiuj hazarde kunhavas nomon. Sekvas la vojo, kiun peto efektive sekvas sur gastiganto kun systemd-resolved.

Tri objektoj nomataj resolv.conf

Sur gastiganto kun resolved, /etc/resolv.conf estas kutime simbola ligilo al /run/systemd/resolve/stub-resolv.conf. Tiu celo tenas la adreson de loka stub-aŭskultanto, 127.0.0.53, plus la serĉajn domajnojn, kiujn resolved kalkulis. Ĝi estas vido de la stato, ne la stato mem.

La stato loĝas en la agordo de resolved laŭ ligilo, kaj tial resolvectl status povas malkonsenti kun la dosiero kaj tamen pravi. Ĉiu ligilo portas siajn proprajn servilojn kaj siajn proprajn enkursigajn domajnojn, kaj la stub konsultas tiujn datumojn, kiam peto alvenas. La manlibro de systemd-resolved priskribas la generitajn dosierojn kaj la modelon laŭ ligilo; la disigo inter vido kaj stato estas la parto, kiun valoras memori. Ŝanĝi la celon de la simbolaj ligilo ŝanĝas tion, kion legas tradiciaj klientoj, ne tion, kion scias la solvilo.

Tria objekto, /run/systemd/resolve/resolv.conf, platigas ĉiun ligilon en unu servilliston. Programo direktita al tiu dosiero sendas petojn rekte al la listigitaj serviloj kaj preterpasas la stub, do la politiko laŭ ligilo jam ne validas por ĝi. Tial du programoj sur la sama maŝino povas respondi la saman nomon malsame, kaj neniu el ili estas difektita.

Spuru unu serĉon tra NSS

glibc legas /etc/nsswitch.conf por decidi, kiu respondas al nomo. Linio hosts enhavanta resolve direktas la demandon al nss-resolve, kiu demandas resolved per D-Bus kaj ricevas la respondon laŭ ligilo. Linio kun nur files dns sendas la peton al tiu adreso, kiun tenas /etc/resolv.conf.

Tiu unu linio klarigas la plej multajn malkonsentojn inter retumilo kaj dig. dig legas resolv.conf rekte kaj neniam tuŝas NSS, do ĝi testas la stub aŭ supran servilon anstataŭ la vojon, kiun la aplikaĵo uzas. getent hosts internal.example trapasas NSS, kaj kompari ĝian respondon kun tiu de dig estas la unua utila mezurado.

Aplikaĵoj, kiuj enhavas propran solvilon aŭ parolas DNS per HTTPS kun fiksa finpunkto, preterpasas ambaŭ vojojn. Nenio en resolv.conf aŭ en la stato de resolved limigas ilin.

Kontrolu, kiu posedas la dosieron kaj kien ĝi montras

Legi la ligilan ĉenon antaŭ ol ŝanĝi ion, ĉar posedo decidas, kiu dosiero estas aŭtoritata. Ĉiu komando sube nur legas staton.

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

La unua linio presas la ligilon kaj ĝian celon kune, kaj ordinara dosiero posedata de VPN-skripto signifas, ke la solvilo neniam traktas tiun skribon kiel enigon. La statusa eligo listigas servilojn laŭ ligilo plus la enkursigajn domajnojn, kiuj decidas, kien iras ĉiu peto. La linio nsswitch diras, ĉu la stub estas konsultata entute, do stub-adreso en la dosiero sen resolve tie signifas, ke petoj atingas la lokan aŭskultanton dum nenio administras la disigon. Ankaŭ tiu lasta listo gravas, ĉar gastiganto sen stub-resolv.conf ne funkciigas la aranĝon priskribitan ĉi tie.

Se la ĉeno finiĝas en dosiero administrata de alia pakaĵo, la VPN-kliento kaj tiu pakaĵo estas la du posedantoj, kiujn oni devas akordigi. Anstataŭigi la ligilon forĵetas la laboron de unu posedanto kaj lasas la alian en loko.

Riparu ĉe la posedanto de la ligilo

VPN-konekto devus registri siajn servilojn kaj siajn domajnojn sur sia propra ligilo, poste retiri ilin ĉe malkonekto. La integriĝo de resolved en NetworkManager kaj la propra helpanto de kliento ambaŭ funkcias tiel; skripto, kiu nur reskribas resolv.conf, ne.

Sur ligilo, kiu jam ekzistas, la runtempaj agordoj montras la mekanismon. resolvectl dns tun0 10.40.0.53 alligas servilon, kaj resolvectl domain tun0 '~corp.example' alligas enkursigan domajnon. La tildo estas la ŝarĝa signo: ĝi limigas petojn por tiu sufikso al ĉi tiu ligilo kaj lasas ĉion alian trankvila, dum la sama valoro sen ĝi fariĝas serĉa domajno kaj la disigo vaporiĝas. Tiuj adresoj estas laboratoriaj ekzemploj, ne daŭra agordo. Konfirmu per resolvectl query host.corp.example kaj legu, kiu ligilo respondis.

Registrita servilo ankoraŭ bezonas itineron. Kiam la peto atingas la ĝustan ligilon kaj tempolimas, la kulpo estas atingeblo tra la tunelo, ne posedo de la solvilo.

Kiel aspektas funkcianta stato

Sana rezulto estas konsekvenca en ĉiuj tri vidoj: la serviloj laŭ ligilo kongruas kun tio, kion la VPN donis, la enkursigaj domajnoj kovras nur internajn sufiksojn, kaj la grava aplikaĵo solvas internan nomon dum publika nomo ankoraŭ sekvas la lokan vojon. Unu sukcesa peto pruvas malpli ol tiu kongruo.

Poste malkonektu kaj ripetu ambaŭ petojn. Kliento, kiu lasas siajn domajnojn registritaj post la malmuntado, produktas maŝinon, kiu malsukcesas ĉe internaj serĉoj horojn poste, sen malferma tunelo kaj sen evidenta kaŭzo.