Varför en brandväggsport knuten till VPN-status inte är en regel för ping bara genom tunneln

Föreställ dig en brandväggsregel som slår på ICMP echo för serverns offentliga adress varje gång en namngiven VPN-profil är ansluten. Det läses som ”ping bara genom tunneln”, och den läsningen är fel på ett sätt som spelar roll. Regeln begränsar inte vem som kan nå värden; den ändrar vad det offentliga gränssnittet svarar på medan en annan anslutning råkar vara uppe. Det är två olika policyer, och en av dem vidgar exponeringen i tysthet.

Regeln du tror att du skrev

Det avsedda kravet är oftast smalt: övervakningssystemet, eller den ende administratören på VPN:et, ska kunna bekräfta att servern lever. Skrivet som en mening låter det som åtkomstkontroll på tunneln. Skrivet som ett brandväggsobjekt blir det ett villkor på den offentliga profilen, eftersom det är dit echo-begäran kommer.

När villkoret är ett anslutningstillstånd i stället för en källadress är mängden tillåtna avsändare inte längre VPN-peer-mängden. Alla som kan nå den offentliga adressen kan skicka en echo-begäran medan porten är öppen. Tunneln blev inte vägen; tunneln blev strömbrytaren.

De som marknadsför idén ljuger oftast inte om effekten de ville ha. De behövde en kontroll som bara svarar när länken är frisk, och länkens hälsa var lättast att observera genom VPN:et. Felet är att behandla en tillgänglighetssignal som ett åtkomstbeslut och sedan automatisera det.

Vad porten faktiskt styr

Den här designen smälter samman två oberoende saker, och att skilja dem är det mesta av rättelsen. Det första är omfång: vilken lokal adress, vilka fjärradresser, vilket protokoll och vilken ICMP-typ. Det andra är villkor: om regelobjektet är aktiverat i detta ögonblick. Omfång är det en brandvägg utvärderar per paket; villkor är det ett skript skriver i policylagret, och de två stäms av på helt olika klockor.

Om kravet verkligen bara är VPN-peers svarar omfånget på det utan någon logik för anslutningstillstånd: bind regeln till tunnelns gränssnitt eller till tunnelns adressområde, begränsa fjärradresserna till klientpoolen och ange echo-typen i stället för ”ICMP”. Den regeln förblir korrekt när inget VPN är uppe och kan inte öppnas av en orelaterad profil.

Om kravet verkligen är en offentlig port, säg det i policytexten, eftersom acceptanskriterierna ändras. En offentlig port måste namnge den exakta profilen, definiera vad ”ansluten” betyder och deklarera att offentliga avsändare är inom omfånget enligt design. Det mesta av förvirringen försvinner i samma ögonblick som någon tvingas skriva ner den meningen.

Bygg objektet en gång och växla det sedan

Förbered i förväg en enda regel med en stabil identitet, inaktiverad, och låt kontrollern ändra bara dess aktiverade tillstånd. Att skapa regler efter visningsnamn vid varje körning är hur ett policylager slutar med fem nästan identiska objekt och ingen tillförlitlig metod att ta bort dem.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

Namnet är den varaktiga identifieraren; visningsnamnet är dokumentation som en människa får redigera. Stäm av mot -Name och skriptet slutar producera dubbletter. Samma kommandoform täcker IPv6-fallet med -Protocol ICMPv6 -IcmpType 128, men det är en separat regel eftersom echo-typens nummer skiljer sig mellan de två familjerna.

Håll adressfamilj och ICMP-typ explicita av en andra anledning: -Protocol ICMPv4 utan typ tillåter varje ICMPv4-meddelande som profilen tillåter, inklusive dem du aldrig tänkt acceptera. Att namnge typ 8 snävar in regeln till echo-begäran, och det är det enda en tillgänglighetskontroll skickar.

Där automatiseringen motsäger avsikten

Att polla en klientprofil var par minut kan inte ge en omedelbar gräns. Mellan att anslutningen faller och nästa poll svarar regeln fortfarande på den offentliga adressen; mellan att anslutningen kommer upp och nästa poll gör den det inte. Att erkänna den fördröjningen är ärligt, och att hävda att designen upprätthåller en strikt invariant är det inte.

Det finns en omfångsfälla i själva tillståndskontrollen. Get-VpnConnection rapporterar klientprofiler som konfigurerats på maskinen, som standard för den aktuella användaren och för alla användare med -AllUserConnection. Den rapporterar inte fjärranvändarna som just nu är inringda till en RRAS-server; det är en annan observation med ett annat kommando. En port byggd på den felaktiga är inte ansluten till något.

Täck sedan tillstånden som ingen skriptar: uppstart med regeln redan aktiverad från en tidigare körning, kontrollerkrasch medan porten är öppen och en profil som raderas medan dess regel lever kvar. Var och en behöver ett definierat standardvärde, och det säkra standardvärdet för ett offentligt tillstånd är inaktiverat. Om kravet verkligen inte tål pollfönstret är en tillståndsstyrd regel fel verktyg och genomdrivandet hör till tunneln, inte till det offentliga gränssnittet.

Testa slutligen den offentliga begäran två gånger, en gång med den valda anslutningen uppe och en gång med den nere, från en värd som inte är på VPN:et. En lyckad ping inifrån tunneln bevisar ingenting om denna policy, och det är den mätning som de flesta utrullningar hoppar över.