Waarom je VPN-adapter op het openbare firewallprofiel blijft

De tunnel is actief, het account is geauthenticeerd tegen het domein, en Windows labelt de verbinding nog steeds als openbaar. Een firewallregel die voor het domeinprofiel is geschreven, geldt dus niet, en de bestandsshare blijft onbereikbaar. De gebruikelijke reparatiepoging is de adapter op privé zetten, wat verandert welke regels gelden zonder iets aan de authenticatie te veranderen. Zowel het label als de reparatie worden breed verkeerd begrepen, en ze scheiden kost drie opdrachten.

Het account dat inbelde is niet de categorie van het netwerk

Tijdens een VPN-verbinding worden twee verschillende beslissingen genomen en die zijn makkelijk te verwarren. De gateway beslist of het account mag verbinden. Windows beslist hoe het resulterende netwerk wordt geclassificeerd, en die classificatie bepaalt welke firewallregels op de interface van toepassing zijn.

Een geslaagde domeinauthenticatie bij de gateway is bewijs over het account. Het is geen bewijs dat het eindpunt het netwerk tegen een domeincontroller heeft geauthenticeerd, en dat is precies wat de domeincategorie voorstelt.

Daarom kan een machine aan een domein zijn gekoppeld, met een domeinaccount verbinden en toch openbaar tonen. De classificatie is een lokale vaststelling over het netwerk, geen uitspraak over de inloggegevens die de tunnel hebben geopend. Het account kan volledig geldig zijn terwijl het label blijft waar het begon.

Drie categorieën, waarvan je er één niet kunt instellen

Windows biedt drie categorieën en alleen twee daarvan kunnen door een beheerder worden toegewezen. De derde wordt bepaald door het besturingssysteem nadat het het netwerk met succes tegen een domeincontroller heeft geauthenticeerd.

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

De derde opdracht mislukt, en dat is het gedocumenteerde gedrag en geen machtigingsprobleem. De referentie van de opdracht zelf vermeldt dat de domeincategorie niet op deze manier kan worden toegewezen, omdat Windows die afleidt uit domeinauthenticatie. De fout zien is een nuttige bevestiging dat de categorie een gevolg is en geen instelling.

Lees de eerste opdracht op het eindpunt waarvan het verkeer wordt geblokkeerd. De classificatie van de eigen interface van een gateway zegt niets over hoe elke verbindende werkstation zijn tunnel classificeerde.

Regels volgen het profiel waarvoor ze zijn geschreven

Zodra je de categorie kent, verklaart de ontbrekende toegang zich meestal vanzelf. Elke Windows Firewall-regel heeft een profielbereik, en een regel die tot domein is beperkt, geldt niet wanneer de interface openbaar is. Drie opdrachten maken daar een antwoord van in plaats van een theorie, en de derde vangt het geval waarin het profiel nooit het probleem was:

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

De tweede opdracht is degene die een vaag rapport in een oplossing verandert. Als de regel is beperkt tot een bereik van externe adressen dat de VPN-pool niet omvat, helpt het wijzigen van het profiel ook niet.

Controleer ook de standaardactie voor inkomend verkeer. Op een machine waar inkomend verkeer standaard wordt geblokkeerd, levert een ontbrekende toestemmingsregel stilte op in plaats van een weigering. Vanaf de clientzijde ziet dat er identiek uit als een routeringsfout, en daarom beginnen zoveel van deze tickets met de verkeerde aanname.

Stel vast welke machine de regel afdwingt

Voordat je een categorie wijzigt, stel je vast waar de blokkade optreedt. De server die de share host, kan een eigen firewall hebben, en de regels daarvan gelden voor het verkeer dat uit de VPN-pool komt, ongeacht hoe de client zijn adapter heeft gelabeld. Een weigering daar is onzichtbaar voor elke lokale opdracht die je uitvoert, en de clientzijde meldt alleen dat de bron niet beschikbaar is. Test de eigen regels van de bestemming voordat je de classificatie van de client aanraakt.

Test vanaf de client naar de specifieke poort en vergelijk daarna met een test vanaf een andere host op dezelfde VPN. Als beide mislukken, ligt het probleem bij de bestemming of op het pad. Als er maar één mislukt, is het verschil lokaal voor die machine, en wordt de profielcategorie een plausibele oorzaak.

Houd ook de richting in gedachten. Een regel die inkomende SMB toestaat, doet niets voor een client waarvan de eigen uitgaande regel hetzelfde verkeer blokkeert. Vanuit een venster van Verkenner zijn de twee storingen niet te onderscheiden, dus test elke richting apart voordat je iets bewerkt.

Wat je moet doen in plaats van alles opnieuw te labelen

Een onbekend netwerk privé maken om een brede regel te bevredigen is een echte wijziging met echte gevolgen. Het privéprofiel staat doorgaans meer detectie en meer inkomend verkeer toe dan het openbare.

Als het doel is een specifieke dienst de VPN-clients te laten bereiken, beperk de regel dan op extern adres in plaats van op profiel. Dat drukt de bedoeling precies uit, werkt ongeacht de classificatie en is er niet van afhankelijk dat Windows een virtuele adapter correct raadt. Het overleeft ook een clientupdate die de interface opnieuw classificeert. Schrijf de pool in de regel en de volgende persoon kan de bedoeling lezen zonder te vragen.

Als de domeincategorie echt wordt verwacht en nooit verschijnt, is dat een apart onderzoek. Controleer of de machine aan een domein is gekoppeld, of hij via de tunnel een domeincontroller kan bereiken en of het beveiligde kanaal gezond is. Deze drie opdrachten beantwoorden dat zonder één registerwijziging:

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

Deze drie beantwoorden of het eindpunt het netwerk überhaupt had kunnen authenticeren. Als het geen controller kan bereiken, wordt de domeincategorie nooit toegewezen, hoe vaak de adapter ook wordt gereset. De firewallregel die je najoeg, was nooit het echte probleem, en het label was een symptoom van een gebroken pad, geen oorzaak.