Split-tunnelen din når appen, men ikke DNS-serveren dens
En split-tunnel kan rute appens subnett og likevel slippe resolverserveren ved siden av. Legg til vertsruten, og kontroller deretter hvilken server Windows faktisk velger.
Å rute applikasjonens subnett er den åpenbare delen av en split-tunnel, og det er ikke hele jobben. Resolveren sitter ofte på en annen adresse enn applikasjonen den betjener, så en fungerende tunnel kan likevel la oppslaget ligge utenfor. En profil som bærer 10.80.0.0/16 og ingenting annet, sender forespørselen for 10.90.0.53 ut gjennom det lokale grensesnittet, der det ikke finnes noen privat sone. Legg til ruten til resolveren, og se deretter på den andre halvdelen av problemet: hvilken server klienten faktisk velger.
Myten: én rute dekker hele tjenesten
En split-tunnel er en liste over destinasjoner som går gjennom tilkoblingen, ikke en beskrivelse av en tjeneste. Applikasjonens subnett og resolverens adresse er to destinasjoner, og en profil kan bære den ene uten den andre. Når det skjer, er applikasjonen tilgjengelig på adressen mens navnet svikter, noe som ser ut som en DNS-feil snarere enn et rutingshull.
Subnettet rundt resolveren er heller ikke automatisk dekket. En vertsrute til én enkelt adresse er nok for den resolveren og åpner ikke naboene. Det er poenget med en vertsrute: smal av design, og lett å glemme når den neste tjenesten dukker opp på samme subnett.
Tre ting må holde for at oppslaget skal virke: klienten ruter resolverens adresse gjennom tunnelen, gatewayen godtar og videresender forespørselen, og resolveren godtar kilden den mottar. Et svar må også komme tilbake langs den avtalte veien. Mangler ett av dem, er symptomet identisk, og derfor er det verdt å skrive ned adresstabellen før man rører en konfigurasjon.
Finn ut hvilke adresser profilen må bære
List destinasjonene i rekkefølge: applikasjonsnettet, resolverens adresse og det offentlige endepunktet som avslutter selve tunnelen. Den tredje må aldri rutes inn i tunnelen, fordi den ytre tilkoblingen trenger en vei som finnes 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, siden implementasjoner forventes å støtte TCP i tillegg til UDP, og en blokkert TCP-vei gir langsomme, delvise feil i stedet for rene. Hvis den private sonen også betjenes over IPv6, bruker den tilsvarende vertsunntakelsen en IPv6-adresse og et prefiks og er en egen oppføring.
Noter hva profilen allerede dekker før du legger til noe. En duplikatrute er harmløs, men en uventet eksisterende rute forteller at profilen ble designet for en annen adresseplan enn den du fikk.
Legg til vertsruten gjennom eieren av tilkoblingen
For en lokalt administrert opprinnelig Windows-profil hører ruten til tilkoblingen snarere enn maskinens globale rutetabell. Forhåndsvis tillegget først, og bruk det deretter med samme omfang som profilen bruker.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Den første kommandoen forhåndsviser endringen uten å installere noe, og den andre lister opp rutene profilen bærer nå. Microsofts referanse til Add-VpnConnectionRoute dokumenterer omfangene for enkeltbruker og alle brukere; en profil for alle brukere trenger sin egen omfangsparameter, og en enkeltbrukerkommando mot en profil for alle brukere feiler eller ender på feil sted.
Når profilen administreres eller kommer fra en leverandørklient, hører endringen til den eieren. Å stable en permanent systemrute oppå en tilkoblingspolicy fungerer til policyen brukes på nytt og ruten er borte, noe som vanligvis skjer under en støttesamtale og ikke under testing. Den feilen er stille: ruten forsvinner, navnet slutter å slå opp, og ingen kobler de to hendelsene. Sett endringen i eierens egen post, slik at neste gjenbruk bærer den i stedet for å slette den.
Etter bruk, koble profilen på nytt i stedet for å anta at ruten har trådt i kraft. Ruteendringer på en aktiv tilkobling fanges ikke alltid opp, og en ny tilkobling gjenskaper også tilstanden brukerne dine faktisk vil ha.
Kontroller hvilken resolver klienten faktisk brukte
En rute styrer pakker som er adressert til resolveren. Den avgjør ikke hvilke navn som skal sendes dit, og det valget er en egen mekanisme. På Windows kan effektive navneromsregler velge en resolver per domene, mens profilens DNS-innstillinger gir en standard. De to lagene kan være uenige uten å produsere noen feil, og derfor er en direkte forespørsel bare halve beviset.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Den første kommandoen skriver ut gjeldende navneromspolicy, og den andre spør den private resolveren direkte om applikasjonens navn. Et direkte svar beviser at veien og resolveren virker; det beviser ikke at applikasjonens eget oppslag valgte den serveren. Sammenlign det med et vanlig oppslag av samme navn og med svaret applikasjonen mottar.
Ta høyde for cacher og sikker DNS på nettlesernivå, som kan omgå systemets resolver helt for navn en bruker har skrevet inn. Et søkesuffiks er et annet villspor: det utvider et kort navn til et fullt kvalifisert og har ingenting å gjøre med hvilken server som svarer.
Avslutt med å koble til på nytt og gjenta det vanlige oppslaget, og bekreft deretter at vanlig surfing fortsatt følger sin godkjente policy. Å erstatte den private resolveren med en offentlig for at et urelatert navn skal slås opp er ikke en rettelse, og det flytter stille private forespørsler et sted de aldri var ment å komme.