Två Windows-VPN samtidigt: vilken profil behåller standardrutten?

Anslut den andra tunneln och den första tystnar, medan båda klienterna fortfarande rapporterar en frisk anslutning. Windows har bara en standardrutt att ge, och varje profil som kräver den tar den från den andra. Symtomet ser ut som ett VPN-avbrott, men det är en rutstrid mellan två profiler. Bestäm vilken tunnel som ska äga rutten, och resten av konfigurationen följer.

Bara en post kan vara den bästa standardrutten

IPv4-routingtabellen håller en enda vinnande rutt för destinationer utan en mer specifik matchning. En VPN-profil som installerar sin egen ersätter den föregående så snart den ansluter, och trafik som tidigare gick in i den första tunneln går nu ut genom den andra. Den första tunneln ligger kvar; det som försvinner är varje paket som skulle ha använt den för allmänna destinationer.

Klientstatusikoner kan inte visa det. De rapporterar att en tunnel upprättades, inte vilka prefix som fortfarande dirigeras dit, så användaren ser två gröna ikoner och en tidsgräns i någon applikation. Att läsa route print -4 under felet är mer informativt än någon VPN-logg.

Namnuppslagning är en andra, oberoende konflikt, och att bara rätta routingtabellen löser den inte.

Vad bocken installerar och vad den tar bort

Alternativet finns i varje VPN-profils adapteregenskaper under avancerade IPv4-inställningar, formulerat som att använda standardgatewayen på fjärrnätverket. Påslaget lägger varje anslutning till en standardrutt genom tunneln och ställer det gränssnittet i kön för allmän trafik. Avslaget behåller Windows rutten för tunnelns eget subnät och låter resten av tabellen vara.

Det är när bocken tas bort som de flesta fastnar. Fjärrplatsen har vanligtvis mer än ett prefix, och inget av dessa prefix ligger i adapterns subnät, så filservrar och hanteringsadresser slutar svara. Bocken bröt inte tunneln; den tog bort den breda rutt som hade täckt allt.

Blandade konfigurationer är legitima och vanliga: en företagsprofil behåller bocken som full tunnel, medan en laboratorieprofil är delad så att den inte kan tränga undan företagets standardrutt.

Välj efter vad varje tunnel måste bära

Tre frågor avgör upplägget. Måste denna tunnel bära vanlig internettrafik, eller bara adresser inom sin egen plats? Använder de två platserna åtskilda privata intervall? Och om profilen hanteras av en arbetsgivare, får du alls ändra dess routingbeteende?

Om en tunnel måste vara full äger den standardrutten, och den andra måste vara delad. Om ingen av dem behöver allmän internettrafik, ta bort bocken på båda och låt den fysiska adaptern behålla standardrutten. Om intervallen överlappar, stoppa: 172.22.0.0/16 kan inte betyda en maskin på företagssidan och en annan på laboratoriesidan, och ingen bock löser det.

Skriv ned beslutet bredvid profilnamnen. Annars upprepar en tredje VPN som läggs till nästa kvartal utredningen från början.

Lägg till de saknade prefixen och testa resultatet

För varje delad tunnel, lägg till fjärrområdena uttryckligen, med den peer-adress som visas på den adaptern i stället för serverns publika adress:

> route add 172.22.0.0 mask 255.255.0.0 172.20.4.1
> route print -4
> Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric

En PPP-adapter använder sin peer-adress som nästa hopp, medan en TAP-adapter vanligtvis använder gatewayen som visas på det gränssnittet, så läs adapteruppgifterna i stället för att kopiera ett tal från en guide. Lägg till den beständiga flaggan först efter att rutten har visat sig korrekt, och radera gamla beständiga poster innan du lägger till ersättare. Hanterade klienter kan installera och skydda sina egna rutter, och då måste profilägaren göra ändringen.

DNS behöver en egen omgång. Båda tunnlarna kan trycka ut resolvers, och Windows håller en lista per gränssnitt med en preferensordning, så ett namn som hör till det andra nätverket kan skickas till det första nätverkets resolver. Titta på vad varje adapter faktiskt fick innan du väljer en åtgärd:

> Get-DnsClientServerAddress -AddressFamily IPv4
> Resolve-DnsName files.corp.internal -Server 172.20.4.1

En namnupplösningspolicy per domän är vanligtvis bättre än att ersätta den globala resolverlistan, eftersom listan delas av varje program på maskinen och en tyst ändring flyttar orelaterade slagningar.

Acceptera uppsättningen med fyra kontroller: en resurs i varje fjärrnätverk nådd via adress, en namnsökning i varje, internetstandarden pekar fortfarande på den fysiska adaptern, och en fjärrskrivbordssession som överlever att den andra anslutningen kommer upp.