Split-tunnelen din når appen, men ikkje DNS-tenaren hennar
Ein split-tunnel kan rute subnettet til appen og likevel sleppe resolvaren ved sida av. Legg til vertsruta, og kontroller deretter kva tenar Windows faktisk vel.
Å rute subnettet til applikasjonen er den openberre delen av ein split-tunnel, og det er ikkje heile jobben. Resolvaren sit ofte på ei anna adresse enn applikasjonen han tener, så ein fungerande tunnel kan likevel la oppslaget liggje utanfor. Ein profil som ber 10.80.0.0/16 og ingenting anna, sender førespurnaden for 10.90.0.53 ut gjennom det lokale grensesnittet, der det ikkje finst noka privat sone. Legg til ruta til resolvaren, og sjå deretter på den andre halvdelen av problemet: kva tenar klienten faktisk vel.
Myten: éi rute dekkjer heile tenesta
Ein split-tunnel er ei liste over destinasjonar som går gjennom tilkoplinga, ikkje ei skildring av ei teneste. Subnettet til applikasjonen og adressa til resolvaren er to destinasjonar, og ein profil kan bere den eine utan den andre. Når det skjer, er applikasjonen tilgjengeleg på adressa medan namnet sviktar, noko som ser ut som ein DNS-feil snarare enn eit rutingshol.
Subnettet rundt resolvaren er heller ikkje automatisk dekt. Ei vertsrute til éi einskild adresse er nok for den resolvaren og opnar ikkje naboane. Det er poenget med ei vertsrute: smal av design, og lett å gløyme når den neste tenesta dukkar opp på same subnett.
Tre ting må halde for at oppslaget skal verke: klienten ruter adressa til resolvaren gjennom tunnelen, gatewayen godtek og videresender førespurnaden, og resolvaren godtek kjelda han mottek. Eit svar må òg kome tilbake langs den avtalte vegen. Manglar eitt av dei, er symptomet identisk, og difor er det verdt å skrive ned adressetabellen før ein rører ein konfigurasjon.
Finn ut kva adresser profilen må bere
List destinasjonane i rekkjefølgje: applikasjonsnettet, adressa til resolvaren og det offentlege endepunktet som avsluttar sjølve tunnelen. Den tredje må aldri rutast inn i tunnelen, fordi den ytre tilkoplinga treng ein veg som finst før tunnelen.
| 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 |
Ta med både UDP og TCP for DNS, sidan implementasjonar er venta å støtte TCP i tillegg til UDP, og ein blokkert TCP-veg gjev treige, delvise feil i staden for reine. Viss den private sona òg blir tent over IPv6, brukar den tilsvarande vertsunntaket ei IPv6-adresse og eit prefiks og er ein eigen oppføring.
Noter kva profilen allereie dekkjer før du legg til noko. Ei duplikatrute er harmlaus, men ei uventa eksisterande rute fortel at profilen vart designa for ein annan adresseplan enn den du fekk.
Legg til vertsruta gjennom eigaren av tilkoplinga
For ein lokalt administrert opphavleg Windows-profil høyrer ruta til tilkoplinga snarare enn den globale rutetabellen til maskina. Førehandsvis tillegget fyrst, og bruk det deretter med same omfang som profilen brukar.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Den fyrste kommandoen førehandsviser endringa utan å installere noko, og den andre listar opp rutene profilen ber no. Microsofts referanse til Add-VpnConnectionRoute dokumenterer omfanga for einskildbrukar og alle brukarar; ein profil for alle brukarar treng sin eigen omfangsparameter, og ein einskildbrukarkommando mot ein profil for alle brukarar feilar eller endar på feil stad.
Når profilen blir administrert eller kjem frå ein leverandørklient, høyrer endringa til den eigaren. Å stable ei permanent systemrute oppå ein tilkoplingpolicy verkar til policyen blir brukt på nytt og ruta er borte, noko som vanlegvis skjer under ein støttesamtale og ikkje under testing. Den feilen er stille: ruta forsvinn, namnet sluttar å slå opp, og ingen knyter dei to hendingane saman. Set endringa i eigen posten til eigaren, slik at neste gjenbruk ber henne i staden for å slette henne.
Etter bruk, kople profilen på nytt i staden for å anta at ruta har teke til å gjelde. Ruteendringar på ei aktiv tilkopling blir ikkje alltid fanga opp, og ei ny tilkopling attskapar òg tilstanden brukarane dine faktisk vil ha.
Kontroller kva resolvar klienten faktisk brukte
Ei rute styrer pakkar som er adresserte til resolvaren. Ho avgjer ikkje kva namn som skal sendast dit, og det valet er ein eigen mekanisme. På Windows kan effektive namneromsreglar velje ein resolvar per domene, medan DNS-innstillingane til profilen gjev ein standard. Dei to laga kan vere usamde utan å produsere nokon feil, og difor er ein direkte førespurnad berre halve provet.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Den fyrste kommandoen skriv ut gjeldande namneromspolicy, og den andre spør den private resolvaren direkte om namnet til applikasjonen. Eit direkte svar provar at vegen og resolvaren verkar; det provar ikkje at oppslaget til applikasjonen sjølv valde den tenaren. Samanlikn det med eit vanleg oppslag av same namn og med svaret applikasjonen mottek.
Ta høgd for cache og sikker DNS på nettlesarnivå, som kan omgå resolvaren til systemet heilt for namn ein brukar har skrive inn. Eit søkjesuffiks er eit anna villspor: det utvidar eit kort namn til eit fullt kvalifisert og har ingenting å gjere med kva tenar som svarar.
Avslutt med å kople til på nytt og gjenta det vanlege oppslaget, og stadfest deretter at vanleg surfing framleis følgjer den godkjende policyen sin. Å byte ut den private resolvaren med ein offentleg for at eit urelatert namn skal slåast opp er ikkje ei retting, og det flyttar stille private førespurnader til ein stad dei aldri var meinte å kome.