Een VPN-route vastgezet op een interface-index breekt bij opnieuw verbinden

De route werkte wekenlang en begon toen verkeer nergens heen te sturen, terwijl de bestemming onveranderd bleef en er niets was bewerkt. Wat veranderde is het nummer: een route die tegen een specifieke interface-index is aangemaakt, verwijst naar een adapter die na een nieuwe verbinding niet meer bestaat, en het bestemmingsprefix blijft wijzen naar infrastructuur die is vervangen. Persistentie aan dat commando toevoegen helpt niet, want het probleem was nooit of de route een herstart overleeft. De oplossing is de bedoeling aan de verbinding te binden, die naar zijn aard adapterwisselingen overleeft.

Controleer waar de route feitelijk naar wijst

Begin met het route-item en de adapters naast elkaar te lezen. Een route met een volgende hop op de VPN-interface en een index die bij geen enkele huidige adapter past, is de signatuur van deze storing; hetzelfde prefix op een andere index is ofwel een restant ofwel de route die je echt wilt. Lees beide lijsten voordat je een van beide wijzigt, want de interessante vergelijking is tussen het nummer in de route en de nummers die nu bestaan. Als de index van de route in de adapterlijst voorkomt, is de index niet je probleem en verschuift het zoeken naar metriek, beleid of de verre kant. Komt hij niet voor, dan valt er niets meer te diagnosticeren: de route hangt aan infrastructuur die niet meer bestaat.

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

De kolom Store onderscheidt een item dat herstarts overleeft van een item dat met de adapter verdwijnt, en dat verschil bepaalt of de storing morgen terugkomt. Een item in de permanente opslag dat naar een verdwenen index wijst, is het slechtste geval, want het overleeft herstarts zonder ooit ergens bij te passen.

Bind het prefix aan het profiel, niet aan de adapter

Een eigen Windows-VPN kan zijn eigen routelijst meedragen, zodat de verbinding telkens de juiste adapter hergebruikt wanneer hij opkomt. De route volgt dan het profiel in plaats van een nummer dat je één keer hebt gezien, en geen enkel script hoeft na elke inbelpoging een index te raden. Een prefix toevoegen is ook omkeerbaar via het bijbehorende verwijdercommando, waardoor de wijziging controleerbaar blijft. Het prefix wordt bij de verbinding opgeslagen in plaats van in een opstartscript, zodat een profiel dat naar een andere gebruiker is gekopieerd de bedoeling meeneemt.

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

De referentie van Add-VpnConnectionRoute documenteert de koppeling aan de verbinding, en de reikwijdte van het telefoonboek is belangrijk: een profiel per gebruiker en een profiel voor alle gebruikers zijn verschillende objecten. Dit mechanisme hoort bij de eigen VPN-client van Windows, dus een leveranciersadapter die door zijn eigen service wordt beheerd, kan zijn routes uit een heel andere beleidsbron halen.

Ruim oude routes op voordat je de nieuwe toevoegt

Twee routes met hetzelfde prefix en verschillende eigenaren zijn erger dan één verkeerde route, want de winnaar hangt af van metriek die niemand heeft opgeschreven. Onderzoek wat er al bestaat voor het prefix, inclusief items in de permanente opslag, en verwijder alleen wat bij de mislukte poging hoort. Een restant uit een eerder ontwerp is hier gebruikelijk, omdat de falende route meestal iets verving dat werkte. Noteer welke items bij welke verbinding horen voordat je iets verwijdert, en houd de lijst bij in het wijzigingsregister.

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

Vergelijk prefix, volgende hop, opslag en eigenaar tegelijk in plaats van alles te wissen wat erop lijkt. Een andere verbinding kan legitiem van een deel van die ruimte afhangen, en een brede verwijdering maakt van een nette reparatie een supportincident.

Verbind opnieuw in een andere volgorde

Reproduceer de voorwaarde in plaats van te hopen dat de eerste poging representatief was. Verbreek de verbinding, verbind opnieuw en bevestig het gekozen pad naar dezelfde externe resource terwijl de tunnel omhoog is; met meerdere VPN's in het spel breng je ze in een andere volgorde omhoog en kijk je of het gekozen pad verandert. Volgorde is de variabele die de meeste mensen overslaan, en juist die legt een route bloot die aan de verkeerde verbinding hangt.

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

Het resultaat dat je wilt is niet dat een adapter zijn nummer één keer behoudt. Het is dat de route verschijnt met welk nummer de verbinding ook krijgt, elke keer, en verdwijnt wanneer de verbinding sluit. Twee keer opnieuw verbinden is de goedkoopste manier om die uitkomsten uit elkaar te houden.

Weet wat de route niet kan

Een profielroute levert een pad en niets anders. Hij opent geen externe firewall, maakt geen retourroute aan de verre kant en lost geen twee locaties op die dezelfde adresreeks gebruiken; elk daarvan is een aparte configuratie met een aparte eigenaar. Het pad bevestigen is daarom het begin van de acceptatietest en niet de hele test.

Houd de prefixlijst bij het profiel en noteer onder welke reikwijdte hij is toegevoegd, zodat de volgende persoon het bedoelde ontwerp kan lezen in plaats van het uit een routetabel af te leiden. Routes die alleen in iemands geheugen bestaan, zijn de routes die na de volgende herverbinding verkeerd worden opgebouwd. Een commentaar van één regel in de uitrolnotities kost minder dan een hele middag herontdekken.