Din split tunnel når appen, men ikke dens DNS-server
En split tunnel kan route appens undernet og alligevel tabe resolveren ved siden af. Tilføj værtsruten, og kontroller derefter, hvilken server Windows faktisk vælger.
At route applikationens undernet er den oplagte del af en split tunnel, og det er ikke hele opgaven. Resolveren sidder ofte på en anden adresse end den applikation, den betjener, så en fungerende tunnel kan stadig efterlade opslaget uden for den. En profil, der bærer 10.80.0.0/16 og intet andet, sender forespørgslen for 10.90.0.53 ud gennem den lokale grænseflade, hvor der ikke findes nogen privat zone. Tilføj resolverens rute, og se derefter på den anden halvdel af problemet: hvilken server klienten faktisk vælger.
Myten: én rute dækker hele tjenesten
En split tunnel er en liste af destinationer, der går gennem forbindelsen, ikke en beskrivelse af en tjeneste. Applikationens undernet og resolverens adresse er to destinationer, og en profil kan bære den ene uden den anden. Når det sker, er applikationen tilgængelig på adressen, mens navnet fejler, hvilket ser ud som en DNS-fejl snarere end et rutningshul.
Undernettet omkring resolveren er heller ikke automatisk dækket. En værtsrute til en enkelt adresse er nok til den resolver og åbner ikke naboerne. Det er pointen med en værtsrute: smal af design og let at glemme, når den næste tjeneste dukker op på samme undernet.
Tre ting skal holde, for at opslaget virker: klienten router resolverens adresse gennem tunnelen, gatewayen tillader og videresender den anmodning, og resolveren accepterer den kilde, den modtager. Et svar skal også komme tilbage ad den aftalte vej. Mangler blot én af dem, er symptomet det samme, og derfor er det værd at skrive adressetabellen ned, før man rører en konfiguration.
Afgør, hvilke adresser profilen skal bære
List destinationerne i rækkefølge: applikationsnetværket, resolverens adresse og det offentlige endepunkt, der afslutter selve tunnelen. Den tredje må aldrig routes ind i tunnelen, fordi den ydre forbindelse har brug for en vej, der findes, før tunnelen gør.
| 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 |
Medtag både UDP og TCP til DNS, da implementeringer forventes at understøtte TCP såvel som UDP, og en blokeret TCP-vej giver langsomme, delvise fejl i stedet for rene. Hvis den private zone også betjenes over IPv6, bruger den tilsvarende værtsundtagelse en IPv6-adresse og et præfiks og er en separat post.
Notér, hvad profilen allerede dækker, før du tilføjer noget. En dubletrute er harmløs, men en uventet eksisterende rute fortæller, at profilen blev designet til en anden adresseplan end den, du fik.
Tilføj værtsruten gennem forbindelsens ejer
For en lokalt administreret oprindelig Windows-profil hører ruten til forbindelsen snarere end maskinens globale rutningstabel. Se tilføjelsen efter først, og anvend den derefter med samme omfang, som profilen bruger.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Den første kommando viser ændringen uden at installere noget, og den anden lister de ruter, profilen aktuelt bærer. Microsofts reference til Add-VpnConnectionRoute dokumenterer omfangene for enkeltbruger og alle brugere; en profil for alle brugere har brug for sin egen omfangsparameter, og en enkeltbrugerkommando mod en profil for alle brugere fejler eller lander det forkerte sted.
Når profilen administreres eller kommer fra en leverandørklient, hører ændringen til den ejer. At stable en permanent systemrute oven på en forbindelsespolitik virker, indtil politikken anvendes igen, og ruten er væk, hvilket normalt sker under et supportopkald snarere end under test. Den fejl er tavs: ruten forsvinder, navnet holder op med at slå op, og ingen forbinder de to hændelser. Sæt ændringen i ejerens egen post, så den næste genanvendelse bærer den i stedet for at slette den.
Efter anvendelsen skal du genoprette forbindelsen til profilen i stedet for at antage, at ruten har virket. Ruteændringer på en aktiv forbindelse bliver ikke altid opfanget, og en genopkobling genskaber også den tilstand, dine brugere faktisk vil have.
Kontroller, hvilken resolver klienten faktisk brugte
En rute styrer pakker, der er adresseret til resolveren. Den afgør ikke, hvilke navne der skal sendes dertil, og det valg er en separat mekanisme. På Windows kan effektive navnerumsregler vælge en resolver pr. domæne, mens profilens DNS-indstillinger leverer en standard. De to lag kan være uenige uden at producere nogen fejl, og derfor er en direkte forespørgsel kun halvdelen af beviset.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Den første kommando udskriver den gældende navnerumspolitik, og den anden spørger den private resolver direkte om applikationens navn. Et direkte svar beviser, at vejen og resolveren virker; det beviser ikke, at applikationens eget opslag valgte den server. Sammenlign det med et normalt opslag af samme navn og med det svar, applikationen modtager.
Tag højde for caches og for sikker DNS på browserniveau, som kan omgå systemets resolver helt for navne, en bruger har tastet. Et søgesuffiks er et andet vildspor: det udvider et kort navn til et fuldt kvalificeret og har intet at gøre med, hvilken server der svarer.
Slut af med at genoprette forbindelsen og gentage det normale opslag, og bekræft derefter, at almindelig browsing stadig følger sin godkendte politik. At erstatte den private resolver med en offentlig for at få et urelateret navn til at slå op er ikke en rettelse, og det flytter stille private forespørgsler et sted, de aldrig var ment at komme.