Brandväggsprofiler kontra VPN-utgång: varför offentlig inte är en väg
En brandväggsprofil väljer vilken regeluppsättning som gäller. Den säger ingenting om vilket gränssnitt som bar paketet, och en explicit blockering slår ett snävare tillstånd.
Regeln låter exakt: tillåt lokal trafik på den privata profilen och bara VPN-trafik på den offentliga. Det är den inte, för en nätverksprofil väljer vilken brandväggsregeluppsättning som gäller och säger ingenting om vilken adapter som bar ett paket. Att behandla profilnamnet som ett krav på vägen är felet som får en design med begränsad utgång att se färdig ut när den inte är det.
Skriv först ned flödena och bestäm sedan vilken mekanism som faktiskt kan genomdriva vart och ett av dem. Den flödeslistan är det enda artefakt som överlever nästa regeländring.
Kategorin väljer regler, inte rutter
När Windows klassificerar ett nätverk som offentligt eller privat tillämpar brandväggen den regeluppsättning som är konfigurerad för den profilen. Klassificeringen följer nätverket som adaptern anslöt till, och regeluppsättningen avgör vad som tillåts på det. Ingen av dessa fakta beror på om ett programs trafik använde tunneln. Just detta oberoende är hela svårigheten.
Vägvalet görs av routning, via gränssnittsmetriken och det prefix som tunneln installerar. En profil kan därför vara märkt offentlig medan ett programs anslutning tar den fysiska vägen, och brandväggen rapporterar ändå att den offentliga regeluppsättningen tillämpades.
Därför kan en regel som är begränsad till profilen inte betyda bara tunnel. De två egenskaperna avgörs av olika komponenter och den ena kan inte ersätta den andra.
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
En explicit blockering går före ett snävare tillstånd
Microsofts vägledning för brandväggsregler skiljer på ett tillstånd som undantag från en standardblockeringsåtgärd och en explicit blockering som står i konflikt med ett tillstånd. Explicit blockeringar vinner den konflikten, och utgående regler följer samma prioritet.
Så det populära receptet att lägga till en regel som blockerar allt och lita på ett snävare tillstånd placerat ovanför gör inte vad dess författare förväntar sig. Windows-brandväggen löser inte konflikten efter den regelordning som administratören tilldelat. Blockeringen gäller helt enkelt, och programmet som ansluter rapporterar timeout. Regeln som såg ut som undantaget var aldrig med i spelet.
Den stödda formen är en standardavvisningspolicy med godkända tillståndsregler, där varje tillstånd namnger ett program, en tjänst eller en destination tillräckligt exakt för att kunna granskas. Den designen tål en revision, eftersom varje undantag är synligt och inget av dem beror på ordningen de skapades i.
Två regler som motsäger varandra är värre än en regel, eftersom beteendet som följer är korrekt och oförklarligt samtidigt.
Ge den utgående policyn en enda ägare
En stödd VPN-klient upprätthåller redan sitt eget blockeringsbeteende och sina egna undantag för slutpunkter. Att lägga till icke-samordnade manuella regler kan lämna den klienten utanför tunneln den behöver för installationen, eller lämna en andra väg öppen som ingen lade märke till.
Bestäm vem som äger den utgående policyn innan du skriver regler: klientens egen konfiguration, en hanterad brandväggspolicy eller en dokumenterad lokal undantagslista med en ägare. Avstäm sedan lagren i stället för att stapla experiment tills något ansluter. En namngiven ägare är också den man frågar när två lager är oense.
Bevara en återställningskanal innan du ändrar något. En fjärrmaskin utelåst från sin egen administrationsväg är ett värre utfall än det policymässiga gap du stängde. Återställningsregeln är lättare att motivera när den är nedskriven i förväg, och lättare att hitta när en ändring går fel vid en timme som ingen uppskattar.
Testa fyra utfall i stället för att läsa etiketten
En policy är bara så bra som de fall den skiljer på, så behandla profiletiketten som en utgångspunkt och inte ett resultat. Fyra utfall säger om den fungerar: den avsedda LAN-begäran lyckas, en täckt internetbegäran lyckas, en förbjuden direkt begäran misslyckas, och fallet med tunnelfel beter sig som designat i stället för att tyst falla tillbaka. Skriv ned de fyra resultaten bredvid regeländringen. En testplan med fyra namngivna fall är kort nog att köras varje gång och specifik nog att misslyckas högljutt.
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
Det första kommandot visar hur varje anslutet nätverk klassificeras, vilket ofta inte är vad personen som skrev regeln antog. Det andra visar standardåtgärden per profil, och det tredje listar aktiverade utgående blockeringar, inklusive dem som tyst kommer att åsidosätta ett snävare tillstånd.
Kör de fyra fallen igen efter en nätverksändring, eftersom en profil kan omklassificeras när maskinen ansluter till ett annat nätverk. En matchande profiletikt är inte bevis för att vägen var den du avsåg.