Váš split tunel sa dostane k aplikácii, ale nie k jej DNS serveru
Split tunel môže smerovať podsieť aplikácie a napriek tomu nechať resolver vedľa nej mimo. Pridajte trasu k hostiteľovi a potom skontrolujte, ktorý server Windows skutočne vyberie.
Smerovanie podsiete aplikácie je zjavná časť split tunela a nie je to celá práca. Resolver často sedí na inej adrese než aplikácia, ktorej slúži, takže fungujúci tunel môže vyhľadávanie nechať mimo. Profil, ktorý nesie 10.80.0.0/16 a nič iné, posiela dopyt na 10.90.0.53 cez miestne rozhranie, kde neexistuje žiadna privátna zóna. Pridajte cestu k resolveru a potom sa pozrite na druhú polovicu problému: ktorý server klient skutočne vyberie.
Mýtus: jedna trasa pokrýva celú službu
Split tunel je zoznam cieľov, ktoré idú cez pripojenie, nie opis služby. Podsieť aplikácie a adresa resolvera sú dva ciele a profil môže niesť jeden bez druhého. Keď sa to stane, aplikácia je dostupná podľa adresy, zatiaľ čo jej meno zlyháva, čo vyzerá ako porucha DNS a nie ako medzera v smerovaní.
Ani podsieť okolo resolvera nie je automaticky pokrytá. Trasa k hostiteľovi na jednu adresu tomu resolveru stačí a jeho susedov neotvorí. V tom je zmysel trasy k hostiteľovi: úzka zámerne a ľahko zabudnuteľná, keď sa ďalšia služba objaví v tej istej podsieti.
Aby vyhľadávanie fungovalo, musia platiť tri veci: klient smeruje adresu resolvera cez tunel, brána ten dopyt prijme a odovzdá a resolver prijme zdroj, ktorý dostane. Odpoveď sa tiež musí vrátiť dohodnutou cestou. Ak chýba čokoľvek z toho, príznak je rovnaký, preto sa oplatí zapísať tabuľku adries predtým, než sa dotknete konfigurácie.
Určite, ktoré adresy musí profil niesť
Vymenujte ciele v poradí: sieť aplikácie, adresu resolvera a verejný koncový bod, ktorý ukončuje samotný tunel. Tretí sa nikdy nesmie smerovať do tunela, pretože vonkajšie pripojenie potrebuje cestu, ktorá existuje pred tunelom.
| 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 aj TCP pre DNS, pretože od implementácií sa očakáva podpora TCP popri UDP a zablokovaná cesta TCP dáva pomalé, čiastočné poruchy namiesto čistých. Ak sa privátna zóna obsluhuje aj cez IPv6, ekvivalentná výnimka pre hostiteľa používa adresu a prefix IPv6 a je samostatnou položkou.
Pred pridaním čohokoľvek si zapíšte, čo profil už pokrýva. Duplicitná trasa je neškodná, ale neočakávaná existujúca trasa vám hovorí, že profil bol navrhnutý pre iný plán adries, než ste dostali.
Pridajte trasu k hostiteľovi cez vlastníka pripojenia
Pri miestne spravovanom natívnom profile Windows patrí trasa pripojeniu, nie globálnej smerovacej tabuľke stroja. Najprv si pridanie pozrite v náhľade a potom ho použite s rovnakým rozsahom, aký profil používa.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Prvý príkaz zobrazí zmenu v náhľade bez toho, aby niečo nainštaloval, a druhý vypíše trasy, ktoré profil práve nesie. Referenčná dokumentácia Microsoftu k Add-VpnConnectionRoute dokumentuje rozsahy pre jednotlivých používateľov a pre všetkých používateľov; profil pre všetkých používateľov potrebuje vlastný parameter rozsahu a príkaz pre jednotlivého používateľa proti profilu pre všetkých používateľov zlyhá alebo skončí na nesprávnom mieste.
Keď je profil spravovaný alebo pochádza z klientskeho programu dodavateľa, zmena patrí tomu vlastníkovi. Vrstvenie trvalej systémovej trasy na zásadu pripojenia funguje dovtedy, kým sa zásada znova nepoužije a trasa nezmizne, čo sa zvyčajne stane počas hovoru s podporou a nie počas testovania. Tá porucha je tichá: trasa zmizne, meno sa prestane vyhľadávať a nikto tie dve udalosti nespojí. Dajte zmenu do vlastného záznamu vlastníka, aby ju ďalšie opakované použitie nieslo, a nie vymazalo.
Po použití profil znova pripojte, namiesto toho, aby ste predpokladali, že trasa nadobudla účinnosť. Zmeny trás na živom pripojení sa nie vždy zachytia a opätovné pripojenie tiež reprodukuje stav, ktorý vaši používatelia skutočne budú mať.
Skontrolujte, ktorý resolver klient skutočne použil
Trasa riadi pakety adresované resolveru. Nerozhoduje, ktoré mená sa tam majú poslať, a tento výber je samostatný mechanizmus. Vo Windows môžu účinné pravidlá menného priestoru zvoliť resolver pre každú doménu, zatiaľ čo nastavenia DNS profilu dodávajú predvolenú hodnotu. Tieto dve vrstvy sa môžu rozísť bez toho, aby vznikla akákoľvek chyba, preto je priamy dopyt len polovica dôkazu.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Prvý príkaz vypíše platnú zásadu menného priestoru a druhý sa súkromného resolvera priamo opýta na názov aplikácie. Priama odpoveď dokazuje, že cesta a resolver fungujú; nedokazuje, že vlastné vyhľadávanie aplikácie zvolilo ten server. Porovnajte ju s bežným vyhľadaním rovnakého mena a s odpoveďou, ktorú aplikácia dostane.
Počítajte s medzipamäťami a so zabezpečeným DNS na úrovni prehliadača, ktoré môže systémový resolver úplne obísť pre mená, ktoré používateľ napísal. Vyhľadávacia prípona je ďalšia falošná stopa: rozširuje krátke meno na plne kvalifikované a nemá nič spoločné s tým, ktorý server odpovedá.
Nakoniec sa znova pripojte a zopakujte bežné vyhľadávanie, potom potvrďte, že bežné prehliadanie stále sleduje svoju schválenú zásadu. Nahradiť súkromný resolver verejným, aby sa vyriešilo nesúvisiace meno, nie je oprava a potichu presúva súkromné dopyty tam, kam nikdy nemali ísť.