Waarom nslookup oor die VPN werk, maar die blaaier nie

nslookup stuur 'n navraag na die bediener wat jy noem en druk die antwoord, daarom kan dit slaag terwyl elke blaaier-oortjie misluk. 'n Blaaier vra die bedryfstelsel om die naam op te los, en die bedryfstelsel weeg per-koppelvlak-resolvers, reels vir naamresolusiebeleid en die netwerklokasie van die adapter. Dan kan die blaaier sy eie versleutelde DNS daarby voeg. Drie verskillende paaie, een simptoom, en die tonnel is gewoonlik nie die stukkende deel nie.

Die kontroles hieronder volg daardie paaie van die stelsel af na buite. Moet nie die VPN-profiel wysig voordat jy weet watter pad geantwoord het en watter een gefaal het nie.

Drie beleide bepaal die antwoord

Elke koppelvlak dra sy eie resolver-lys en soek-agtervoegsels. 'n VPN-adapter voeg bedieners by terwyl die fisiese adapter sy eie hou, en die stelsel kan die een neem wat eerste antwoord, so 'n opsoek kan buite die tonnel bedien word sonder dat iemand dit gekies het. Reels vir die naamresolusiebeleid-tabel kan gekose domeine na gekose bedieners stuur, en dit is hoe split DNS gewoonlik op Windows uitgedruk word. En die VPN-kliënt of gateway kan 'n resolver-adres stoot wat net binne die private netwerk bestaan.

Daardie drie werk op maniere wat van 'n blaaier af willekeurig lyk. 'n Gestootde resolver by 'n private adres sonder 'n roete deur die split-tonnel laat elke opsoek hang en dan misluk. 'n Beleidreel wat die interne agtervoegsel dek en na 'n bediener wys wat af is, lewer dieselfde sigbare fout as 'n ontbrekende roete. 'n Soek-agtervoegsel wat by die VPN-adapter ontbreek verander 'n kort naam in 'n openbare navraag vir die verkeerde domein. Elkeen het 'n ander herstelling nodig.

Waarom 'n blaaier 'n ander vraag vra

nslookup stel sy eie navraag aan die bediener wat hy kies en volg nóg die naamruimtebeleid nóg die blaaier se versleutelde DNS-instelling. Dit is waarom 'n handmatige navraag teen 'n openbare resolver antwoord terwyl die blaaier sê dat die werf nie bestaan nie. Jy vergelyk twee programme, nie twee toestande van een program nie.

Adresfamilie-voorkeur verduidelik vertraging eerder as mislukking. 'n Blaaier wat eerste na IPv6-rekords vra op 'n tonnel wat net IPv4 dra, wag vir 'n tydsverloop voordat dit terugval. Firefox het juis hiervoor 'n voorkeur gedra, en om dit af te skakel is 'n diagnostiese stap eerder as 'n herstelling.

Lees die resolver-lys en die reels

Op Windows, dump wat die stelsel hou voordat jy teoretiseer. Get-DnsClientServerAddress wys die bedieners per koppelvlak, Get-DnsClientNrptRule lys die naamruimtereels, en Resolve-DnsName antwoord die presiese naam deur die stelselpad. Vergelyk daardie antwoord met 'n direkte navraag teen die VPN se bediener per adres. Wanneer Resolve-DnsName misluk en die direkte navraag slaag, is die resolver-lys of 'n naamruimtereel die verdagte.

Kontroleer ook die naam self. 'n Interne kort naam het dalk die private agtervoegsel nodig wat net die VPN-adapter verskaf, terwyl die volle gekwalifiseerde naam fyn oplos. 'n Sertifikaatwaarskuwing ná 'n suksesvolle opsoek hoort by 'n ander probleem.

Die onbereikbare gestootde resolver

'n Gateway of kliënt kan 'n resolver-adres stoot, en daardie adres moet deur die tonnel bereikbaar wees. Op 'n split-tonnel is die private reeks wat die resolver huisves dalk nie in die ingeslote roetes nie, wat 'n opsoek lewer wat nooit 'n antwoord kry nie. Bevestig die roete bestaan, en vra dan daardie adres spesifiek, deur die tonnel. Dit is die mislukking agter 'n blaaier-domeinfout terwyl 'n openbare resolver steeds antwoord.

As die resolver onbereikbaar is, is die herstelling 'n roete of 'n ingeslote subnet, nie 'n ander DNS-bediener nie.

Versleutelde DNS omseil die hele pad

Blaaiers met DNS-over-HTTPS los name self op oor 'n HTTPS-verbinding na 'n gekose verskaffer. Met dit aan word die stelselresolver en die split-DNS-reels heeltemal omseil vir daardie opsoeke, so interne name misluk in die blaaier terwyl die bedryfstelsel hulle korrek oplos. Die omgekeerde gebeur ook: interne name slaag in die blaaier deur 'n verskaffer wat hulle nooit sou moes sien nie, wat 'n beleidsprobleem eerder as 'n verbindingsprobleem is.

Bepaal doelbewus of versleutelde DNS op bestuurde toestelle toegelaat word, en konfigureer dit dan deur die blaaier se bestuuroppervlak sodat die keuse sigbaar is. Om dit aan individuele voorkeur oor te laat, lewer 'n vloot waarin dieselfde VPN op elke skootrekenaar anders werk.

Herstellings wat by die mislukking pas

As die VPN sy resolver stoot, maak dat die tonnel verkeer daarheen dra en maak dieselfde instelling sigbaar op die adapters wat aan resolusie deelneem. As plaaslike werwe ophou oplos terwyl jy gekonnekteer is, voeg eksplisiete naamruimte-uitsonderings of 'n voorwaardelike doorstuurder by in plaas daarvan om die resolver in die geheel te vervang. As die blaaier se versleutelde DNS die beleid omseil, is dit die instelling om te verander. Moet nooit 'n openbare resolver byvoeg om 'n interne naam reg te maak nie: dit lek private navrae en los nie die naam op nie.

Skei dan opsoek van verbinding. 'n Naam wat na die regte adres oplos maar 'n verbinding weier, is 'n diens-, firewall- of sertifikaatprobleem, en DNS-veranderinge sal dit nie regmaak nie.

Teken aan watter pad geantwoord het, watter een gefaal het en wat jy verander het. Die volgende verslag van dieselfde simptoom neem dan een opdrag in plaas van 'n middag.