Windows VPN: opgeslagen profiel tegenover de status van de actieve interface

Een Windows VPN verschijnt op twee plaatsen die verschillende vragen beantwoorden, en ze door elkaar halen levert een zelfverzekerde maar verkeerde diagnose op. Het opgeslagen profiel zegt wat iemand heeft geconfigureerd; de actieve interface zegt wat de stack zojuist heeft toegepast. Wanneer een verbinding tot stand komt en het verkeer nog steeds de verkeerde weg neemt, moeten beide weergaven worden gelezen, in die volgorde. Geen van beide alleen vertelt u of het pakket van de toepassing door de tunnel is gegaan.

Twee weergaven van dezelfde tunnel

De profielweergave is configuratie: serveradres, tunneltype, authenticatiemethode, instellingen voor gesplitste tunnel. Hij kan correct zijn terwijl de verbinding hem negeert, en hij kan verouderd zijn terwijl de verbinding perfect werkt, omdat een client die opnieuw verbindt misschien niet opnieuw leest wat u hebt bewerkt. De interfaceweergave is toegepaste toestand: welke adapters bestaan, welke adresfamilies ze dragen, hun metriek en hun verbindingsstatus. Hij verandert wanneer tunnels komen en gaan, waardoor het de juiste plek is voor een vraag over live routing en de verkeerde plek voor een configuratievraag.

Ze samen lezen is de hele methode, en een van beide alleen lezen is hoe mensen uiteindelijk een gezonde adapter verwijderen. De opdrachten hieronder leveren beide weergaven zonder iets te wijzigen.

Lees beide weergaven zonder iets te wijzigen

Begin met de opgeslagen profielen, want dat is het goedkoopste feit om te bevestigen. Let op het tunneltype en de waarde voor gesplitste tunnel, omdat beide bepalen welke bestemmingen überhaupt de tunnel in moeten. Als het profiel onjuist is, herstel het dan via het ondersteunde configuratieoppervlak, want niets in de interfacelijst repareert een profiel dat naar een verkeerde gateway wijst.

Get-VpnConnection | Select-Object Name,ServerAddress,TunnelType,SplitTunneling,ConnectionStatus

De interfaceweergave heeft een andere vorm: één tunnel kan twee rijen innemen wanneer hij beide adresfamilies draagt. Lees de index als de identiteit en de alias als een label dat iemand heeft gekozen, en verwacht dat de alias tussen clientversies verandert.

Get-NetIPInterface | Select-Object InterfaceIndex,InterfaceAlias,AddressFamily,ConnectionState,InterfaceMetric

Aanwezigheid is geen bewijs van gebruik, want een interface kan bestaan, verbonden zijn en toch niet degene zijn die de route naar uw bestemming kiest. Houd dat in gedachten voordat u een onbekende adapter als de fout behandelt. Deze twee storingen zien er van buiten identiek uit: een correct profiel met een route die het nooit gebruikt, en een onjuist profiel met een route die het wel gebruikt. Ze hebben volledig verschillende oplossingen, en daarom bestaat de volgende sectie.

Volg de route naar de bestemming

Vraag de stack welk pad hij zou nemen voor het adres dat de toepassing werkelijk benadert. Dat is de vraag die de interfacelijst niet alleen kan beantwoorden.

Find-NetRoute -RemoteIPAddress 10.60.20.10 | Select-Object -First 1
Get-NetIPAddress -InterfaceIndex 37 | Select-Object IPAddress,AddressFamily,PrefixLength

De eerste opdracht meldt twee velden die het lezen waard zijn: de interfacealias van de gekozen bron en de volgende hop voor die bestemming. De index 37 in de tweede opdracht is wat de eerste uitvoer heeft afgedrukt, geen constante om te kopiëren, en het adres 10.60.20.10 is illustratief. Als de gekozen bron bij de fysieke adapter hoort terwijl de bestemming binnen de tunnel zou moeten liggen, hebt u het selectieprobleem gevonden, want de VPN-interface kan volledig gezond zijn en simpelweg niet worden verkozen. Een metriek is slechts een deel van die beslissing, omdat routespecificiteit, beleid en interfacetoestand allemaal meedoen.

Vergelijk drie toestanden onder dezelfde omstandigheden

Leg de interfacelijst en de gekozen route vast vóór het verbinden, terwijl u verbonden bent en na het verbreken, elke keer met dezelfde bestemming en dezelfde opdrachten. Die vergelijking scheidt een huidige tunnelinterface van een oude verborgen adapter die door een de-installatie is achtergelaten, en van een tweede client die ook draait. Ze vertelt u ook of de tunnelinterface netjes verdwijnt, want een adapter die na het verbreken blijft bestaan is een ander probleem dan een die nooit verscheen. Zonder de drie momentopnamen lijkt elke onbekende alias de schuldige.

Bewaar de drie uitvoer bij het ticket, want twee opdrachtuitvoer verslaan een alinea beschrijving. Een collega kan ze vergelijken zonder uw sessie überhaupt te herhalen.

Verwijder niet wat u niet hebt geïdentificeerd

Onbekende adapters horen meestal bij iets: een beheerde client, een virtuele switch, een containernetwerk of een beveiligingsagent. Een verwijderen kan een werkend onderdeel weghalen en het oorspronkelijke symptoom precies laten waar het was. Als de route verouderd is, zoek de eigenaar van de route en herstel die daar; als het profiel onjuist is, bewerk het profiel. De documentatie van Get-NetIPInterface somt de hierboven gebruikte velden op, inclusief de metriek- en statuskolommen die de vergelijking zinvol maken.

Noem het object, vind de eigenaar en handel dan op die eigenaar. Al het andere is het probleem hernoemen in plaats van het te lezen.