Waarom een firewall-poort op VPN-status geen ping-regel alleen via de tunnel is

Stel u een firewallregel voor die ICMP-echo aanzet voor het openbare adres van de server zodra een benoemd VPN-profiel verbonden is. Het leest als 'ping alleen via de tunnel', en die lezing is fout op een manier die ertoe doet. De regel beperkt niet wie de host kan bereiken; hij verandert wat de openbare interface antwoordt terwijl een andere verbinding toevallig actief is. Dat zijn twee verschillende beleidsregels, en een ervan vergroot de blootstelling stilletjes.

De regel die u denkt te hebben geschreven

De bedoelde eis is meestal smal: het monitoringsysteem, of de enige beheerder op de VPN, moet kunnen bevestigen dat de server leeft. Als zin geschreven klinkt het als toegangscontrole op de tunnel. Als firewallobject geschreven wordt het een voorwaarde op het openbare profiel, want daar komt het echo-verzoek aan.

Zodra de voorwaarde een verbindingsstatus is in plaats van een bronadres, is de verzameling toegestane afzenders niet langer de VPN-peer-verzameling. Iedereen die het openbare adres kan bereiken, kan een echo-verzoek sturen zolang de poort open staat. De tunnel werd niet de route; de tunnel werd de schakelaar.

De mensen achter dit idee liegen meestal niet over het effect dat ze wilden. Ze hadden een controle nodig die alleen antwoordt als de link gezond is, en de gezondheid van de link was het makkelijkst via de VPN te observeren. De fout is een beschikbaarheidssignaal als toegangsbeslissing te behandelen en dat vervolgens te automatiseren.

Wat de poort werkelijk bestuurt

Dit ontwerp smelt twee onafhankelijke dingen samen, en ze scheiden is het grootste deel van de correctie. Het eerste is bereik: welk lokaal adres, welke externe adressen, welk protocol en welk ICMP-type. Het tweede is voorwaarde: of het regelobject op dit moment is ingeschakeld. Bereik is wat een firewall per pakket beoordeelt; voorwaarde is wat een script in het beleidsarchief schrijft, en beide worden op volledig verschillende klokken afgestemd.

Als de eis werkelijk alleen VPN-peers is, beantwoordt bereik dat zonder enige logica voor verbindingsstatus: bind de regel aan de tunnelinterface of aan het tunneladresbereik, beperk de externe adressen tot de clientpool en geef het echo-type op in plaats van 'ICMP'. Die regel blijft correct als er geen VPN actief is en kan niet door een ongerelateerd profiel worden geopend.

Als de eis werkelijk een openbare poort is, zeg dat dan in de beleidstekst, want de acceptatiecriteria veranderen. Een openbare poort moet het exacte profiel noemen, definiëren wat 'verbonden' betekent en verklaren dat openbare afzenders volgens ontwerp binnen het bereik vallen. Het meeste misverstand verdwijnt op het moment dat iemand gedwongen wordt die zin op te schrijven.

Bouw het object één keer en schakel het dan

Zorg vooraf voor één regel met een stabiele identiteit, uitgeschakeld, en laat de controller alleen de ingeschakelde status wijzigen. Regels aanmaken op weergavenaam bij elke run is hoe een beleidsarchief eindigt met vijf bijna identieke objecten en geen betrouwbare manier om ze te verwijderen.

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

De naam is de duurzame identificatie; de weergavenaam is documentatie die een mens mag bewerken. Stem af op -Name en het script produceert geen duplicaten meer. Dezelfde commando-vorm dekt het IPv6-geval met -Protocol ICMPv6 -IcmpType 128, maar dat is een aparte regel omdat de echo-typenummers tussen de twee families verschillen.

Houd adresfamilie en ICMP-type expliciet om een tweede reden: -Protocol ICMPv4 zonder type staat elk ICMPv4-bericht toe dat het profiel toestaat, inclusief berichten die u nooit wilde accepteren. Type 8 noemen vernauwt de regel tot echo-verzoek, en dat is het enige wat een bereikbaarheidscontrole stuurt.

Waar de automatisering de bedoeling tegenspreekt

Een cliëntprofiel elke paar minuten pollen kan geen onmiddellijke grens opleveren. Tussen het wegvallen van de verbinding en de volgende poll antwoordt de regel nog op het openbare adres; tussen het opkomen van de verbinding en de volgende poll niet. Die vertraging toegeven is eerlijk, beweren dat het ontwerp een strikte invariant afdwingt niet.

Er zit een bereikval in de statuscontrole zelf. Get-VpnConnection rapporteert cliëntprofielen die op de machine zijn geconfigureerd, standaard voor de huidige gebruiker en voor alle gebruikers met -AllUserConnection. Het rapporteert niet de externe gebruikers die op dit moment bij een RRAS-server zijn ingebeld; dat is een andere waarneming met een andere cmdlet. Een poort gebouwd op de verkeerde is met niets verbonden.

Dek daarna de toestanden die niemand scriptet: opstarten met de regel al ingeschakeld uit een vorige run, een crash van de controller terwijl de poort open staat, en een verwijderd profiel terwijl de regel blijft leven. Elk vraagt een gedefinieerde standaard, en de veilige standaard voor een openbare toestemming is uitgeschakeld. Als de eis het pollvenster echt niet verdraagt, is een statusgebonden regel het verkeerde instrument en hoort de handhaving bij de tunnel, niet bij de openbare interface.

Test ten slotte het openbare verzoek twee keer, één keer met de gekozen verbinding actief en één keer met die uit, vanaf een host die niet op de VPN zit. Een geslaagde ping van binnen de tunnel bewijst niets over dit beleid, en dat is de meting die de meeste uitrollingen overslaan.