Proč brána firewallu vázaná na stav VPN není pravidlem pro ping pouze tunelem

Představte si pravidlo firewallu, které zapne ICMP echo pro veřejnou adresu serveru pokaždé, když je připojen pojmenovaný profil VPN. Čte se to jako „ping jen tunelem“ a takové čtení je špatné způsobem, na kterém záleží. Pravidlo neomezuje, kdo se může dostat k hostiteli; mění, na co veřejné rozhraní odpovídá, dokud je náhodou aktivní jiné připojení. To jsou dvě různé politiky a jedna z nich tiše rozšiřuje vystavení.

Pravidlo, které jste si mysleli, že jste napsali

Zamýšlený požadavek je obvykle úzký: monitorovací systém nebo jediný správce na VPN musí být schopen potvrdit, že server žije. Napsáno jako věta, zní to jako řízení přístupu k tunelu. Napsáno jako objekt firewallu, změní se to v podmínku na veřejném profilu, protože právě tam požadavek echo přichází.

Jakmile se podmínkou stane stav připojení a ne zdrojová adresa, množina povolených odesílatelů už není množinou peerů VPN. Kdokoli, kdo se dostane na veřejnou adresu, může odeslat požadavek echo, dokud je brána otevřená. Tunel se nestal cestou; tunel se stal přepínačem.

Lidé, kteří tento nápad prodávají, obvykle nelžou o efektu, který chtěli. Potřebovali kontrolu, která odpovídá jen tehdy, když je spojení zdravé, a zdraví spoje bylo nejsnazší pozorovat přes VPN. Chyba je považovat signál dostupnosti za rozhodnutí o přístupu a pak to automatizovat.

Co brána ve skutečnosti řídí

Tento návrh slévá dvě nezávislé věci a jejich oddělení je většinou opravy. První je rozsah: která místní adresa, které vzdálené adresy, který protokol a který typ ICMP. Druhá je podmínka: zda je objekt pravidla právě zapnutý. Rozsah je to, co firewall vyhodnocuje pro každý paket; podmínka je to, co skript zapisuje do úložiště zásad, a obojí se slaďuje na zcela jiných hodinách.

Pokud je požadavek opravdu jen peery VPN, rozsah ho vyřeší bez jakékoli logiky stavu připojení: přivažte pravidlo k rozhraní tunelu nebo k rozsahu adres tunelu, omezit vzdálené adresy na pool klientů a uveďte typ echo místo „ICMP“. Takové pravidlo zůstává správné, když není aktivní žádná VPN, a nemůže ho otevřít nesouvisející profil.

Pokud je požadavek opravdu veřejná brána, řekněte to v textu politiky, protože kritéria přijetí se mění. Veřejná brána musí pojmenovat přesný profil, definovat, co znamená „připojeno“, a uvést, že veřejní odesílatelé jsou v rozsahu záměrně. Většina zmatku zmizí v okamžiku, kdy je někdo nucen tu větu napsat.

Postavte objekt jednou a pak ho přepínejte

Zřiďte předem jediné pravidlo se stabilní identitou, vypnuté, a nechte kontroler měnit jen jeho stav zapnutí. Vytváření pravidel podle zobrazovaného názvu při každém běhu je způsob, jakým úložiště zásad skončí s pěti téměř totožnými objekty a bez spolehlivého způsobu, jak je odebrat.

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

Název je trvalý identifikátor; zobrazovaný název je dokumentace, kterou člověk může upravit. Slaďte podle -Name a skript přestane vytvářet duplikáty. Stejný tvar příkazu pokrývá případ IPv6 s -Protocol ICMPv6 -IcmpType 128, ale to je samostatné pravidlo, protože čísla typu echo se mezi oběma rodinami liší.

Rodinu adres a typ ICMP držte explicitní i z druhého důvodu: -Protocol ICMPv4 bez typu povoluje každou zprávu ICMPv4, kterou profil připouští, včetně těch, které jste nikdy nechtěli přijímat. Pojmenování typu 8 zužuje pravidlo na požadavek echo, což je jediné, co kontrola dostupnosti odesílá.

Kde automatizace odporuje záměru

Dotazování klientského profilu každých několik minut nemůže vytvořit okamžitou hranici. Mezi vypadnutím připojení a dalším dotazem pravidlo stále odpovídá na veřejné adrese; mezi navázáním připojení a dalším dotazem neodpovídá. Přiznat toto zpoždění je poctivé, tvrdit, že návrh vynucuje striktní invariant, nikoli.

V samotné kontrole stavu je past rozsahu. Get-VpnConnection hlásí klientské profily nakonfigurované na stroji, ve výchozím nastavení pro aktuálního uživatele a pro všechny uživatele s -AllUserConnection. Nehlásí vzdálené uživatele, kteří jsou právě připojeni k serveru RRAS; to je jiné pozorování s jiným příkazem. Brána postavená na nesprávném není připojena k ničemu.

Pak pokryjte stavy, které nikdo neskriptuje: start s pravidlem už zapnutým z předchozího běhu, pád kontroleru při otevřené bráně a smazaný profil, jehož pravidlo zůstává aktivní. Každý potřebuje definovanou výchozí hodnotu a bezpečná výchozí hodnota pro veřejné povolení je vypnuto. Pokud požadavek opravdu nesnese okno dotazování, pravidlo vázané na stav je nesprávný nástroj a vymáhání patří tunelu, ne veřejnému rozhraní.

Nakonec otestujte veřejný požadavek dvakrát, jednou s vybraným připojením nahoru a jednou s ním dole, z hostitele, který není na VPN. Úspěšný ping zevnitř tunelu nic o této politice nedokazuje, a to je měření, které většina nasazení vynechává.