Profiluri de firewall versus ieșirea VPN: de ce public nu este o cale

Regula sună precis: permite traficul local pe profilul privat și doar traficul VPN pe cel public. Nu este, pentru că un profil de rețea alege ce set de reguli de firewall se aplică și nu spune nimic despre ce adaptor a transportat un pachet. Tratarea numelui profilului ca cerință de cale este greșeala care face un proiect de ieșire restricționată să pară terminat când nu este.

Notați mai întâi fluxurile, apoi decideți ce mecanism poate impune cu adevărat fiecare dintre ele. Acea listă de fluxuri este singurul artefact care supraviețuiește următoarei modificări de reguli.

Categoria alege reguli, nu rute

Când Windows clasifică o rețea ca publică sau privată, firewall-ul aplică setul de reguli configurat pentru acel profil. Clasificarea urmează rețeaua la care s-a alăturat adaptorul, iar setul de reguli decide ce este permis pe ea. Niciunul dintre aceste fapte nu depinde de faptul că traficul unei aplicații a folosit tunelul. Exact această independență este întreaga dificultate.

Alegerea căii o face rutarea, prin metrica interfeței și prefixul pe care îl instalează tunelul. Un profil poate fi deci etichetat ca public în timp ce conexiunea unei aplicații ia calea fizică, iar firewall-ul va raporta totuși că s-a aplicat setul de reguli public.

De aceea o regulă limitată la profil nu poate însemna doar tunel. Cele două proprietăți sunt decise de componente diferite și una nu o poate înlocui pe cealaltă.

O blocare explicită are prioritate față de o permisiune mai îngustă

Îndrumările Microsoft privind regulile de firewall disting o permisiune ca excepție de la o acțiune de blocare implicită de o blocare explicită care intră în conflict cu o permisiune. Blocările explicite câștigă acel conflict, iar regulile de ieșire respectă aceeași precedență.

Așadar rețeta populară de a adăuga o regulă care blochează tot și de a te baza pe o permisiune mai îngustă plasată deasupra nu face ce se așteaptă autorul ei. Firewall-ul Windows nu rezolvă conflictul după ordinea regulilor atribuită de administrator. Blocarea se aplică pur și simplu, iar aplicația care se conectează raportează un timeout. Regula care părea excepția nu a fost niciodată în joc.

Forma acceptată este o politică de refuz implicit cu reguli de permisiune aprobate, în care fiecare permisiune numește un program, un serviciu sau o destinație suficient de precis pentru a putea fi revizuită. Acel proiect trece de un audit, pentru că fiecare excepție este vizibilă și niciuna nu depinde de ordinea în care a fost creată.

Două reguli care se contrazic sunt mai rele decât o singură regulă, pentru că comportamentul rezultat este corect și inexplicabil în același timp.

Dați politicii de ieșire un singur proprietar

Un client VPN acceptat își întreține deja propriul comportament de blocare și propriile excepții de punct final. Adăugarea unor reguli manuale necoordonate poate lăsa acel client în afara tunelului de care are nevoie pentru configurare sau poate lăsa deschisă o a doua cale pe care nimeni nu a observat-o.

Decideți cine deține politica de ieșire înainte de a scrie reguli: configurația clientului însuși, o politică de firewall gestionată sau o listă locală de excepții documentată cu un proprietar. Apoi reconciliați straturile în loc să stivuiți experimente până când ceva se conectează. Un proprietar numit este și persoana întrebată când două straturi nu sunt de acord.

Păstrați un canal de recuperare înainte de a schimba ceva. O mașină de la distanță blocată în afara propriei căi de administrare este un rezultat mai rău decât golul de politică pe care îl închideați. Regula de recuperare este mai ușor de justificat când este scrisă dinainte și mai ușor de găsit când o modificare merge prost la o oră pe care nimeni nu o agreează.

Testați patru rezultate în loc să citiți eticheta

O politică este la fel de bună pe cât de bine distinge cazurile, așa că tratați eticheta profilului ca punct de plecare, nu ca rezultat. Patru rezultate vă spun dacă funcționează: cererea LAN prevăzută reușește, o cerere de internet acoperită reușește, o cerere directă interzisă eșuează, iar cazul de eșec al tunelului se comportă conform proiectării în loc să se retragă în tăcere. Notați cele patru rezultate lângă modificarea regulilor. Un plan de testare cu patru cazuri numite este suficient de scurt pentru a fi rulat de fiecare dată și suficient de specific pentru a eșua zgomotos.

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

Prima comandă arată cum este clasificată fiecare rețea conectată, ceea ce adesea nu este ce a presupus persoana care a scris regula. A doua arată acțiunea implicită pe profil, iar a treia listează blocările de ieșire activate, inclusiv cele care vor anula în tăcere o permisiune mai îngustă.

Rulați din nou cele patru cazuri după o schimbare de rețea, pentru că un profil poate fi reclasificat când mașina se alătură altei rețele. O etichetă de profil potrivită nu este dovada că calea a fost cea pe care o intenționați.