VPN-clients geblokkeerd door het openbare Windows-firewallprofiel

Uw tunnel staat, de gateway antwoordt op ping en de bestandsshare loopt nog steeds in een time-out. Die combinatie is zelden een routeringsprobleem: Windows heeft het subnet van de VPN-adapter in het profiel Openbaar gezet, en elke toelatingsregel die voor Privé of Domein is geschreven, is nooit toegepast. Ik ben dit tegengekomen op laptops die het kantoor prima bereiken en op RRAS-servers die elke andere client bedienen, en de reparatie is kort zodra u het profiel in kwestie benoemt. Hier is de volgorde waarin ik werk, met de controle die u vertelt wanneer u vóór de volgende stap moet stoppen.

Bepaal op welk profiel het verkeer werkelijk binnenkomt

De Windows-firewall heeft geen enkele globale modus. Elke verbonden interface draagt een categorie, en inkomende pakketten worden gefilterd tegen de categorie van de interface waarop ze binnenkomen, dus het profiel van de VPN-adapter bepaalt wat een client in de tunnel kan bereiken, niet de Wi-Fi- of Ethernet-adapter ernaast. Lees beide feiten voordat u iets wijzigt:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

Bij een standaardinstallatie van OpenVPN of WireGuard verschijnt de VPN-adapter als een niet-geïdentificeerd netwerk en belandt in Openbaar, de standaard voor elk netwerk dat Windows niet kan classificeren: er antwoordde geen domeincontroller erover en er kwam geen gatewayprofiel overeen. De naam van de interface is hier irrelevant, dus de adapter “VPN” of “Corp” noemen verandert niets. DomainAuthenticated vereist een computer die aan het domein is gekoppeld , die via die interface daadwerkelijk een domeincontroller kan bereiken; een split tunnel die één subnet vervoert, voldoet daar niet aan.

Als de regel die u nodig hebt al tot de VPN-pool is beperkt en al geldt voor de categorie die u zojuist hebt gelezen, stop dan hier: filtering is niet uw laag, en de volgende plek om te kijken is de serviceconfiguratie. Die controle kost tien seconden en bespaart een uur regels bewerken. De categorienamen en wat elke categorie dekt, staan in de referentie voor Get-NetConnectionProfile.

Bevestig filtering, niet routering, voordat u regels bewerkt

Ping is een zwakke test. ICMP kan doorkomen terwijl de servicepoort wordt weggegooid, en een host kan vanaf de LAN antwoorden terwijl hij hetzelfde verzoek via de tunnel weigert. Test de poort die de client nodig heeft, vanaf de client:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Als de poorttest mislukt, scheid dan de twee lagen. Een tunnel- of routefout uit zich meestal als helemaal geen antwoord van het gatewayadres, terwijl een firewall-drop een gateway laat zien die antwoordt en een servicepoort die dat niet doet. Voer op een Windows-server die de pool via RRAS publiceert dezelfde test uit vanaf een client en lees het eigen profiel van de server: de RAS-interface kan in een categorie zitten waarvan de inkomende regels het clientbereik nooit noemen, en daarom bedient de machine zijn LAN en weigert hij elke client in de tunnel.

Als het resultaat nog steeds dubbelzinnig is, log dan de drops voor het profiel in kwestie en lees ze:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

Vermeldingen die het clientadres en de poort met DROP noemen, zijn beslissend, en ze vertellen u ook welke regel ontbrak. Een log zonder iets erin terwijl de SYN van de client nooit verschijnt, wijst stroomopwaarts van de host, dus ga terug naar de tunnel, de NAT-regel of de poolroute voordat u een ander firewallobject aanraakt.

Beperk één inkomende regel tot de clientpool

De reparatie is één inkomende toelatingsregel waarvan het externe adres de pool is, niet de hele wereld. Vanuit een verhoogde sessie:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

Als de service één binair bestand is, geef dan de voorkeur aan een programmagerichte regel met -Program in plaats van een poortenlijst; dat beperkt de uitzondering zowel tot het proces als tot het bronbereik.

De profielkeuze is waar dezelfde fout in de andere richting wordt gemaakt. -Profile Public is genoeg wanneer de adapter Openbaar is en Openbaar blijft. -Profile Any is verdedigbaar wanneer de service moet werken ongeacht hoe Windows de adapter classificeert, maar alleen zolang het externe bereik blijft. Wat nooit verdedigbaar is, is -RemoteAddress Any op het profiel Openbaar: die regel volgt de laptop naar elk café- en hotelnetwerk waar hij lid van wordt en opent de poort voor iedereen die dat subnet deelt.

Leg de pool naast de regel vast. -RemoteAddress 10.8.0.0/24 stopt stilzwijgend met overeenkomen op de dag dat de VPN-pool wordt hernummerd, en de fout ziet er precies zo uit als de oorspronkelijke bug, waardoor er een tweede middag aan verloren gaat. Noem regels naar de service en het bronbereik, houd ze samen met -Group, en lees ze opnieuw wanneer de pooldefinitie verandert. Een regelinventaris die u op één scherm kunt auditen, verslaat een correcte regel die niemand kan vinden.

Wijzig de categorie alleen wanneer de categorie de beslissing is

De interface op Privé zetten werkt ook, en het is de verkeerde standaard. Het profiel Privé bevat een lange lijst ingebouwde toelatingsregels, die bestands- en printerdeling, netwerkdetectie, extern bureaublad en afhankelijk van de baseline meer omvatten, dus het herclassificeren van de VPN-adapter schakelt ze allemaal tegelijk in voor elke client in de tunnel. Eén beperkte regel verleent één service aan één bereik. Op een laptop die ook niet-vertrouwde netwerken bezoekt, is dat verschil niet cosmetisch.

Er zijn gevallen waarin de classificatie echt verkeerd is: een altijd actieve of site-to-site-tunnel die een kantoorsubnet vervoert, is vertrouwde infrastructuur, en die adapter Privé markeren is een legitieme ontwerpkeuze, één keer per beleid gemaakt en niet per ticket. Wanneer u dat doet, doe het dan expliciet:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

Controleer op een beheerd apparaat eerst of Groepsbeleid of een MDM-baseline de instelling bezit. Als dat zo is, wordt de lokale wijziging bij de volgende vernieuwing ongedaan gemaakt en gpresult /h zal het beleid noemen dat haar bezit; herstel het daar, niet op het eindpunt.

Verifieer vanaf beide kanten en laat een spoor achter

Verifieer de stroom die de gebruiker meldde, vanaf de client, na de wijziging:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

Sluit daarna de lus voor de dingen die volgende week stukgaan. Herstart de host en test opnieuw, want een regel die op het verkeerde profiel is beperkt, blijft werken tot de adapter in een andere categorie terugkomt. Test vanaf een tweede client, want één client met een verouderde lease kan een poolafwijking verbergen. Tel de regels die u hebt toegevoegd tegen de regels die u hebt verwijderd, want overlappende uitzonderingen zijn de manier waarop een oplossing van twee regels een filterbeleid wordt dat niemand kan beoordelen.

Voordat u het als klaar beschouwt:

• Het profiel dat in de regel wordt genoemd, is het profiel op de interface waarop het verkeer binnenkomt.
• Het externe bereik is de VPN-pool, en die pool komt overeen met wat de server werkelijk uitgeeft.
• Geen regel die u hebt toegevoegd gebruikt -RemoteAddress Any op het profiel Openbaar.
• Er is niets uitgeschakeld om de test te laten slagen, en elke categoriewijziging legt vast wie haar heeft goedgekeurd.