Bare Windows-brannmuren som VPN-nødstopp: holder det?

Spør om Windows-brannmuren alene kan fungere som nødstopp, og du får to selvsikre og uforenlige svar. Det ene sier at regelen etter grensesnitttype gjør hele jobben; det andre at det ikke går uten skript. Begge beskriver halvparten av samme mekanisme. Brannmuren kan uttrykke blokkeringen, og om resultatet faktisk feiler lukket, avhenger av tre ting: hvordan Windows klassifiserer tunneladapteren, om unntaket for endepunktet overlever, og om navneoppslag og IPv6 er dekket. Bommer du på én av dem, lekker maskinen eller mister all tilkobling.

Tre betingelser, i denne rekkefølgen

Den første betingelsen er klassifisering, og den avgjør om regelen du vil ha i det hele tatt kan uttrykkes. Windows-brannmurregler kan begrenses etter grensesnitttype: kablet, trådløst eller ekstern tilgang. En policy som blokkerer utgående trafikk på de fysiske typene og tillater tunnelen, virker bare hvis Windows anerkjenner tunnelen som ekstern tilgang.

Den andre betingelsen er unntaket for endepunktet. Før noen tunnel finnes, må klienten nå VPN-serveren over den fysiske adapteren, så en blanket blokkering av den adapteren hindrer nettopp den forbindelsen som ville gjøre blokkeringen unødvendig. Unntaket må navngi serveren og porten, og pakken må gå ut gjennom den fysiske gatewayen i stedet for inn i en tunnel som ennå ikke er oppe.

Den tredje er dekning. Et regelsett som blokkerer IPv4 og glemmer IPv6, eller som lar den lokale resolveren slå opp endepunktet og dermed tillater ethvert annet oppslag, feiler åpent nøyaktig i det vinduet nødstoppet finnes for å dekke. Det er et hull i designet, ikke en feil i brannmuren. Det er også hullet som overlever hver test på et skrivebord.

Klassifiseringen er den første porten

Se hva Windows mener om adapterne før du skriver en eneste regel. En innebygd Windows VPN-forbindelse vises normalt som ekstern tilgang. En tredjepartsklient som lager sin egen virtuelle adapter, vises ofte som kablet, noe som betyr at en blokkering begrenset til kablede adaptere også blokkerer 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 kommandoen forteller om en standardblokkering av utgående trafikk allerede gjelder, noe som endrer hele formen på designet. Hvis standarden allerede er blokkering, skriver du tillatelsesregler i stedet for unntak fra en ettergivende base, og det er en langt lettere holdning å resonnere om.

Hvis tunneladapteren din rapporterer som kablet, er bare-brannmur ikke riktig verktøy for et design med lukket feil, og ingen mengde regeljustering endrer det. Det er tilfellet der den andre meningen i hver forumtråd har rett.

Unntaket for endepunktet trenger en rute, ikke bare en regel

Anta at klassifiseringen virker. Unntaket består av to deler, og de lever i forskjellige delsystemer. Brannmurregelen tillater trafikken; vertsruten får den til å forlate riktig grensesnitt 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

Uten ruten hjelper unntaket bare så lenge en standardrute fortsatt peker på den fysiske gatewayen. Når klienten installerer sin egen standardrute og deretter dør, har de tillatte pakkene ingen fornuftig vei å gå, og forbindelsen kan ikke gjenopprettes. Den feilen ser ut som en ødelagt klient og er egentlig en manglende rute.

Hold unntaket så smalt som klienten tillater. Én adresse og én port kan gjennomgås; et område som dekker hele leverandørens nettverk, kan ikke. Den bredere regelen tillater også alt annet som hostes hos samme leverandør, og det er vanligvis mer enn du mente.

DNS og IPv6 er der det feiler åpent

Navneoppslag er den klassiske lekkasjen. Hvis endepunktet er et vertsnavn, må klienten slå det opp før tunnelen finnes, noe som betyr at den fysiske adapteren må få lov til å nå en resolver. Den samme tillatelsen slipper ethvert annet oppslag ut mens tunnelen er nede, og ett oppslag er nok til å avsløre hva du var i ferd med å besøke.

IPv6 er den andre. Regler skrevet for IPv4 dekker ikke den andre familien, og mange klienter installerer bare IPv4-ruter. En maskin med innebygd IPv6-tilkobling kan derfor fortsette å snakke med internett mens IPv4-siden er fast blokkert, og nødstoppet rapporterer suksess hele tiden.

Den tredje raden er verdt å forstå i stedet for å omgå. En brannmur avgjør om pakker, ikke om hvilket grensesnitt et program ba om å bruke, og et program som binder seg eksplisitt, kan være vanskelig å holde styr på. Det er et argument for et nødstopp på klientsiden som virker under programmet, ikke for flere regler.

Test ved å stoppe klienten, ikke ved å trekke ut kabelen

Den eneste meningsfulle testen er den som etterligner feilen du beskytter deg mot. Stopp tjenesten, drep prosessen eller deaktiver adapteren klienten opprettet, og prøv deretter å nå internett 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 feile. Hvis den første lykkes, er blokkeringen ikke i kraft; hvis den andre lykkes der den første feilet, har du en DNS-lekkasje; hvis den tredje lykkes, er IPv6 ikke dekket. Hvert utfall peker på nøyaktig ett av hullene ovenfor.

Gjenta testen etter dvale og gjenopptakelse, fordi brannmurprofilen kan endre seg når Windows bestemmer at et nettverk er offentlig eller privat, og regler begrenset til en profil følger den. Et design som holder på et skrivebord og feiler i et tog, er et design som er testet én gang.

Hvis klassifiseringsporten eller DNS-kravet gjør bare-brannmur-tilnærmingen ubrukelig, er et nødstopp på klientsiden det ærlige svaret. Hvis tunnelen i stedet ender på en ruter, bør ruteren eie policyen, fordi én regel der dekker hver enhet bak den og avhenger ikke av hvordan Windows navngir en adapter.