Din delade tunnel når appen men inte dess DNS-server
En delad tunnel kan routa appens subnät och ändå tappa resolveraren bredvid. Lägg till värdrutten och kontrollera sedan vilken server Windows faktiskt väljer.
Att routa applikationens subnät är den självklara delen av en delad tunnel, och det är inte hela jobbet. Resolveraren sitter ofta på en annan adress än applikationen den betjänar, så en fungerande tunnel kan ändå lämna uppslaget utanför. En profil som bär 10.80.0.0/16 och ingenting annat skickar frågan för 10.90.0.53 ut genom det lokala gränssnittet, där ingen privat zon finns. Lägg till vägen till resolveraren och titta sedan på den andra halvan av problemet: vilken server klienten faktiskt väljer.
Myten: en rutt täcker hela tjänsten
En delad tunnel är en lista över destinationer som går genom anslutningen, inte en beskrivning av en tjänst. Applikationens subnät och resolverarens adress är två destinationer, och en profil kan bära den ena utan den andra. När det händer är applikationen nåbar via adressen medan namnet misslyckas, vilket ser ut som ett DNS-fel snarare än en routinglucka.
Subnätet kring resolveraren är inte heller automatiskt täckt. En värdrutt till en enda adress räcker för den resolveraren och öppnar inte dess grannar. Det är poängen med en värdrutt: smal av design och lätt att glömma när nästa tjänst dyker upp i samma subnät.
Tre saker måste gälla för att uppslaget ska fungera: klienten routar resolverarens adress genom tunneln, gatewayen tar emot och vidarebefordrar begäran, och resolveraren accepterar den källa den får. Svaret måste också komma tillbaka via den avtalade vägen. Saknas något av det är symptomet identiskt, därför är det värt att skriva ned adresstabellen innan man rör en konfiguration.
Bestäm vilka adresser profilen måste bära
Lista destinationerna i ordning: applikationens nät, resolverarens adress och den publika slutpunkten som avslutar själva tunneln. Den tredje får aldrig routas in i tunneln, eftersom den yttre anslutningen behöver en väg som finns innan tunneln.
| 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 och TCP för DNS, eftersom implementeringar förväntas stödja TCP vid sidan av UDP, och en blockerad TCP-väg ger långsamma, partiella fel i stället för rena. Om den privata zonen också betjänas över IPv6 använder motsvarande värdunntag en IPv6-adress och ett prefix och är en separat post.
Anteckna vad profilen redan täcker innan du lägger till något. En dubbelrutt är ofarlig, men en oväntad befintlig rutt säger att profilen designades för en annan adressplan än den du fick.
Lägg till värdrutten via anslutningens ägare
För en lokalt hanterad inhemsk Windows-profil hör rutten till anslutningen snarare än maskinens globala routingtabell. Förhandsgranska tillägget först och använd det sedan med samma omfång som profilen använder.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Det första kommandot förhandsgranskar ändringen utan att installera något, och det andra listar de rutter som profilen bär just nu. Microsofts referens för Add-VpnConnectionRoute dokumenterar omfången per användare och för alla användare; en profil för alla användare behöver sin egen omfångsparameter, och ett kommando per användare mot en profil för alla användare misslyckas eller hamnar på fel ställe.
När profilen hanteras eller kommer från en leverantörsklient tillhör ändringen den ägaren. Att stapla en permanent systemrutt ovanpå en anslutningspolicy fungerar tills policyn tillämpas igen och rutten är borta, vilket oftast händer under ett supportsamtal och inte under testning. Det felet är tyst: rutten försvinner, namnet slutar slås upp och ingen kopplar ihop de två händelserna. Lägg ändringen i ägarens egen post så att nästa återtillämpning bär den i stället för att radera den.
Efter tillämpningen, återanslut profilen i stället för att anta att rutten trätt i kraft. Ruttändringar på en aktiv anslutning fångas inte alltid upp, och en återanslutning återskapar också det tillstånd som dina användare faktiskt kommer att ha.
Kontrollera vilken resolver klienten faktiskt använde
En rutt styr paket som är adresserade till resolveraren. Den avgör inte vilka namn som ska skickas dit, och det valet är en egen mekanism. I Windows kan effektiva namnrymdsregler välja en resolver per domän, medan profilens DNS-inställningar ger en standard. De två lagren kan vara oense utan att producera något fel, och därför är en direkt fråga bara halva beviset.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Det första kommandot skriver ut gällande namnrymdspolicy, och det andra frågar den privata resolveraren direkt efter applikationens namn. Ett direkt svar bevisar att vägen och resolveraren fungerar; det bevisar inte att applikationens eget uppslag valde den servern. Jämför det med ett vanligt uppslag av samma namn och med svaret som applikationen får.
Ta hänsyn till cachar och säkert DNS på webbläsarnivå, som helt kan kringgå systemets resolver för namn som en användare har skrivit. Ett söksuffix är ett annat villospår: det expanderar ett kort namn till ett fullt kvalificerat och har inget att göra med vilken server som svarar.
Avsluta med att återansluta och upprepa det vanliga uppslaget, och bekräfta sedan att vanligt surfande fortfarande följer sin godkända policy. Att ersätta den privata resolveraren med en publik för att ett orelaterat namn ska slås upp är ingen lagning, och det flyttar tyst privata frågor någonstans de aldrig var tänkta att hamna.