Bara Windows-brandväggen som VPN-nödstopp: håller det?

Fråga om Windows-brandväggen ensam kan fungera som nödstopp och du får två självsäkra och oförenliga svar. Det ena säger att regeln efter gränssnittstyp gör hela jobbet; det andra att det inte går utan skript. Båda beskriver halva samma mekanism. Brandväggen kan uttrycka blockeringen, och om resultatet verkligen fallerar stängt beror på tre saker: hur Windows klassificerar tunneladaptern, om undantaget för slutpunkten överlever och om namnmatchning och IPv6 täcks. Bommar du på någon av dem läcker maskinen eller tappar all anslutning.

Tre villkor, i den här ordningen

Det första villkoret är klassificering, och det avgör om regeln du vill ha ens kan uttryckas. Windows-brandväggsregler kan begränsas efter gränssnittstyp: trådbundet, trådlöst eller fjärråtkomst. En policy som blockerar utgående trafik på de fysiska typerna och tillåter tunneln fungerar bara om Windows känner igen tunneln som fjärråtkomst.

Det andra villkoret är undantaget för slutpunkten. Innan någon tunnel finns måste klienten nå VPN-servern via den fysiska adaptern, så en heltäckande blockering av den adaptern hindrar just den anslutning som skulle göra blockeringen onödig. Undantaget måste namnge servern och dess port, och paketet måste gå ut genom den fysiska gatewayen i stället för in i en tunnel som ännu inte är uppe.

Det tredje är täckning. En regeluppsättning som blockerar IPv4 och glömmer IPv6, eller som låter den lokala matcharen slå upp slutpunkten och därmed tillåter varje annan uppslagning, fallerar öppet exakt i det fönster som nödstoppet finns för att täcka. Det är en designlucka, inte ett fel i brandväggen. Det är också luckan som överlever varje test på ett skrivbord.

Klassificeringen är den första porten

Titta på vad Windows tycker om adaptrarna innan du skriver en enda regel. En inbyggd Windows VPN-anslutning visas normalt som fjärråtkomst. En klient från tredje part som skapar sin egen virtuella adapter visas ofta som trådbunden, vilket betyder att en blockering begränsad till trådbundna adaptrar också blockerar tunneln.

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

Det tredje kommandot berättar om en standardblockering av utgående trafik redan gäller, vilket ändrar hela formen på designen. Om standarden redan är blockera skriver du tillåtelseregler i stället för undantag från en tillåtande bas, och det är en mycket lättare hållning att resonera kring.

Om din tunneladapter rapporterar sig som trådbunden är bara brandväggen inte rätt verktyg för en design med stängt fel, och ingen mängd regeljustering ändrar det. Det är fallet där den andra åsikten i varje forumtråd har rätt.

Undantaget för slutpunkten behöver en väg, inte bara en regel

Anta att klassificeringen fungerar. Undantaget består av två delar, och de lever i olika delsystem. Brandväggsregeln tillåter trafiken; värdvägen får den att lämna via rätt gränssnitt medan tunneln är nere.

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 vägen hjälper undantaget bara så länge en standardväg fortfarande pekar på den fysiska gatewayen. När klienten installerar sin egen standardväg och sedan dör har de tillåtna paketen ingen vettig väg att gå och anslutningen kan inte återupprättas. Det felet ser ut som en trasig klient och är egentligen en saknad väg.

Håll undantaget så smalt som klienten tillåter. En adress och en port går att granska; ett intervall som täcker hela leverantörens nätverk gör det inte. Den bredare regeln tillåter också allt annat som driftas hos samma leverantör, och det är vanligtvis mer än du tänkt dig.

DNS och IPv6 är där det fallerar öppet

Namnmatchning är den klassiska läckan. Om slutpunkten är ett värdnamn måste klienten matcha det innan tunneln finns, vilket betyder att den fysiska adaptern måste få nå en matchare. Samma tillstånd släpper ut varje annan uppslagning medan tunneln är nere, och en uppslagning räcker för att avslöja vad du var på väg att besöka.

IPv6 är den andra. Regler skrivna för IPv4 täcker inte den andra familjen, och många klienter installerar bara IPv4-vägar. En maskin med inbyggd IPv6-anslutning kan därför fortsätta prata med internet medan IPv4-sidan är fast blockerad, och nödstoppet rapporterar framgång hela tiden.

Den tredje raden är värd att förstå i stället för att kringgå. En brandvägg avgör om paket, inte om vilket gränssnitt ett program bad att få använda, och ett program som binder sig uttryckligen kan vara svårt att hålla i schack. Det är ett argument för ett nödstopp på klientsidan som arbetar under programmet, inte för fler regler.

Testa genom att stoppa klienten, inte genom att dra ur kabeln

Det enda meningsfulla testet är det som efterliknar felet du skyddar dig mot. Stoppa tjänsten, döda processen eller inaktivera adaptern som klienten skapade, och försök sedan nå internet och ett 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

Alla tre borde misslyckas. Om den första lyckas är blockeringen inte i kraft; om den andra lyckas där den första misslyckades har du en DNS-läcka; om den tredje lyckas täcks inte IPv6. Varje utfall pekar på exakt en av luckorna ovan.

Upprepa testet efter viloläge och uppvaknande, eftersom brandväggsprofilen kan ändras när Windows avgör att ett nätverk är offentligt eller privat, och regler begränsade till en profil följer den. En design som håller på ett skrivbord och fallerar i ett tåg är en design som testats en gång.

Om klassificeringsporten eller DNS-kravet gör bara-brandvägg-ansatsen oanvändbar är ett nödstopp på klientsidan det ärliga svaret. Om tunneln i stället slutar på en router bör routern äga policyn, eftersom en regel där täcker varje enhet bakom den och beror inte på hur Windows namnger en adapter.