Váš split tunel dosáhne na aplikaci, ale ne na její DNS server
Split tunel může směrovat podsíť aplikace, a přesto zahodit resolver vedle ní. Přidejte route hostitele a potom zkontrolujte, který server Windows skutečně vybere.
Směrování podsítě aplikace je zřejmá část split tunelu a není to celá práce. Resolver často sedí na jiné adrese než aplikace, které slouží, takže fungující tunel může vyhledávání nechat mimo. Profil, který nese 10.80.0.0/16 a nic jiného, posílá dotaz na 10.90.0.53 přes místní rozhraní, kde žádná privátní zóna neexistuje. Přidejte cestu k resolveru a potom se podívejte na druhou polovinu problému: který server klient skutečně zvolí.
Mýtus: jedna route pokrývá celou službu
Split tunel je seznam cílů, které jdou přes připojení, ne popis služby. Podsíť aplikace a adresa resolveru jsou dva cíle a profil může nést jeden bez druhého. Když se to stane, aplikace je dostupná podle adresy, zatímco její jméno selhává, což vypadá jako porucha DNS, a ne jako mezera ve směrování.
Ani podsíť kolem resolveru není automaticky pokrytá. Route hostitele na jednu adresu tomu resolveru stačí a jeho sousedy neotevře. V tom je smysl route hostitele: úzká záměrně a snadno zapomenutelná, když se další služba objeví ve stejné podsíti.
Aby vyhledávání fungovalo, musí platit tři věci: klient směruje adresu resolveru přes tunel, brána ten požadavek přijme a předá a resolver přijme zdroj, který dostane. Odpověď se také musí vrátit dohodnutou cestou. Chybí-li kterákoli z nich, příznak je stejný, a proto se vyplatí zapsat tabulku adres dřív, než se sáhne na konfiguraci.
Určete, které adresy musí profil nést
Vyjmenujte cíle v pořadí: síť aplikace, adresu resolveru a veřejný koncový bod, který ukončuje samotný tunel. Třetí se nikdy nesmí směrovat do tunelu, protože vnější připojení potřebuje cestu, která existuje dřív než tunel.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
Zahrňte UDP i TCP pro DNS, protože se od implementací očekává podpora TCP vedle UDP a zablokovaná cesta TCP dává pomalé, částečné poruchy místo čistých. Pokud se privátní zóna obsluhuje i přes IPv6, ekvivalentní výjimka pro hostitele používá adresu a prefix IPv6 a je samostatnou položkou.
Než něco přidáte, zapište, co profil už pokrývá. Duplicitní route je neškodná, ale neočekávaná existující route vám říká, že profil byl navržen pro jiný plán adres, než jste dostali.
Přidejte route hostitele přes vlastníka připojení
U místně spravovaného nativního profilu Windows patří route připojení, ne globální směrovací tabulce stroje. Nejprve přidání zobrazte náhledem a potom ho použijte se stejným rozsahem, jaký profil používá.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
První příkaz zobrazí změnu náhledem, aniž by něco instaloval, a druhý vypíše route, které profil právě nese. Referenční dokumentace Microsoftu k Add-VpnConnectionRoute dokumentuje rozsahy pro jednotlivé uživatele a pro všechny uživatele; profil pro všechny uživatele potřebuje vlastní parametr rozsahu a příkaz pro jednotlivého uživatele proti profilu pro všechny uživatele selže nebo skončí na špatném místě.
Když je profil spravovaný nebo pochází z klientského programu dodavatele, změna patří tomu vlastníkovi. Vrstvení trvalé systémové route na zásadu připojení funguje, dokud se zásada znovu nepoužije a route nezmizí, což se obvykle stane během hovoru s podporou, a ne během testování. Ta porucha je tichá: route zmizí, jméno přestane být vyhledáváno a nikdo ty dvě události nespojí. Dejte změnu do vlastního záznamu vlastníka, aby ji příští opakované použití neslo, místo aby ji smazalo.
Po použití profil znovu připojte, místo abyste předpokládali, že route nabyla účinnosti. Změny route na živém připojení se ne vždy zachytí a opětovné připojení také reprodukuje stav, který vaši uživatelé skutečně budou mít.
Zkontrolujte, který resolver klient skutečně použil
Route řídí pakety adresované resolveru. Nerozhoduje, která jména se tam mají poslat, a tento výběr je samostatný mechanismus. Ve Windows mohou účinná pravidla oboru názvů zvolit resolver pro každou doménu, zatímco nastavení DNS profilu dodává výchozí hodnotu. Tyto dvě vrstvy se mohou rozejít, aniž by vznikla jakákoli chyba, a proto je přímý dotaz jen polovina důkazu.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
První příkaz vypíše platnou zásadu oboru názvů a druhý se soukromého resolveru přímo zeptá na jméno aplikace. Přímá odpověď dokazuje, že cesta a resolver fungují; nedokazuje, že vlastní vyhledávání aplikace zvolilo ten server. Porovnejte ji s běžným vyhledáním stejného jména a s odpovědí, kterou aplikace dostane.
Počítejte s mezipamětmi a se zabezpečeným DNS na úrovni prohlížeče, které může systémový resolver úplně obejít pro jména, která uživatel napsal. Vyhledávací přípona je další falešná stopa: rozšiřuje krátké jméno na plně kvalifikované a nemá nic společného s tím, který server odpovídá.
Nakonec se znovu připojte a zopakujte běžné vyhledávání, potom potvrďte, že běžné prohlížení stále sleduje svou schválenou zásadu. Nahradit soukromý resolver veřejným, aby se vyřešilo nesouvisející jméno, není oprava a tiše přesouvá soukromé dotazy tam, kam nikdy neměly jít.