Proč nslookup funguje přes VPN, ale prohlížeč ne

nslookup pošle dotaz na server, který zadáte, a vytiskne odpověď, proto může uspět, zatímco každá karta prohlížeče selhává. Prohlížeč žádá operační systém o přeložení jména a systém zvažuje resolvery jednotlivých rozhraní, pravidla zásad překladu jmen a síťové umístění adaptéru. Pak může prohlížeč přidat ještě vlastní šifrované DNS. Tři různé cesty, jeden příznak a tunel obvykle nebývá rozbitá část.

Následující kontroly jdou po těchto cestách od systému ven. Neupravujte profil VPN, dokud nevíte, která cesta odpověděla a která selhala.

O odpovědi rozhodují tři zásady

Každé rozhraní nese vlastní seznam resolverů a vyhledávací přípony. Adaptér VPN přidává servery, zatímco fyzický adaptér si drží své a systém může vzít ten, který odpoví první, takže vyhledání může být obslouženo mimo tunel, aniž by to někdo zvolil. Pravidla tabulky zásad překladu jmen mohou posílat vybrané domény na vybrané servery, což je obvyklý způsob, jak se split DNS vyjadřuje ve Windows. A klient VPN nebo brána mohou protlačit adresu resolveru, která existuje jen ve vnitřní síti.

Tyto tři se ovlivňují způsoby, které z prohlížeče vypadají nahodile. Protlačený resolver na soukromé adrese bez trasy způsobí, že každé vyhledání v rozděleném tunelu zamrzne a pak selže. Pravidlo zásad pokrývající vnitřní příponu a ukazující na server, který je mimo provoz, dává stejnou viditelnou chybu jako chybějící trasa. Chybějící vyhledávací přípona na adaptéru VPN promění krátké jméno ve veřejný dotaz na špatnou doménu. Každý z nich potřebuje jinou opravu.

Proč se prohlížeč ptá na něco jiného

nslookup vydává vlastní dotaz na server, který si vybere, a neřídí se ani zásadami jmenného prostoru, ani nastavením šifrovaného DNS prohlížeče. Proto ruční dotaz na veřejný resolver odpovídá, zatímco prohlížeč hlásí, že stránka neexistuje. Porovnáváte dva programy, ne dva stavy jednoho programu.

Preference rodiny adres vysvětluje zpoždění, ne selhání. Prohlížeč, který v tunelu nesoucím jen IPv4 žádá nejprve záznamy IPv6, čeká na vypršení časového limitu, než ustoupí. Firefox takovou preferenci měl právě proto a její vypnutí je diagnostický krok, ne oprava.

Přečtěte seznam resolverů a pravidla

Ve Windows vypište, co systém drží, než začnete teoretizovat. Get-DnsClientServerAddress ukazuje servery podle rozhraní, Get-DnsClientNrptRule vypisuje pravidla jmenného prostoru a Resolve-DnsName odpovídá na přesné jméno systémovou cestou. Porovnejte tuto odpověď s přímým dotazem na server VPN podle adresy. Když Resolve-DnsName selže a přímý dotaz uspěje, podezřelý je seznam resolverů nebo pravidlo jmenného prostoru.

Zkontrolujte i samotné jméno. Vnitřní krátké jméno může potřebovat soukromou příponu, kterou dodává jen adaptér VPN, zatímco plně kvalifikované jméno se přeloží dobře. Varování certifikátu po úspěšném vyhledání patří k jinému problému.

Nedostupný protlačený resolver

Brána nebo klient mohou protlačit adresu resolveru a tato adresa musí být dostupná tunelem. Ve split tunelu nemusí být soukromý rozsah obsahující resolver mezi zahrnutými trasami, což vede k vyhledání, které nikdy nedostane odpověď. Potvrďte, že trasa existuje, a pak se tunelem dotažte přímo na tuto adresu. To je selhání za chybou domény v prohlížeči, zatímco veřejný resolver stále odpovídá.

Je-li resolver nedostupný, opravou je trasa nebo zahrnutá podsíť, ne jiný DNS server.

Šifrované DNS obchází celou cestu

Prohlížeče s DNS-over-HTTPS překládají jména samy přes HTTPS spojení ke zvolenému poskytovateli. Když je to zapnuté, systémový resolver a pravidla split DNS se pro tato vyhledání zcela obcházejí, takže vnitřní jména v prohlížeči selhávají, zatímco operační systém je překládá správně. Děje se i opak: vnitřní jména v prohlížeči uspějí přes poskytovatele, který by je nikdy neměl vidět, a to je problém zásad, ne konektivity.

Vědomě rozhodněte, zda je šifrované DNS na spravovaných zařízeních povolené, a pak je nastavte přes správu prohlížeče, aby byla volba viditelná. Ponechání na individuálních preferencích vytváří flotilu, kde se stejná VPN chová na každém notebooku jinak.

Opravy, které odpovídají selhání

Pokud VPN protlačuje svůj resolver, zajistěte, aby tunel nesl provoz k němu a stejné nastavení bylo viditelné na adaptérech účastnících se překladu. Pokud lokální stránky při připojení přestanou překládat, přidejte výslovné výjimky jmenného prostoru nebo podmíněný přeposílač místo plošné výměny resolveru. Pokud šifrované DNS prohlížeče obchází zásady, je to nastavení, které je třeba změnit. Nikdy nepřidávejte veřejný resolver k opravě vnitřního jména: unikají přes něj soukromé dotazy a jméno nepřeloží.

Pak oddělte vyhledání od spojení. Jméno, které se přeloží na správnou adresu, ale odmítá spojení, je problém služby, firewallu nebo certifikátu a změny DNS ho neopraví.

Zapište, která cesta odpověděla, která selhala a co jste změnili. Příští hlášení stejného příznaku pak zabere jeden příkaz místo celého odpoledne.