VPN-roete vasgepen aan 'n koppelvlakindeks breek by herverbinding
'n Roete wat aan 'n adapternommer gekoppel is, sterf wanneer daardie nommer verander. Kyk na die stoor, bind die voorvoegsel aan die profiel en herverbind dan in 'n nuwe volgorde.
Die roete het weke lank gewerk en toe begin om verkeer nêrens heen te stuur, terwyl die bestemming onveranderd gebly het en niks geredigeer is. Wat verander het, is die nommer: 'n roete wat teen 'n spesifieke koppelvlakindeks geskep is, verwys na 'n adapter wat ná 'n herverbinding nie meer bestaan nie, en die bestemmingsvoorvoegsel bly wys na infrastruktuur wat vervang is. Om volharding by daardie opdrag te voeg, help nie, want die probleem was nooit of die roete 'n herlaai oorleef nie. Die oplossing is om die bedoeling aan die verbinding te koppel, wat per ontwerp adapterveranderinge oorleef.
Kontroleer waarheen die roete werklik wys
Begin deur die roete-inskrywing en die adapters langs mekaar te lees. 'n Roete met 'n volgende sprong op die VPN-koppelvlak en 'n indeks wat by geen huidige adapter pas nie, is die kenmerk van hierdie fout; dieselfde voorvoegsel op 'n ander indeks is óf 'n oorblyfsel óf die roete wat jy werklik wil hê. Lees albei lyste voordat jy enigeen verander, want die interessante vergelyking is tussen die nommer in die roete en die nommers wat tans bestaan. As die roete se indeks in die adapterlys voorkom, is die indeks nie jou probleem nie en skuif die soektog na metrieke, beleid of die verre kant. As dit nie voorkom nie, hoef niks verder gediagnoseer te word nie: die roete is aan infrastruktuur gekoppel wat nie meer bestaan nie.
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
Die Store-kolom onderskei 'n inskrywing wat oor herlaaie heen bly bestaan van een wat saam met die adapter verdwyn, en daardie verskil bepaal of die fout môre weer opduik. 'n Inskrywing in die blywende stoor wat na 'n verdwene indeks wys, is die ergste geval, want dit oorleef herstarts terwyl dit nooit by enigiets pas nie.
Bind die voorvoegsel aan die profiel, nie aan die adapter nie
'n Inheemse Windows VPN kan sy eie roetelys dra, sodat die verbinding die korrekte adapter hergebruik wanneer dit opkom. Die roete volg dan die profiel eerder as 'n nommer wat jy een keer gesien het, en geen skrip hoef ná elke skakeling 'n indeks te raai nie. Om 'n voorvoegsel by te voeg, is ook omkeerbaar deur die ooreenstemmende verwyderingsopdrag, wat die verandering auditeerbaar hou. Die voorvoegsel word saam met die verbinding gestoor eerder as in 'n opstartskrip, sodat 'n profiel wat na 'n ander gebruiker gekopieer word, die bedoeling saamdra.
Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru
Die Add-VpnConnectionRoute-verwysing dokumenteer die verbindingassosiasie, en die telefoonboekomvang maak saak: 'n profiel per gebruiker en 'n profiel vir alle gebruikers is verskillende objekte. Hierdie meganisme behoort aan Windows se eie VPN-kliënt, so 'n verskafferadapter wat deur sy eie diens bestuur word, kan sy roetes uit 'n heeltemal ander beleidsbron kry.
Maak ou roetes skoon voordat jy die nuwe een byvoeg
Twee roetes met dieselfde voorvoegsel en verskillende eienaars is erger as een verkeerde roete, want die wenner hang af van metrieke wat niemand neergeskryf het nie. Ondersoek wat reeds vir die voorvoegsel bestaan, insluitend inskrywings in die blywende stoor, en verwyder net wat aan die mislukte poging behoort. 'n Oorblyfsel van 'n vorige ontwerp is algemeen in hierdie area, want die falende roete het gewoonlik iets vervang wat vroeër gewerk het. Let op watter inskrywings aan watter verbinding behoort voordat jy enigiets verwyder, en hou die lys in die veranderingsrekord.
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
Pas op voorvoegsel, volgende sprong, stoor en eienaar saam eerder as om alles te verwyder wat soortgelyk lyk. 'n Ander verbinding kan wettiglik op 'n deel van daardie ruimte staatmaak, en 'n veegverwydering verander 'n netjiese herstelling in 'n ondersteuningsinsident.
Herverbind in 'n ander volgorde
Reproduseer die toestand eerder as om te hoop die eerste poging was verteenwoordigend. Ontkoppel, herverbind en bevestig die gekose pad na dieselfde afgeleë hulpbron terwyl die tonnel op is; met verskeie VPN's in die spel, bring hulle in 'n ander volgorde op en kyk of die gekose pad verander. Volgorde is die veranderlike wat die meeste mense oorslaan, en dit is die een wat 'n roete ontbloot wat aan die verkeerde verbinding gekoppel is.
rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1
Die resultaat wat jy wil hê, is nie dat 'n adapter sy nommer een keer behou nie. Dit is dat die roete verskyn met watter nommer die verbinding ook al kry, elke keer, en verdwyn wanneer die verbinding sluit. Om twee keer te herverbind is die goedkoopste manier om daardie uitkomste uitmekaar te hou.
Weet wat die roete nie kan doen nie
'n Profielroete verskaf 'n pad en niks anders nie. Dit maak nie 'n afgeleë firewall oop nie, skep nie 'n terugroete aan die verre kant nie, en los nie twee terreine op wat dieselfde adresreeks gebruik nie; elkeen daarvan is 'n aparte konfigurasie met 'n aparte eienaar. Om die pad te bevestig is dus die begin van die aanvaardingstoets eerder as die geheel daarvan.
Hou die voorvoegsellys by die profiel en let op onder watter omvang dit bygevoeg is, sodat die volgende persoon die beoogde ontwerp kan lees eerder as om dit uit 'n roetetabel af te lei. Roetes wat net in iemand se geheue bestaan, is diegene wat ná die volgende herverbinding verkeerd herbou word. 'n Eenreëlkommentaar in die ontplooiingsnotas kos minder as 'n middag se herontdekking.