Kun Windows-firewallen som VPN-nødafbryder: holder det?

Spørg, om Windows-firewallen alene kan fungere som nødafbryder, og du får to sikre og uforenelige svar. Det ene siger, at reglen efter grænsefladetype gør hele arbejdet; det andet, at det ikke kan lade sig gøre uden scripting. Begge beskriver den halve del af samme mekanisme. Firewallen kan udtrykke blokeringen, og om resultatet faktisk fejler lukket, afhænger af tre ting: hvordan Windows klassificerer tunneladapteren, om undtagelsen for slutpunktet overlever, og om navneopløsning og IPv6 er dækket. Rammer du forkert på blot én af dem, lækker maskinen eller mister al forbindelse.

Tre betingelser, i denne rækkefølge

Den første betingelse er klassifikation, og den afgør, om den regel, du ønsker, overhovedet kan udtrykkes. Windows-firewallregler kan afgrænses efter grænsefladetype: kablet, trådløs eller fjernadgang. En politik, der blokerer udgående trafik på de fysiske typer og tillader tunnelen, virker kun, hvis Windows anerkender tunnelen som fjernadgang.

Den anden betingelse er undtagelsen for slutpunktet. Før der findes en tunnel, skal klienten nå VPN-serveren over den fysiske adapter, så en blanket blokering af den adapter forhindrer netop den forbindelse, som ville gøre blokeringen unødvendig. Undtagelsen skal navngive serveren og dens port, og pakken skal sendes ud gennem den fysiske gateway i stedet for ind i en tunnel, der endnu ikke er oppe.

Den tredje er dækning. Et regelsæt, der blokerer IPv4 og glemmer IPv6, eller som tillader den lokale resolver at slå slutpunktet op og dermed tillader enhver anden opslagning, fejler åbent præcis i det vindue, som nødafbryderen findes for at dække. Det er et hul i designet frem for en fejl i firewallen. Det er også det hul, der overlever hver eneste test på et skrivebord.

Klassifikationen er den første port

Se, hvad Windows mener om adapterne, før du skriver en eneste regel. En indbygget Windows VPN-forbindelse optræder normalt som fjernadgang. En tredjepartsklient, der opretter sin egen virtuelle adapter, optræder ofte som kablet, hvilket betyder, at en blokering afgrænset til kablede adaptere også blokerer tunnelen.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundAction

Den tredje kommando fortæller, om en standardblokering af udgående trafik allerede gælder, hvilket ændrer hele designets form. Hvis standarden allerede er blokering, skriver du tilladelsesregler frem for undtagelser til en eftergivende baseline, og det er en langt lettere holdning at ræsonnere om.

Hvis din tunneladapter rapporterer som kablet, er kun-firewall ikke det rigtige værktøj til et design med lukket fejl, og ingen mængde regeljustering ændrer det. Det er det tilfælde, hvor den anden mening i enhver forumtråd har ret.

Undtagelsen for slutpunktet kræver en rute såvel som en regel

Antag, at klassifikationen virker. Undtagelsen er to stykker, og de lever i forskellige delsystemer. Firewallreglen tillader trafikken; værtsruten får den til at forlade den rigtige grænseflade, mens tunnelen er nede.

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/32

Uden ruten hjælper undtagelsen kun, mens en standardrute stadig peger på den fysiske gateway. Når klienten installerer sin egen standardrute og derefter dør, har de tilladte pakker ingen fornuftig vej at gå, og forbindelsen kan ikke genoprettes. Den fejl ser ud som en ødelagt klient og er i virkeligheden en manglende rute.

Hold undtagelsen så smal, som klienten tillader. Én adresse og én port kan gennemgås; et område, der dækker udbyderens hele netværk, kan ikke. Den bredere regel tillader også alt andet, der hostes hos samme udbyder, og det er normalt mere, end du havde tænkt.

DNS og IPv6 er, hvor det fejler åbent

Navneopløsning er den klassiske lækage. Hvis slutpunktet er et værtsnavn, skal klienten opløse det, før tunnelen findes, hvilket betyder, at den fysiske adapter skal have lov at nå en resolver. Den samme tilladelse lukker enhver anden opslagning ud, mens tunnelen er nede, og én opslagning er nok til at afsløre, hvad du var på vej til at besøge.

IPv6 er den anden. Regler skrevet til IPv4 dækker ikke den anden familie, og mange klienter installerer kun IPv4-ruter. En maskine med indbygget IPv6-forbindelse kan derfor fortsætte med at tale med internettet, mens IPv4-siden er fast blokeret, og nødafbryderen rapporterer succes hele tiden.

Den tredje række er værd at forstå i stedet for at omgå. En firewall afgør om pakker, ikke om hvilken grænseflade et program bad om at bruge, og et program, der binder sig eksplicit, kan være svært at holde styr på. Det er et argument for en nødafbryder på klientsiden, der arbejder under programmet, ikke for flere regler.

Test ved at stoppe klienten, ikke ved at trække kablet

Den eneste meningsfulde test er den, der efterligner den fejl, du beskytter dig imod. Stop tjenesten, dræb processen, eller deaktiver den adapter, klienten oprettede, og prøv derefter at nå internettet og et navn:

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 443

Alle tre bør fejle. Hvis den første lykkes, er blokeringen ikke i kraft; hvis den anden lykkes, hvor den første fejlede, har du en DNS-lækage; hvis den tredje lykkes, er IPv6 ikke dækket. Hvert udfald peger på præcis et af hullerne ovenfor.

Gentag testen efter dvale og genoptagelse, fordi firewallprofilen kan ændre sig, når Windows beslutter, at et netværk er offentligt eller privat, og regler afgrænset til en profil følger den. Et design, der holder på et skrivebord og fejler i et tog, er et design, der er testet én gang.

Hvis klassifikationsporten eller DNS-kravet gør kun-firewall-tilgangen ubrugelig, er en nødafbryder på klientsiden det ærlige svar. Hvis tunnelen i stedet ender på en router, bør routeren eje politikken, fordi én regel der dækker hver enhed bag den og afhænger ikke af, hvordan Windows mærker en adapter.