Berre Windows-brannmuren som VPN-nødstopp: held det?

Spør om Windows-brannmuren åleine kan fungere som nødstopp, og du får to sjølvsikre og uforeinlege svar. Det eine seier at regelen etter grensesnitttype gjer heile jobben; det andre at det ikkje går utan skript. Begge skildrar halvparten av same mekanisme. Brannmuren kan uttrykke blokkeringa, og om resultatet faktisk feilar lukka, kjem an på tre ting: korleis Windows klassifiserer tunneladapteren, om unntaket for endepunktet overlever, og om namneoppslag og IPv6 er dekte. Bommar du på éin av dei, lek maskinen eller mistar all tilkopling.

Tre vilkår, i denne rekkjefølgja

Det første vilkåret er klassifisering, og det avgjer om regelen du vil ha i det heile kan uttrykkjast. Windows-brannmurreglar kan avgrensast etter grensesnitttype: kabel, trådlaust eller ekstern tilgang. Ein politikk som blokkerer utgåande trafikk på dei fysiske typane og tillèt tunnelen, verkar berre om Windows kjenner att tunnelen som ekstern tilgang.

Det andre vilkåret er unntaket for endepunktet. Før nokon tunnel finst, må klienten nå VPN-tenaren over den fysiske adapteren, så ein fullstendig blokkering av den adapteren hindrar nettopp den sambandet som ville gjere blokkeringa unødvendig. Unntaket må namngje tenaren og porten, og pakken må gå ut gjennom den fysiske porten i staden for inn i ein tunnel som enno ikkje er oppe.

Det tredje er dekning. Eit regelsett som blokkerer IPv4 og gløymer IPv6, eller som lèt den lokale oppløysaren slå opp endepunktet og dermed tillèt kvart anna oppslag, feilar ope nøyaktig i det vindauget nødstoppet finst for å dekkje. Det er eit hol i designet, ikkje ein feil i brannmuren. Det er også holet som overlever kvar test på ein skrivebord.

Klassifiseringa er den første porten

Sjå kva Windows meiner om adapterane før du skriv ein einaste regel. Ei innebygd Windows VPN-tilkopling viser seg normalt som ekstern tilgang. Ein tredjepartsklient som lagar sin eigen virtuelle adapter, viser seg ofte som kabel, noko som betyr at ei blokkering avgrensa til kabeladapterar 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 fortel om ei standardblokkering av utgåande trafikk alt gjeld, noko som endrar heile forma på designet. Om standarden alt er blokkering, skriv du tilletjingsreglar i staden for unntak frå ein ettergjevande base, og det er ein mykje lettare haldning å tenkje over.

Om tunneladapteren din rapporterer som kabel, er berre-brannmur ikkje rett verktøy for eit design med lukka feil, og inga mengd regeljustering endrar det. Det er tilfellet der den andre meininga i kvar forumtråd har rett.

Unntaket for endepunktet treng ei rute, ikkje berre ein regel

Gå ut frå at klassifiseringa verkar. Unntaket består av to delar, og dei lever i ulike delsystem. Brannmurregelen tillèt trafikken; vertsruta får han til å gå ut gjennom rett grensesnitt medan 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

Utan ruta hjelper unntaket berre så lenge ei standardrute enno peikar på den fysiske porten. Når klienten installerer si eiga standardrute og deretter døyr, har dei tillatne pakkane ingen fornuftig veg å gå, og sambandet kan ikkje gjenopprettast. Den feilen ser ut som ein øydelagd klient og er eigentleg ei manglande rute.

Hald unntaket så smalt som klienten tillèt. Éi adresse og ein port kan gjennomgåast; eit område som dekkjer heile nettet til leverandøren, kan ikkje. Den breiare regelen tillèt også alt anna som er hosta hos same leverandør, og det er vanlegvis meir enn du meinte.

DNS og IPv6 er der det feilar ope

Namneoppslag er den klassiske lekkasjen. Om endepunktet er eit vertsnamn, må klienten slå det opp før tunnelen finst, noko som betyr at den fysiske adapteren må få lov til å nå ein oppløysar. Den same løyva slepp kvart anna oppslag ut medan tunnelen er nede, og eitt oppslag er nok til å avsløre kva du var i ferd med å besøkje.

IPv6 er den andre. Reglar skrivne for IPv4 dekkjer ikkje den andre familien, og mange klientar installerer berre IPv4-ruter. Ein maskin med innebygd IPv6-tilkopling kan difor halde fram med å snakke med internett medan IPv4-sida er fast blokkert, og nødstoppet rapporterer suksess heile tida.

Den tredje rada er verdt å forstå i staden for å omgå. Ein brannmur avgjer om pakkar, ikkje om kva grensesnitt eit program bad om å bruke, og eit program som bind seg eksplisitt, kan vere vanskeleg å halde styr på. Det er eit argument for eit nødstopp på klientsida som verkar under programmet, ikkje for fleire reglar.

Test ved å stoppe klienten, ikkje ved å dra ut kabelen

Den einaste meiningsfulle testen er den som etterliknar feilen du vernar deg mot. Stopp tenesta, drep prosessen eller deaktiver adapteren klienten oppretta, og prøv deretter å nå internett og eit namn:

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. Om den første lukkast, er blokkeringa ikkje i kraft; om den andre lukkast der den første feila, har du ein DNS-lekkasje; om den tredje lukkast, er IPv6 ikkje dekt. Kvar utfald peikar på nøyaktig eitt av hola ovanfor.

Gjenta testen etter dvale og gjenopptaking, fordi brannmurprofilen kan endre seg når Windows avgjer at eit nettverk er offentleg eller privat, og reglar avgrensa til ein profil følgjer han. Eit design som held på ein skrivebord og feilar i eit tog, er eit design som er testa éin gong.

Om klassifiseringsporten eller DNS-kravet gjer berre-brannmur-tilnærminga ubrukeleg, er eit nødstopp på klientsida det ærlege svaret. Om tunnelen i staden endar på ein ruter, bør ruteren eige politikken, fordi éin regel der dekkjer kvar eining bak han og er ikkje avhengig av korleis Windows namngjev ein adapter.