Waarom Get-VpnConnection sommige Windows VPN-profielen mist

Typ Get-VpnConnection, krijg niets terug, en het onderzoek stopt meestal daar. Die lege uitvoer wordt gelezen als bewijs dat de machine helemaal geen VPN heeft, zelfs terwijl een tunnel verkeer draagt. De opdracht is in orde; de aanname over wat hij inventariseert niet. Hij leest één native opslag in één bereik, en hij weet niets van clients die hun eigen profielen bijhouden.

Eén native opslag per aanroep

Begin met de kale aanroep, die zich richt op de profielen van het aangemelde account. Dit is de aanroep die de meeste mensen als eerste uitvoeren:

Get-VpnConnection

Elk teruggegeven object draagt Name, ServerAddress, TunnelType en ConnectionStatus, en die vier velden zijn genoeg om twee vermeldingen in een ticket te onderscheiden. Een profiel kan maanden losgekoppeld staan en toch in de lijst blijven, omdat het object opgeslagen configuratie beschrijft en geen live verkeer. Een leeg resultaat betekent hier dat de opslag per gebruiker niets voor dat account had. Dat is een veel kleinere bewering dan die mensen er gewoonlijk in lezen.

Het telefoonboek voor alle gebruikers heeft een eigen query nodig

Profielen die elk account bedienen, staan in een aparte lijst, en de standaardaanroep leest die nooit. Je vraagt die opslag expliciet op:

Get-VpnConnection -AllUserConnection

Als de sessie de rechten mist, verwacht dan een toegang-geweigerd-fout in plaats van een leeg resultaat, en behandel de twee uitkomsten verschillend: de ene betekent dat je niet mag kijken, de andere dat er niets is opgeslagen. Noteer het bereik naast elke naam terwijl de uitvoer voor je ligt, want een latere opdracht herinnert je er niet aan welke opslag hij heeft bevraagd. Machtigingen zijn de gebruikelijke reden dat een collega een profiel ziet dat jij niet kunt. De parametersets zijn gedocumenteerd op de referentepagina van Get-VpnConnection, inclusief welke schakelaars bij welke set horen.

Dezelfde naam, twee verschillende opslagen

Een profielnaam is uniek binnen zijn opslag, niet op de hele machine, dus de lijsten per gebruiker en voor alle gebruikers kunnen elk een profiel met de naam Office bevatten. De twee vermeldingen kunnen naar verschillende servers wijzen, verschillende tunneltypen gebruiken en verschillende inloggegevens dragen. Slechts één ervan is de vermelding waarop de gebruiker dubbelklikt. Noteer het bereik voordat je een van beide aanraakt.

De kopie verwijderen die niemand start, lijkt onschuldig in een wijzigingsvenster. Het wordt een supportgesprek wanneer de snelkoppeling van de gebruiker stopt met werken.

Clients die de native lijst nooit aanraken

Een OpenVPN- of WireGuard-profiel dat in een leveranciersclient is geïmporteerd, leeft in de eigen configuratie van die client, dus het wordt nooit een native Windows-vermelding. De client draait zijn eigen service, houdt zijn eigen lijst bij en leidt verkeer via zijn eigen adapter. Niets daarvan is wat de opdracht meldt, en geen bereikschakelaar laat het verschijnen. Een machine kan drie werkende tunnels en een lege native lijst hebben.

Wanneer je in plaats daarvan de adapterweergave nodig hebt, vraag de adapters op. Leveranciersinterfaces noemen zichzelf, dus match een fragment en geen exacte tekenreeks:

Get-NetAdapter | Where-Object InterfaceDescription -match 'WireGuard|OpenVPN|TAP'

Native profielen die met de hand zijn gemaakt, belanden in het telefoonboekbestand onder het gebruikersprofiel, en de equivalenten voor alle gebruikers staan in de kopie voor de hele machine. Daarom reproduceert het kopiëren van de profielopslag van één gebruiker naar een ander account zelden dezelfde lijst. Het bestand verklaart waar een verdwaalde native verbinding vandaan kwam. Over de opslag van een leveranciersclient zegt het niets.

Wat je moet vastleggen voordat je een profiel verwijdert

De goedkope verzekering is een notitie met vijf velden: naam, bereik, serveradres, status en de exacte fouttekst uit de poging van de gebruiker. Voeg de client toe die ze echt starten, want dat detail bepaalt of de native vermelding er überhaupt toe doet. Zonder dat lijkt een correcte verwijdering nog steeds de oorzaak van de volgende fout. Bewaar de notitie in het ticket en niet in een chatvenster.

Verwijderen is één opdracht, en hij verwijdert configuratie in plaats van die uit te schakelen. Voer hem pas uit als die notitie bestaat:

Remove-VpnConnection -Name "Office" -Force

Voeg -AllUserConnection toe wanneer het doel in de opslag voor alle gebruikers staat, en bewaar de goedgekeurde configuratiebron eerst elders. Verbind daarna één keer opnieuw en lees de routetabel, want een lijst bewijst alleen dat de configuratie is opgeslagen. Of het verkeer de server bereikt, is een aparte vraag die geen enkele hoeveelheid Get-VpnConnection-uitvoer beantwoordt. Als de gebruiker na een schone hernieuwde toevoeging nog steeds faalt, was het profiel nooit het probleem.