A split tunnel eléri az alkalmazást, de a DNS-kiszolgálóját nem

Az alkalmazás alhálózatának irányítása a split tunnel nyilvánvaló része, és nem ez a teljes feladat. A feloldó gyakran más címen ül, mint az alkalmazás, amelyet szolgál, ezért egy működő alagút a lekérdezést még kívül hagyhatja. Az a profil, amely 10.80.0.0/16-ot hordoz és semmi mást, a 10.90.0.53-ra vonatkozó lekérdezést a helyi interfészen küldi ki, ahol nem létezik privát zóna. Adja hozzá a feloldó útvonalát, majd nézze meg a probléma második felét: melyik kiszolgálót választja valójában a kliens.

A mítosz: egy útvonal lefedi az egész szolgáltatást

A split tunnel azon célok listája, amelyek az összeköttetésen keresztül mennek, nem egy szolgáltatás leírása. Az alkalmazás alhálózata és a feloldó címe két cél, és egy profil az egyiket a másik nélkül is hordozhatja. Amikor ez megtörténik, az alkalmazás cím alapján elérhető, miközben a neve meghiúsul, ami inkább DNS-hibának tűnik, mint útvonalhiányosságnak.

A feloldó körüli alhálózat sem fedeződik automatikusan. Egyetlen címre mutató hosztútvonal elegendő ehhez a feloldóhoz, és nem nyitja meg a szomszédait. Ez a hosztútvonal lényege: tervezésében szűk, és könnyű elfelejteni, amikor a következő szolgáltatás ugyanazon az alhálózaton megjelenik.

Három dolognak kell teljesülnie ahhoz, hogy a lekérdezés működjön: a kliens a feloldó címét az alagúton keresztül irányítja, az átjáró elfogadja és továbbítja ezt a kérést, és a feloldó elfogadja a kapott forrást. A válasznak is a megbeszélt úton kell visszatérnie. Ha bármelyik hiányzik, a tünet azonos, ezért érdemes a címtáblát felírni, mielőtt bármilyen konfigurációhoz nyúl.

Határozza meg, mely címeket kell a profilnak hordoznia

Sorolja fel a célokat sorrendben: az alkalmazás hálózatát, a feloldó címét és azt a nyilvános végpontot, amely magát az alagutat lezárja. A harmadikat soha nem szabad az alagútba irányítani, mert a külső kapcsolatnak olyan útra van szüksége, amely az alagút előtt létezik.

A DNS-hez vegye fel az UDP-t és a TCP-t is, mert az implementációktól elvárható, hogy a TCP-t az UDP mellett támogassák, és az elzárt TCP-út lassú, részleges hibákat okoz tiszta hibák helyett. Ha a privát zóna IPv6-on is kiszolgált, az egyenértékű hosztkivétel IPv6-címet és előtagot használ, és külön bejegyzés.

Jegyezze fel, mit fed már le a profil, mielőtt bármit hozzáad. A duplikált útvonal ártalmatlan, de egy váratlan meglévő útvonal azt mondja, hogy a profilt más címtervre tervezték, mint amit kapott.

Adja hozzá a hosztútvonalat az összeköttetés tulajdonosán keresztül

Egy helyben kezelt natív Windows-profilnál az útvonal az összeköttetéshez tartozik, nem a gép globális útválasztási táblázatához. Először tekintse meg előnézetben a hozzáadást, majd alkalmazza ugyanazzal a hatókörrel, amelyet a profil használ.

Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf
Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes

Az első parancs mindent telepítés nélkül mutatja meg a változást, a második pedig felsorolja azokat az útvonalakat, amelyeket a profil jelenleg hordoz. A Microsoft Add-VpnConnectionRoute-referenciája dokumentálja a felhasználónkénti és a minden felhasználóra vonatkozó hatóköröket; a minden felhasználóra vonatkozó profilnak saját hatókörparaméterre van szüksége, és a felhasználónkénti parancs a minden felhasználóra vonatkozó profil ellen meghiúsul vagy rossz helyre kerül.

Amikor a profilt kezelik, vagy szállítói kliensből származik, a változás ahhoz a tulajdonoshoz tartozik. Egy állandó rendszerútvonal ráhalmozása egy kapcsolati házirendre addig működik, amíg a házirendet újra nem alkalmazzák, és az útvonal el nem tűnik, ami általában támogatási hívás közben történik, nem tesztelés közben. Ez a hiba csendes: az útvonal eltűnik, a név feloldása leáll, és senki nem köti össze a két eseményt. Tegye a változást a tulajdonos saját rekordjába, hogy a következő újraalkalmazás hordozza, ne törölje.

Alkalmazás után csatlakoztassa újra a profilt, ahelyett hogy feltételezné, hogy az útvonal életbe lépett. Az élő kapcsolat útvonalváltozásait nem mindig veszik át, és az újracsatlakozás azt az állapotot is újrateremti, amely a felhasználóinál valóban lesz.

Ellenőrizze, melyik feloldót használta valójában a kliens

Az útvonal a feloldóhoz címzett csomagokat szabályozza. Nem dönti el, mely neveket kell oda küldeni, és ez a kiválasztás külön mechanizmus. Windows alatt a tényleges névtérszabályok domainenként választhatnak feloldót, míg a profil DNS-beállításai alapértelmezést adnak. Ez a két réteg hiba nélkül is ellentmondhat egymásnak, ezért a közvetlen lekérdezés csak a bizonyíték fele.

Get-DnsClientNrptPolicy
Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A

Az első parancs kiírja az érvényes névtér-házirendet, a második pedig közvetlenül a privát feloldótól kérdezi az alkalmazás nevét. A közvetlen válasz bizonyítja, hogy az útvonal és a feloldó működik; nem bizonyítja, hogy az alkalmazás saját lekérdezése azt a kiszolgálót választotta. Hasonlítsa össze egy ugyanazon név normál lekérdezésével és azzal a válasszal, amelyet az alkalmazás kap.

Számoljon a gyorsítótárakkal és a böngészőszintű biztonságos DNS-sel, amely teljesen megkerülheti a rendszer feloldóját a felhasználó által beírt neveknél. A keresési utótag egy másik zsákutca: rövid nevet teljesen minősített névvé bővít, és semmi köze ahhoz, melyik kiszolgáló válaszol.

Végül csatlakozzon újra, és ismételje meg a normál lekérdezést, majd erősítse meg, hogy a szokásos böngészés továbbra is a jóváhagyott házirendjét követi. A privát feloldó nyilvánosra cserélése azért, hogy egy független név feloldódjon, nem javítás, és csendesen olyan helyre mozgatja a privát lekérdezéseket, ahová soha nem szánták őket.