Via VPN pelas tri DNS-servilojn: kiu respondas?

Malfermu la agordan paĝon post konektiĝo kaj tri DNS-adresoj estas listigitaj; la demando de la revizio estas, kiu traktis vian lastan peton. La nombro sole respondas nenion, ĉar klienta puŝo, fizika interfaco kaj politiko por unu domajno ĉiuj skribas en la saman vidon. Tiuj enskriboj portas malsamajn ampleksojn, kaj amplekso prefere ol pozicio decidas, kiu respondas. Komencu per apartigo de la fontoj, poste testu tiun, kiu posedas la nomon, kiu gravas al vi.

Kial la listo estas pli longa ol via profilo

VPN-kliento puŝas adresojn de solvilo por la tunela ligo, kaj la operaciumo tenas ilin apud tio, kion la fizika interfaco jam havis. Enkursigilo, entreprena DHCP-luo, dua VPN kaj politiko por unu domajno ĉiu kontribuas sian propran enskribon. Tri adresoj en la paĝo do povas signifi tri ampleksojn anstataŭ tri kandidatoj por unu tasko. Legi la nombron kiel pruvon de liko estas la unua eraro de ĉi tiu revizio.

Ene de unu interfaco kliento ja provas siajn servilojn laŭ ordo, do ordigita listo ne estas sensignifa. Tio, kio ne estas vico, estas la kunfandita vido, kie enskriboj el la profilo, la fizika ligo kaj reguloj por unu domajno staras unu apud la alia sen unu sola rangigo. Tiu distingo decidas, kion vi testas: ordo klarigas konduton ene de unu amplekso, kaj amplekso klarigas ĉion alian.

Ĉifrita DNS rompas la bildon de interne de aplikaĵo. Retumilo aŭ babileja kliento kun propra DNS-over-HTTPS-solvilo sendas demandojn tute preter la listo de la operaciumo, do la adresoj sur la agorda paĝo priskribas trafikon, kiun la aplikaĵo neniam generis. Kontrolu la propran solvilan agordon de la aplikaĵo antaŭ ol kulpigi la profilon pri nomo, kiu eliris malĝuste.

Kion diras ĉiu el la tri kontroloj

Ĉiu fonto lasas sian spuron en alia loko, kaj neniu unuopa komando montras ĉiujn. Jen la mapado inda teni apud la agorda paĝo:

Sur sistemo uzanta systemd-resolved, resolvectl status estas aŭtoritata, ĉar ĝi raportas DNS por ĉiu ligo kune kun la enkursigaj domajnoj. macOS respondas per scutil --dns, kiu listigas ampleksajn solvilojn laŭ la ordo de provado. Windows dividas la du duonojn: Get-DnsClientServerAddress por serviloj de ĉiu interfaco kaj Get-DnsClientNrptPolicy por la sufiksaĵaj reguloj. Rulu la komandon, kiu apartenas al la fakte uzata solvilo, ĉar maŝino kun uja rultempo kaj labortabla solvilo povas havi pli ol unu instalitan.

Rezerva solvilo, kiu ne povas respondi pri via zono

Dua enskribo kutime ekzistas por havebleco, kaj havebleco funkcias nur se la rezervo konas la nomojn. Demandu publikan solvilon pri interna gastigantnomo kaj ĝi redonas NXDOMAIN, aŭ ĵokeran respondon el serĉa domajno tute senrilata al vi. Tiam rezerva transiro, kiun neniu kontrolis, produktas interrompon ĝuste en la momento, kiam ĝi necesas.

Split DNS ekzistas por malhelpi tion: firmaaj sufiksaĵoj iras al solvilo, kiu tenas la zonon, kaj publikaj nomoj restas sur la defaŭlta vojo. La dezajno estas solida, kaj ĝi dependas de tio, ke la sufiksaĵa listo estu kompleta. Microsoft dokumentas la solvilan politikon por ĉiu sufiksaĵo, kiu stiras tion en Windows, kaj la sama ideo aperas kiel enkursigaj domajnoj en systemd-resolved kaj kiel ampleksaj solviloj en macOS.

Komparu la zonojn, pri kiuj la rezervo rajtas respondi, kun la sufiksaĵoj ĉeestaj en la politiko. Tiu komparo trovas la mankon antaŭ ol uzanto raportas, ke unu interna retejo ĉesis solviĝi post tunela ŝanĝo.

Demandu tra la politiko, ne preter ĝi

Demandu tra la solvilo de la operaciumo, ĉar rekta demando al servilo preteriras la politikon kaj raportas nur tion, kion tiu servilo dirus. La manko inter la du respondoj estas la tuta senco:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Se la sistema demando redonas privatan adreson dum la rekta demando redonas NXDOMAIN, la politiko funkcias kaj la rezervo estas la malforta punkto. Se ambaŭ redonas la saman publikan respondon, la nomo solviĝas ekster la amplekso, kiun vi celis, kaj la sufiksaĵa listo estas la loko por rigardi. Konservu ambaŭ eligojn, ĉar solvilan disputon oni finas pli rapide per du linioj ol per ekrankopio de la agorda paĝo.

Poste ekzercu la malsukcesan vojon, ĉar rezervo, kiun neniu testis, estas supozo. Faru la preferatan solvilon nigra truo por unu demando kaj observu, kiu adreso revenas:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Forigu tiun vojon tuj kiam la demando finiĝos, alie la sekva persono heredas misteron. Se internaj nomoj ankoraŭ solviĝas en tiu fenestro, io ekster la celita amplekso respondis ilin. Se ili anstataŭe tempolimas, la rezervo mankas aŭ estas ĝuste limigita, kaj la propra protokolo de la solvilo diras al vi, kiu el la du ĝi estis.

Decidu: teni, limigi aŭ forigi

Tenu duan solvilon, kiam ĝi respondas la nomspacon, kiun vi bezonas, kaj restas atingebla sub la profilo. Limigu ĝin, kiam ĝi devas vidi unu sufiksaĵon kaj nenion alian, kaj forigu ĝin, kiam ĝi havas nek amplekson nek dokumentitan celon. Enskribo sen tasko estas estonta liko sen utilo, kaj fabrikanta defaŭlto ne estas celo.

Registru la rezulton kiel kvar kolumnoj: sufiksaĵo, solvilo, interfaco kaj posedanto. Tiu linio respondas la sekvan revizian demandon pli rapide ol iu ajn ekrankopio, kaj ĝi postvivas la klientan ĝisdatigon, kiu silente reordigas la liston.