Twee Windows-VPN’s tegelijk: welk profiel houdt de standaardroute?

Sluit de tweede tunnel aan en de eerste wordt stil, terwijl beide clients nog steeds een gezonde verbinding melden. Windows heeft maar één standaardroute te geven, en elk profiel dat er aanspraak op maakt, neemt hem van het andere af. Het symptoom lijkt op een VPN-storing, maar het is een routestrijd tussen twee profielen. Bepaal welke tunnel die route moet bezitten en de rest van de configuratie volgt.

Slechts één vermelding kan de beste standaard zijn

De IPv4-routetabel houdt één winnende route voor bestemmingen zonder specifiekere overeenkomst. Een VPN-profiel dat zijn eigen route installeert, vervangt de vorige zodra het verbindt, en verkeer dat eerst de eerste tunnel in ging, verlaat nu de tweede. De eerste tunnel blijft actief; wat verdwijnt is elk pakket dat hem voor algemene bestemmingen zou hebben gebruikt.

Statuspictogrammen van de client kunnen dat niet tonen. Ze melden dat een tunnel tot stand is gebracht, niet welke prefixen er nog naartoe worden gerouteerd, dus de gebruiker ziet twee groene pictogrammen en een time-out in een toepassing. route print -4 lezen tijdens de storing is informatiever dan welk VPN-logboek dan ook.

Naamresolutie is een tweede, onafhankelijk conflict, en alleen de routetabel repareren lost het niet op.

Wat het vakje installeert, en wat het verwijdert

De optie staat in de adaptereigenschappen van elk VPN-profiel onder geavanceerde IPv4-instellingen, geformuleerd als het gebruik van de standaardgateway op het externe netwerk. Ingeschakeld voegt elke verbinding een standaardroute via de tunnel toe en zet die interface in de rij voor algemeen verkeer. Uitgeschakeld houdt Windows de route voor het eigen subnet van de tunnel en laat de rest van de tabel met rust.

Bij het uitzetten van het vakje lopen de meeste mensen vast. De externe locatie heeft meestal meer dan één prefix, en geen van die prefixen ligt binnen het adaptersubnet, dus fileservers en beheeradressen antwoorden niet meer. Het vakje heeft de tunnel niet gebroken; het verwijderde de brede route die alles had gedekt.

Gemengde configuraties zijn legitiem en gebruikelijk: een bedrijfsprofiel houdt het vakje als volledige tunnel, terwijl een laboratoriumprofiel gesplitst is zodat het de bedrijfsstandaard niet kan verdringen.

Kies op basis van wat elke tunnel moet dragen

Drie vragen bepalen de opstelling. Moet deze tunnel gewoon internetverkeer dragen, of alleen adressen binnen zijn eigen locatie? Gebruiken de twee locaties gescheiden privébereiken? En als het profiel door een werkgever wordt beheerd, mag u het routegedrag dan überhaupt wijzigen?

Als één tunnel vol moet zijn, bezit die de standaardroute en moet de andere gesplitst zijn. Als geen van beide algemeen internetverkeer nodig heeft, vink het vakje bij beide uit en laat de fysieke adapter de standaardroute houden. Als de bereiken overlappen, stop: 172.22.0.0/16 kan niet één machine aan de bedrijfskant en een andere aan de laboratoriumkant betekenen, en geen enkel vakje lost dat op.

Noteer de beslissing naast de profielnamen. Anders herhaalt een derde VPN die volgend kwartaal wordt toegevoegd het onderzoek vanaf het begin.

Voeg de ontbrekende prefixen toe en test het resultaat

Voeg voor elke gesplitste tunnel de externe bereiken expliciet toe, met het peeradres dat op die adapter wordt getoond in plaats van het openbare serveradres:

> 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

Een PPP-adapter gebruikt zijn peeradres als volgende hop, terwijl een TAP-adapter meestal de gateway gebruikt die op die interface wordt getoond, dus lees de adapterdetails in plaats van een getal uit een gids te kopiëren. Voeg de permanente vlag pas toe nadat de route correct is gebleken, en verwijder oude permanente vermeldingen voordat u vervangingen toevoegt. Beheerde clients kunnen hun eigen routes installeren en beschermen, en dan moet de eigenaar van het profiel de wijziging doorvoeren.

DNS vereist een aparte ronde. Beide tunnels kunnen resolvers opdringen, en Windows houdt per interface een lijst bij met een voorkeursvolgorde, dus een naam van het tweede netwerk kan naar de resolver van het eerste gaan. Kijk wat elke adapter werkelijk heeft ontvangen voordat u een oplossing kiest:

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

Een naamresolutiebeleid per domein is meestal beter dan het vervangen van de globale resolverlijst, omdat die lijst door elke toepassing op de machine wordt gedeeld en een stille wijziging niet-verwante opzoekingen verplaatst.

Accepteer de opstelling met vier controles: één resource in elk extern netwerk bereikbaar via adres, een naamopzoeking in elk, de internetstandaard wijst nog steeds naar de fysieke adapter, en een sessie op afstand die het opkomen van de tweede verbinding overleeft.