Alleen de Windows-firewall als VPN-noodschakelaar: houdt dat?
Regels op basis van interfacetype kunnen de fysieke adapters blokkeren, maar een tunnel van derden ziet er vaak bedraad uit. Controleer de classificatie, de route naar het eindpunt en dan DNS.
Vraag of de Windows-firewall op zichzelf als noodschakelaar kan dienen en je krijgt twee zelfverzekerde en onverenigbare antwoorden. Het ene zegt dat de regel op basis van interfacetype het hele werk doet; het andere dat het zonder scripts niet kan. Beide beschrijven de helft van hetzelfde mechanisme. De firewall kan de blokkade uitdrukken, en of het resultaat werkelijk gesloten faalt, hangt van drie dingen af: hoe Windows de tunneladapter classificeert, of de uitzondering voor het eindpunt overleeft, en of naamresolutie en IPv6 gedekt zijn. Zit er één fout, dan lekt de machine of verliest zij alle verbinding.
Drie voorwaarden, in deze volgorde
De eerste voorwaarde is classificatie, en die bepaalt of de regel die je wilt überhaupt uitdrukbaar is. Windows-firewallregels kunnen op interfacetype worden beperkt: bedraad, draadloos of externe toegang. Een beleid dat uitgaand verkeer op de fysieke typen blokkeert en de tunnel toestaat, werkt alleen als Windows de tunnel als externe toegang herkent.
De tweede voorwaarde is de uitzondering voor het eindpunt. Voordat er een tunnel bestaat, moet de client de VPN-server via de fysieke adapter bereiken, dus een algehele blokkade op die adapter verhindert juist de verbinding die de blokkade overbodig zou maken. De uitzondering moet de server en zijn poort noemen, en het pakket moet via de fysieke gateway naar buiten gaan in plaats van een tunnel in die nog niet actief is.
De derde is dekking. Een regelset die IPv4 blokkeert en IPv6 vergeet, of die de lokale resolver het eindpunt laat opzoeken en daarmee elk ander opzoeken toestaat, faalt open precies in het venster waarvoor de noodschakelaar bestaat. Dat is een ontwerpgat, geen fout in de firewall. Het is ook het gat dat elke test op een bureau overleeft.
Classificatie is de eerste poort
Kijk wat Windows van de adapters vindt voordat je één regel schrijft. Een native Windows-VPN-verbinding verschijnt normaal als externe toegang. Een client van derden die zijn eigen virtuele adapter maakt, verschijnt vaak als bedraad, wat betekent dat een blokkade die tot bedrade adapters beperkt is, ook de tunnel blokkeert.
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundActionHet derde commando vertelt of een standaardblokkade van uitgaand verkeer al van kracht is, wat de hele vorm van het ontwerp verandert. Is de standaard al blokkeren, dan schrijf je toestemmingsregels in plaats van uitzonderingen op een toelatende basis, en dat is een veel gemakkelijker houding om over te redeneren.
Als je tunneladapter zich als bedraad meldt, is alleen de firewall niet het juiste gereedschap voor een ontwerp met gesloten falen, en geen enkele regelaanpassing verandert dat. Dit is het geval waarin de tweede mening in elke forumdraad gelijk heeft.
De uitzondering voor het eindpunt heeft een route nodig, niet alleen een regel
Stel dat de classificatie werkt. De uitzondering bestaat uit twee stukken, en ze leven in verschillende subsystemen. De firewallregel staat het verkeer toe; de hostroute zorgt dat het via de juiste interface naar buiten gaat terwijl de tunnel omlaag is.
New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
-Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32Zonder de route helpt de uitzondering alleen zolang een standaardroute nog naar de fysieke gateway wijst. Zodra de client zijn eigen standaardroute installeert en dan sterft, hebben de toegestane pakketten geen zinvolle plek om heen te gaan en kan de verbinding niet opnieuw worden opgezet. Die fout lijkt op een kapotte client en is in werkelijkheid een ontbrekende route.
Houd de uitzondering zo smal als de client toestaat. Eén adres en één poort zijn controleerbaar; een bereik dat het hele netwerk van de provider dekt niet. Die bredere regel staat ook al het andere toe dat bij dezelfde provider wordt gehost, en dat is meestal meer dan je bedoelde.
DNS en IPv6 zijn waar het open faalt
Naamresolutie is het klassieke lek. Als het eindpunt een hostnaam is, moet de client die oplossen voordat de tunnel bestaat, wat betekent dat de fysieke adapter een resolver mag bereiken. Diezelfde toestemming laat elk ander opzoeken naar buiten, terwijl de tunnel omlaag is, en één opzoeking is genoeg om te onthullen wat je op het punt stond te bezoeken.
IPv6 is de tweede. Regels die voor IPv4 zijn geschreven, dekken de andere familie niet, en veel clients installeren alleen IPv4-routes. Een machine met native IPv6-connectiviteit kan dus blijven praten met internet terwijl de IPv4-kant stevig is geblokkeerd, en de noodschakelaar meldt de hele tijd succes.
| Gap | What leaks | Control |
|---|---|---|
| Resolver permitted for endpoint lookup | Every name queried while down | Pin the endpoint as an address, or block non-tunnel DNS |
| Rules only for IPv4 | Full IPv6 connectivity | Add the same rules for the other family |
| Application bound to physical interface | Its own traffic | Firewall cannot fix this; change the binding |
De derde rij is het begrijpen waard in plaats van te omzeilen. Een firewall beslist over pakketten, niet over welke interface een toepassing vroeg te gebruiken, en een programma dat zich expliciet bindt, kan lastig in bedwang te houden zijn. Dat is een argument voor een noodschakelaar aan de clientzijde die onder de toepassing werkt, niet voor meer regels.
Test door de client te stoppen, niet door de kabel eruit te trekken
De enige zinvolle test is degene die de fout nabootst waartegen je je beschermt. Stop de dienst, dood het proces of schakel de adapter uit die de client heeft gemaakt, en probeer dan internet en een naam te bereiken:
Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443Alle drie zouden moeten mislukken. Als de eerste slaagt, is de blokkade niet van kracht; als de tweede slaagt waar de eerste faalde, heb je een DNS-lek; als de derde slaagt, is IPv6 niet gedekt. Elke uitkomst wijst precies op één van de gaten hierboven.
Herhaal de test na slaapstand en hervatten, omdat het firewallprofiel kan veranderen wanneer Windows besluit dat een netwerk openbaar of privé is, en regels die tot een profiel beperkt zijn, volgen dat. Een ontwerp dat op een bureau houdt en in een trein faalt, is een ontwerp dat één keer is getest.
Als de classificatiepoort of de DNS-eis de alleen-firewall-aanpak onbruikbaar maakt, is een noodschakelaar aan de clientzijde het eerlijke antwoord. Als de tunnel in plaats daarvan op een router eindigt, zou de router het beleid moeten bezitten, want één regel daar dekt elk apparaat erachter en hangt niet af van hoe Windows een adapter noemt.