Varför din VPN-adapter stannar kvar på den offentliga brandväggsprofilen

Tunneln är uppe, kontot är autentiserat mot domänen och Windows märker fortfarande anslutningen som offentlig. Därför gäller inte en brandväggsregel skriven för domänprofilen, och filutdelningen förblir oåtkomlig. Det vanliga reparationsförsöket är att ställa adaptern på privat, vilket ändrar vilka regler som gäller utan att ändra något i autentiseringen. Både etiketten och reparationen missförstås brett, och att skilja dem åt kräver tre kommandon.

Kontot som kopplade upp är inte nätverkets kategori

Under en VPN-anslutning fattas två olika beslut och de är lätta att blanda ihop. Gatewayen avgör om kontot får ansluta. Windows avgör hur det resulterande nätverket ska klassas, och den klassningen avgör vilka brandväggsregler som gäller för gränssnittet.

Lyckad domänautentisering vid gatewayen är bevis om kontot. Det är inte bevis för att slutpunkten har autentiserat nätverket mot en domänkontrollant, och det är precis vad domänkategorin representerar.

Därför kan en dator vara domänansluten, ansluta med ett domänkonto och ändå visa offentlig. Klassningen är ett lokalt avgörande om nätverket, inte ett påstående om de autentiseringsuppgifter som öppnade tunneln. Kontot kan vara helt giltigt medan etiketten blir kvar där den började.

Tre kategorier, varav du inte kan ange en

Windows erbjuder tre kategorier och bara två av dem kan tilldelas av en administratör. Den tredje bestäms av operativsystemet efter att det framgångsrikt har autentiserat nätverket mot en domänkontrollant.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

Det tredje kommandot misslyckas, och det är det dokumenterade beteendet och inte ett behörighetsproblem. Referensen för själva kommandot anger att domänkategorin inte kan tilldelas på detta sätt, eftersom Windows härleder den från domänautentisering. Att se felet är en användbar bekräftelse på att kategorin är en konsekvens och inte en inställning.

Läs det första kommandot på den slutpunkt vars trafik blockeras. Gatewayens egen gränssnittsklassning säger ingenting om hur varje anslutande arbetsstation klassade sin tunnel.

Regler följer den profil de skrevs för

När du känner till kategorin förklarar den saknade åtkomsten vanligtvis sig själv. Varje Windows-brandväggsregel har en profilomfattning, och en regel som är begränsad till domän gäller inte när gränssnittet är offentligt. Tre kommandon gör det till ett svar i stället för en teori, och det tredje fångar fallet där profilen aldrig var problemet:

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Det andra kommandot är det som förvandlar en vag rapport till en åtgärd. Om regeln är begränsad till ett intervall av fjärradresser som inte omfattar VPN-poolen hjälper det inte heller att byta profil.

Kontrollera också standardåtgärden för inkommande trafik. På en dator där inkommande trafik är blockerad som standard ger en saknad tillåtelseregel tystnad i stället för en avvisning. Från klientsidan ser det identiskt ut med ett routingfel, och därför börjar så många av dessa ärenden med det felaktiga antagandet.

Ta reda på vilken dator som tillämpar regeln

Innan du ändrar en kategori, fastställ var blockeringen sker. Servern som är värd för utdelningen kan ha en egen brandvägg, och dess regler gäller för trafiken som kommer från VPN-poolen oavsett hur klienten märkte sin adapter. En avvisning där är osynlig för varje lokalt kommando du kör, och klientsidan rapporterar bara att resursen inte är tillgänglig. Testa destinationens egna regler innan du rör klientens klassning.

Testa från klienten till den specifika porten och jämför sedan med ett test från en annan värd i samma VPN. Om båda misslyckas ligger problemet vid destinationen eller på vägen. Om bara en misslyckas är skillnaden lokal för den datorn, och profilkategorin blir en trolig orsak.

Tänk också på riktningen. En regel som tillåter inkommande SMB gör ingenting för en klient vars egen utgående regel blockerar samma trafik. Från ett filutforskarfönster går de två felen inte att skilja åt, så testa varje riktning separat innan du redigerar något.

Vad du bör göra i stället för att märka om allt

Att göra ett oidentifierat nätverk privat för att uppfylla en bred regel är en verklig ändring med verkliga konsekvenser. Den privata profilen tillåter vanligtvis mer upptäckt och mer inkommande trafik än den offentliga.

Om målet är att låta en specifik tjänst nå VPN-klienterna bör du begränsa regeln efter fjärradress i stället för efter profil. Det uttrycker avsikten exakt, fungerar oavsett klassning och är inte beroende av att Windows gissar rätt om en virtuell adapter. Den överlever också en klientuppdatering som omklassar gränssnittet. Skriv poolen i regeln och nästa person kan läsa avsikten utan att fråga.

Om domänkategorin verkligen förväntas och aldrig dyker upp är det en separat undersökning. Kontrollera att datorn är domänansluten, att den kan nå en domänkontrollant genom tunneln och att den säkra kanalen är frisk. Dessa tre kommandon svarar på det utan en enda registerändring:

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

Dessa tre svarar på om slutpunkten överhuvudtaget kunde ha autentiserat nätverket. Om den inte kan nå en kontrollant tilldelas domänkategorin aldrig, oavsett hur många gånger adaptern återställs. Brandväggsregeln du jagade var aldrig det egentliga problemet, och etiketten var ett symptom på en bruten väg, inte en orsak.