Kial nslookup solvas tra la VPN sed la retumilo ne povas

nslookup sendas demandon al la servilo, kiun vi nomas, kaj presas la respondon, tial ĝi povas sukcesi dum ĉiu retumila langeto malsukcesas. Retumilo petas la operaciumon solvi, kaj la operaciumo pezas solvilojn laŭ interfaco, regulojn de nomresolva politiko kaj la retan lokon de la adaptilo. Poste la retumilo povas aldoni sian propran ĉifritan DNS supre. Tri malsamaj vojoj, unu simptomo, kaj la tunelo kutime ne estas la rompita parto.

La subaj kontroloj sekvas tiujn vojojn de la sistemo eksteren. Ne redaktu la VPN-profilo ĝis vi scios, kiu vojo respondis kaj kiu malsukcesis.

Tri politikoj decidas la respondon

Ĉiu interfaco portas sian propran solvilan liston kaj serĉajn sufiksojn. VPN-adaptilo aldonas servilojn dum la fizika adaptilo konservas siajn proprajn, kaj la sistemo povas preni tiun, kiu respondas unue, do serĉo povas esti servita ekster la tunelo sen ke iu tion elektus. Reguloj de la tabelo de nomresolva politiko povas sendi elektitajn domajnojn al elektitaj serviloj, kaj tiel split DNS kutime esprimiĝas en Windows. Kaj la VPN-kliento aŭ enirejo povas puŝi solvilan adreson, kiu ekzistas nur ene de la privata reto.

Tiuj tri interagas laŭ manieroj, kiuj el retumilo ŝajnas arbitraj. Puŝita solvilo ĉe privata adreso sen vojo tra la split-tunelo igas ĉiun serĉon halti kaj poste malsukcesi. Politika regulo, kiu kovras la internan sufikson kaj montras al malŝaltita servilo, produktas la saman videblan eraron kiel mankanta vojo. Serĉa sufikso mankanta en la VPN-adaptilo turnas mallongan nomon en publikan demandon pri la malĝusta domajno. Ĉiu el ili bezonas malsaman riparon.

Kial retumilo faras alian demandon

nslookup eldonas sian propran demandon al la servilo, kiun ĝi elektas, kaj sekvas nek la nomspacan politikon nek la ĉifritan DNS-agordon de la retumilo. Tial mana demando al publika solvilo respondas dum la retumilo raportas, ke la retejo ne ekzistas. Vi komparas du programojn, ne du statojn de unu programo.

Adresfamilia prefero klarigas prokraston, ne malsukceson. Retumilo, kiu unue petas IPv6-rikordojn en tunelo portanta nur IPv4, atendas tempolimon antaŭ ol retroiri. Firefox portis preferon ĝuste por ĉi tio, kaj malŝalti ĝin estas diagnoza paŝo, ne riparo.

Legu la solvilan liston kaj la regulojn

En Windows, elŝutu tion, kion la sistemo tenas, antaŭ ol teorigi. Get-DnsClientServerAddress montras la servilojn laŭ interfaco, Get-DnsClientNrptRule listigas la nomspacajn regulojn, kaj Resolve-DnsName respondas la ĝustan nomon tra la sistema vojo. Komparu tiun respondon kun rekta demando al la servilo de la VPN laŭ adreso. Kiam Resolve-DnsName malsukcesas kaj la rekta demando sukcesas, la suspektato estas la solvila listo aŭ nomspaca regulo.

Kontrolu ankaŭ la nomon mem. Interna mallonga nomo eble bezonas la privatan sufikson, kiun provizas nur la VPN-adaptilo, dum la plene kvalifikita nomo solviĝas bone. Atentigo pri atestilo post sukcesa serĉo apartenas al alia problemo.

La neatingebla puŝita solvilo

Enirejo aŭ kliento povas puŝi solvilan adreson, kaj tiu adreso devas esti atingebla tra la tunelo. En split-tunelo la privata gamo enhavanta la solvilon eble ne estas inter la inkluditaj vojoj, kio produktas serĉon, kiu neniam ricevas respondon. Konfirmu, ke la vojo ekzistas, poste demandu tiun adreson specife, tra la tunelo. Tio estas la malsukceso malantaŭ domajna eraro en la retumilo dum publika solvilo ankoraŭ respondas.

Se la solvilo estas neatingebla, la riparo estas vojo aŭ inkludita subreto, ne alia DNS-servilo.

Ĉifrita DNS preterpasas la tutan vojon

Retumiloj kun DNS-over-HTTPS mem solvas nomojn per HTTPS-konekto al elektita provizanto. Kun tio ŝaltita, la sistema solvilo kaj la split-DNS-reguloj tute preterpasiĝas por tiuj serĉoj, do internaj nomoj malsukcesas en la retumilo dum la operaciumo solvas ilin ĝuste. Ankaŭ la malo okazas: internaj nomoj sukcesas en la retumilo per provizanto, kiu neniam devus vidi ilin, kaj tio estas politika problemo, ne konekteca.

Decidu konscie, ĉu ĉifrita DNS estas permesata sur administritaj aparatoj, poste agordu ĝin per la administra surfaco de la retumilo por ke la elekto estu videbla. Laso al individua prefero produktas floton, en kiu la sama VPN kondutas malsame sur ĉiu tekkomputilo.

Reparoj kongruaj kun la malsukceso

Se la VPN puŝas sian solvilon, igi la tunelon porti trafikon al ĝi kaj igi la saman agordon videbla sur la adaptiloj, kiuj partoprenas en la solvado. Se lokaj retejoj ĉesas solviĝi dum vi estas konektita, aldonu eksplicitajn nomspacajn esceptojn aŭ kondiĉan plusendilon anstataŭ anstataŭigi la solvilon tute. Se la ĉifrita DNS de la retumilo preterpasas politikon, tiu estas la agordo ŝanĝenda. Neniam aldonu publikan solvilon por ripari internan nomon: ĝi likas privatajn demandojn kaj ne solvas la nomon.

Poste apartigu serĉadon de konekto. Nomo, kiu solviĝas al la ĝusta adreso sed rifuzas konekton, estas problemo de servo, fajroŝirmilo aŭ atestilo, kaj DNS-ŝanĝoj ne riparos ĝin.

Notu, kiu vojo respondis, kiu malsukcesis kaj kion vi ŝanĝis. La sekva raporto pri la sama simptomo tiam postulos unu komandon anstataŭ posttagmezon.