De ce o poartă de firewall legată de starea VPN nu este o regulă de ping doar prin tunel

Imaginați-vă o regulă de firewall care activează ICMP echo pentru adresa publică a serverului de fiecare dată când este conectat un profil VPN numit. Se citește ca „ping doar prin tunel”, iar această lectură este greșită într-un mod care contează. Regula nu restricționează cine poate ajunge la gazdă; schimbă ce răspunde interfața publică în timp ce o altă conexiune este activă din întâmplare. Sunt două politici diferite, iar una dintre ele lărgește expunerea în liniște.

Regula pe care credeți că ați scris-o

Cerința vizată este de obicei îngustă: sistemul de monitorizare, sau singurul administrator din VPN, trebuie să poată confirma că serverul este viu. Scrisă ca o propoziție, sună ca un control de acces pe tunel. Scrisă ca obiect de firewall, devine o condiție pe profilul public, pentru că acolo ajunge cererea echo.

Odată ce condiția este o stare a conexiunii și nu o adresă sursă, mulțimea expeditorilor permiși nu mai este mulțimea partenerilor VPN. Oricine poate ajunge la adresa publică poate trimite o cerere echo cât timp poarta este deschisă. Tunelul nu a devenit calea; tunelul a devenit întrerupătorul.

Cei care promovează această idee de obicei nu mint despre efectul dorit. Aveau nevoie de o verificare care răspunde doar când legătura este sănătoasă, iar sănătatea legăturii era cel mai ușor de observat prin VPN. Greșeala este să tratezi un semnal de disponibilitate ca decizie de acces și apoi să îl automatizezi.

Ce controlează de fapt poarta

Acest design fuzionează două lucruri independente, iar separarea lor este cea mai mare parte a corecției. Prima este aria de cuprindere: ce adresă locală, ce adrese îndepărtate, ce protocol și ce tip ICMP. A doua este condiția: dacă obiectul regulii este activat în acest moment. Aria de cuprindere este ce evaluează un firewall pentru fiecare pachet; condiția este ce scrie un script în depozitul de politici, iar cele două se reconciliază pe ceasuri complet diferite.

Dacă cerința este într-adevăr doar partenerii VPN, aria de cuprindere o rezolvă fără nicio logică de stare a conexiunii: legați regula de interfața tunelului sau de intervalul de adrese al tunelului, limitați adresele îndepărtate la grupul de clienți și specificați tipul echo în loc de „ICMP”. Acea regulă rămâne corectă când nu este activ niciun VPN și nu poate fi deschisă de un profil fără legătură.

Dacă cerința este într-adevăr o poartă publică, spuneți-o în textul politicii, pentru că criteriile de acceptare se schimbă. O poartă publică trebuie să numească profilul exact, să definească ce înseamnă „conectat” și să declare că expeditorii publici sunt în aria de cuprindere prin proiectare. Cea mai mare parte a confuziei dispare în momentul în care cineva este obligat să scrie acea propoziție.

Construiți obiectul o dată, apoi comutați-l

Furnizați în avans o singură regulă cu o identitate stabilă, dezactivată, și lăsați controllerul să schimbe doar starea ei de activare. Crearea regulilor după numele afișat la fiecare rulare este modul în care un depozit de politici ajunge cu cinci obiecte aproape identice și fără o modalitate fiabilă de a le elimina.

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

Numele este identificatorul durabil; numele afișat este documentație pe care o persoană o poate edita. Reconciliați după -Name și scriptul nu mai produce duplicate. Aceeași formă de comandă acoperă cazul IPv6 cu -Protocol ICMPv6 -IcmpType 128, dar este o regulă separată pentru că numerele tipului echo diferă între cele două familii.

Păstrați familia de adrese și tipul ICMP explicite și pentru un al doilea motiv: -Protocol ICMPv4 fără tip permite fiecare mesaj ICMPv4 pe care profilul îl admite, inclusiv pe cele pe care nu ați intenționat niciodată să le acceptați. Numirea tipului 8 îngustează regula la cererea echo, iar acesta este singurul lucru pe care îl trimite o verificare de accesibilitate.

Unde automatizarea contrazice intenția

Interogarea unui profil de client la fiecare câteva minute nu poate produce o graniță imediată. Între căderea conexiunii și următoarea interogare regula răspunde încă pe adresa publică; între ridicarea conexiunii și următoarea interogare nu răspunde. Să recunoști acea întârziere este onest, să afirmi că designul impune un invariant strict nu este.

Există o capcană de cuprindere în verificarea stării în sine. Get-VpnConnection raportează profilurile de client configurate pe mașină, implicit pentru utilizatorul curent și pentru toți utilizatorii cu -AllUserConnection. Nu raportează utilizatorii la distanță care sunt conectați în acest moment la un server RRAS; aceea este o altă observație cu altă comandă. O poartă construită pe cea greșită nu este conectată la nimic.

Apoi acoperiți stările pe care nimeni nu le scriptează: pornirea cu regula deja activată dintr-o rulare anterioară, prăbușirea controllerului cu poarta deschisă și un profil șters în timp ce regula lui rămâne vie. Fiecare are nevoie de un implicit definit, iar implicitul sigur pentru o permisiune publică este dezactivat. Dacă cerința nu tolerează fereastra de interogare, o regulă legată de stare este instrumentul greșit, iar aplicarea aparține tunelului, nu interfeței publice.

În final, testați cererea publică de două ori: o dată cu conexiunea aleasă activă și o dată cu ea căzută, de la un gazdă care nu este în VPN. Un ping reușit din interiorul tunelului nu dovedește nimic despre această politică, și aceasta este măsurătoarea pe care majoritatea implementărilor o sar.