Varför Always On VPN slutar utlösas på kontorets nätverk

Den bärbara datorn ansluter till kontorets Wi-Fi, och Always On-profilen som anslöt hemifrån ligger kvar nere. Inget i händelseloggen kallar det ett fel, eftersom nätverket ur klientens synvinkel är betrott och tunneln är onödig. Identifiering av betrodda nätverk är funktionen som fattar det beslutet, och den jämför specifika värden i stället för att känna igen ett bekant SSID. När beslutet är fel måste du se vilken jämförelse som gick igenom.

Vad utlösaren faktiskt jämför

Tre saker måste stämma innan klienten behandlar ett nätverk som betrott. För det första måste det anslutningsspecifika DNS-suffix som Windows registrerar för den fysiska adaptern finnas i suffixlistan i profilen. För det andra måste den anslutningsprofil som Windows har för nätverket vara den som principen förväntar sig, eftersom matchningen sker mot den profilen och inte mot ett namn som en användare skrev i en trådlös dialog. För det tredje måste nätverket klassas så som principen kräver, vilket i praktiken betyder ett domän- eller privatnätverk, eller en enhet vars princip kom via hantering. Ta bort någon av dem och utlösaren slår till.

Det är ett snävare test än att jämföra VPN:ens offentliga utgångsadress, och mycket snävare än att lita på ett SSID. En åtkomstpunkt som upprepar företagsnamnet uppfyller inte suffix- och profilsjämförelserna på egen hand. Det betyder också att funktionen inte säger något om huruvida ett nätverk är säkert; den säger om den här enheten tror att den redan är hemma.

Läs aktuellt tillstånd innan du ändrar profilen

Börja med vad Windows tror just nu. Cmdleten för anslutningsprofil rapporterar nätverksnamnet, gränssnittet och den kategori Windows tilldelade, vilket är den tredje jämförelsen ovan. Läs sedan VPN-profilen och leta efter listan över betrodda suffix, med en full egenskapsutskrift i stället för att gissa egenskapsnamnen:

Get-NetConnectionProfile
Get-VpnConnection -Name "Corp VPN" | Format-List *

Om den utskriften inte visar det betrodda suffixet på din version, fall tillbaka på profilens XML, som är den auktoritativa kopian när egenskapsytan skiljer sig mellan versioner. Läs XML:en från hanteringsprincipen eller från profillagret för alla användare, och jämför dess suffixposter med det adapter-suffix som rapporterades ovan. Anteckna båda värdena innan du rör något av dem.

Testa gränsen i båda riktningarna

Testa på den avsedda företagsanslutningen och på ett annat godkänt nätverk, och skriv ned om tunneln kom upp. Testa sedan samma enhet efter att du lämnat nätverket. En bärbar dator som utlöses hemma och undertrycks på kontoret beter sig som designat, medan en som aldrig utlöses någonstans har ett annat fel. Kontrollera att resurserna bakom tunneln är nåbara när den utlöses, eftersom en startad tunnel inte är bevis på en fungerande väg.

Lägg inte till ett brett suffix bara för att en avisering ska försvinna. Ett suffix som förekommer på många nätverk lär klienten att undertrycka tunneln nästan överallt, och supportbelastningen som följer är värre än aviseringen. Ändra kriterierna via profilägaren, som i en hanterad flotta är MDM-administratören och inte personen vid datorn.

Behåll båda testnätverken i protokollet tillsammans med resultatet. En gräns som aldrig testats är bara ett påstående.

Skilj undertryckning från blockering

En tunnel som inte startades är inte en blockerad anslutning. Identifiering av betrodda nätverk styr den automatiska utlösningen, medan trafikfiltrering och kill-switch-beteende är separata principinställningar med egna fellägen. En enhet på ett betrott nätverk får skicka trafik utanför tunneln legitimt, och att kalla det en läcka utan att läsa principen blandar ihop två konstruktioner. Kontrollera profilens trafikregler innan du skyller identifieringen för en läcka.

Samma åtskillnad förklarar det omvända klagomålet. Användare som rapporterar att VPN:en stannade slumpmässigt beskriver oftast en nätverksändring som uppfyllde kriterierna, inte ett tjänstefel. Det matchande suffixet och nätverkskategorin är bevisen som ska samlas in, och båda syns i utdata ovan.

Samla in dessa bevis innan du ändrar principen. En växel som döljer symtomet döljer också orsaken.

Anteckna vad beslutet byggde på

Skriv det matchande suffixet, namnet på anslutningsprofilen och nätverkskategorin i distributionsanteckningarna för varje plats. När tunneln inte kommer upp förvandlar den anteckningen ett mysterium till en jämförelse: antingen har ett av de tre värdena ändrats, eller principen. Det ger också nästa ingenjör ett sätt att bekräfta designen i stället för att inaktivera identifieringen för att stänga ärendet.

Gå igenom suffixlistan när en plats byter namn eller en domän konsolideras, eftersom en inaktuell post fortsätter att undertrycka tunneln i tysthet. Microsofts referens för identifiering av betrodda nätverk listar profilelementen och förutsättningarna för distribution, och det är dokumentet som citeras när någon föreslår att listan ska vidgas.