Teie split-tunnel jõuab rakenduseni, aga mitte selle DNS-serverini
Split-tunnel võib rakenduse alavõrgu marsruutida ja jätta siiski kõrval oleva resolveri välja. Lisage hosti marsruut ja kontrollige seejärel, millise serveri Windows tegelikult valib.
Rakenduse alavõrgu marsruutimine on split-tunneli ilmne osa ja see ei ole kogu töö. Resolver asub sageli teisel aadressil kui rakendus, mida see teenindab, nii et töötav tunnel võib päringu sellest väljapoole jätta. Profiil, mis kannab 10.80.0.0/16 ja mitte midagi muud, saadab 10.90.0.53 päringu kohaliku liidese kaudu, kus privaatset tsooni ei ole. Lisage resolveri marsruut ja vaadake seejärel probleemi teist poolt: millise serveri klient tegelikult valib.
Müüt: üks marsruut katab kogu teenuse
Split-tunnel on ühendusest läbi minevate sihtkohtade loend, mitte teenuse kirjeldus. Rakenduse alavõrk ja resolveri aadress on kaks sihtkohta ning profiil võib kanda ühte ilma teiseta. Kui see juhtub, on rakendus aadressi järgi kättesaadav, samal ajal kui selle nimi ebaõnnestub, mis näeb välja nagu DNS-i rike, mitte marsruutimise lünk.
Ka resolverit ümbritsev alavõrk ei ole automaatselt kaetud. Hosti marsruut ühele aadressile on selle resolveri jaoks piisav ega ava selle naabreid. See ongi hosti marsruudi mõte: kavatsuselt kitsas ja kergesti ununev, kui järgmine teenus samas alavõrgus ilmub.
Päringu toimimiseks peavad kehtima kolm asja: klient marsruudib resolveri aadressi läbi tunneli, lüüs võtab selle taotluse vastu ja edastab selle ning resolver võtab vastu allika, mille see saab. Vastus peab samuti naasma kokkulepitud teel. Kui üks neist puudub, on sümptom sama, seepärast tasub aadressitabel enne konfiguratsiooni puutumist üles kirjutada.
Määrake, milliseid aadresse peab profiil kandma
Loetlege sihtkohad järjekorras: rakenduse võrk, resolveri aadress ja avalik lõpp-punkt, mis tunneli enda lõpetab. Kolmandat ei tohi kunagi tunnelisse marsruutida, sest välimine ühendus vajab teed, mis on olemas enne tunnelit.
| 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 |
Kaasake DNS-i jaoks nii UDP kui ka TCP, sest teostustelt eeldatakse TCP toetust UDP kõrval ning blokeeritud TCP tee annab aeglaseid ja osalisi tõrkeid puhta tõrke asemel. Kui privaatset tsooni teenindatakse ka IPv6 kaudu, kasutab samaväärne hosti erand IPv6 aadressi ja prefiksit ning on eraldi kirje.
Kirjutage üles, mida profiil juba katab, enne kui midagi lisate. Dubleeritud marsruut on kahjutu, kuid ootamatu olemasolev marsruut ütleb, et profiil kavandati teistsuguse aadressiplaani jaoks kui see, mille saite.
Lisage hosti marsruut ühenduse omaniku kaudu
Kohalikult hallatava natiivse Windowsi profiili puhul kuulub marsruut ühendusele, mitte masina üldisele marsruutimistabelile. Eelvaadake lisamist esmalt ja rakendage seda seejärel sama ulatusega, mida profiil kasutab.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Esimene käsk näitab muudatust eelvaates ilma midagi paigaldamata ja teine loetleb marsruudid, mida profiil praegu kannab. Microsofti viide Add-VpnConnectionRoute'ile dokumenteerib üksikkasutaja ja kõigi kasutajate ulatused; kõigi kasutajate profiil vajab oma ulatusparameetrit ning üksikkasutaja käsk kõigi kasutajate profiili vastu ebaõnnestub või maandub valesse kohta.
Kui profiili hallatakse või see tuleb tarnija kliendist, kuulub muudatus sellele omanikule. Alalise süsteemse marsruudi kuhjamine ühenduspoliitika peale toimib seni, kuni poliitika uuesti rakendatakse ja marsruut kaob, mis juhtub tavaliselt tugikõne ajal, mitte testimise ajal. See rike on vaikne: marsruut kaob, nimi lakkab lahendamast ja keegi ei seosta neid kahte sündmust. Pange muudatus omaniku enda kirjesse, et järgmine uuesti rakendamine seda kannaks, mitte ei kustutaks.
Pärast rakendamist ühendage profiil uuesti, selle asemel et eeldada, et marsruut mõjus. Marsruudimuudatusi aktiivsel ühendusel ei võeta alati vastu ja uuesti ühendamine taastoodab ka oleku, mis teie kasutajatel tegelikult on.
Kontrollige, millist resolverit klient tegelikult kasutas
Marsruut juhib resolverile adresseeritud pakette. See ei otsusta, millised nimed sinna saata, ja see valik on eraldi mehhanism. Windowsis võivad kehtivad nimeruumireeglid valida resolveri domeeni kaupa, samal ajal kui profiili DNS-seaded annavad vaikeväärtuse. Need kaks kihti võivad lahkneda ilma ühegi veata, seepärast on otsene päring vaid pool tõendist.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Esimene käsk prindib kehtiva nimeruumipoliitika ja teine küsib privaatselt resolverilt otse rakenduse nime. Otsene vastus tõestab, et tee ja resolver töötavad; see ei tõesta, et rakenduse enda päring valis just selle serveri. Võrrelge seda sama nime tavalise päringuga ja vastusega, mille rakendus saab.
Arvestage vahemälu ja brauseritasemel turvalise DNS-iga, mis võib kasutaja trükitud nimede puhul süsteemi resolveri täielikult mööda minna. Otsingusufiks on veel üks eksitav jälg: see laiendab lühikese nime täielikult kvalifitseerituks ega puutu kuidagi sellesse, milline server vastab.
Lõpetuseks ühendage uuesti ja korrake tavalist päringut, seejärel kinnitage, et tavaline sirvimine järgib endiselt oma kinnitatud poliitikat. Privaatse resolveri asendamine avalikuga, et lahendada mitteseotud nimi, ei ole parandus ja see liigutab privaatsed päringud vaikselt sinna, kuhu neid kunagi ei kavatsetud saata.