Două grupuri de clienți, un singur server: unde se aplică politica

Așezarea a două grupuri de clienți pe subrețele diferite pare izolare, și nu este. Adresele descriu de unde pare că vine un pachet, în timp ce permisiunea este o decizie luată de ceea ce îl redirecționează. La această întrebare răspunde configurația, nu masca, așa că decideți ce componentă redirecționează traficul între egali înainte de a scrie vreo regulă.

O subrețea este o etichetă, nu o regulă

Alocarea unui pool pe grup vă oferă adrese lizibile și nimic altceva. Un client care acceptă o rută suplimentară a câștigat accesibilitate, iar accesibilitatea nu este autorizare. Permisiunea de a vorbi se află în decizia de redirecționare, care poate locui în daemon sau în nucleu, în funcție de modul în care este configurat serverul.

Proprietatea adresei este ceea ce face un prefix utilizabil ca selector de grup. Fiecare identitate autentificată trebuie să corespundă unei adrese sau unui interval previzibil, iar această mapare eșuează de îndată ce mai multe dispozitive partajează o singură acreditare și o singură alocare. Rezolvați identitatea și concurența înainte de a vă baza pe un prefix sursă, pentru că o politică ce ghicește care mașină sună autorizează cea greșită în cel mai rău moment.

Alegeți calea care transportă traficul între egali

Când daemonul redirecționează pachetele între egali în propriul proces, acele pachete nu ajung niciodată la cârligul de redirecționare al gazdei, așa că o regulă din nucleu nu le poate vedea. Dezactivați acea redirecționare internă și nucleul devine punctul de redirecționare, unde se aplică regulile obișnuite de redirecționare.

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

Canalele de date descărcate și serverele administrate de produs își publică propriile modele de aplicare, așa că confirmați pe care îl rulați în loc să presupuneți comportamentul comunității. Eșecul care merită evitat este o regulă care pare corectă la o revizuire și nu este niciodată consultată în timpul execuției.

Scrieți matricea înainte de reguli

O matrice scurtă este mai ușor de revizuit decât un set de reguli și este contractul pe care implementarea trebuie să îl îndeplinească: egali din același grup permiși, egali între grupuri respinși, ambele grupuri permise către un serviciu partajat numit, tot restul respins. Scrieți aceste patru linii înainte de a deschide un editor de firewall. Un revizor care nu citește sintaxa regulilor poate verifica totuși matricea. Apoi implementarea trebuie doar să corespundă liniilor.

Țineți cele trei clase de destinație separate în timp ce o scrieți. Un serviciu pe gazda VPN este intrare locală, un alt client este tranzit între egali, iar o mașină din spatele gateway-ului este o altă cale de redirecționare. O singură regulă generoasă poate acorda toate trei din greșeală, și așa o politică de grup devine o rețea plată cu pași în plus. Scrieți clasa lângă fiecare rând pentru ca intenția să supraviețuiască următoarei editări.

Puneți regulile unde supraviețuiesc

Adăugați deciziile în același loc unde este întreținut restul firewall-ului, înaintea oricărei reguli permisive care altfel le-ar înghiți. Ordinea regulilor face parte din politică, iar o regulă corectă plasată după o acceptare largă nu aplică nimic. Notați numerele regulilor înainte și după modificare. O politică ce există într-un editor dar nu în setul de reguli care rulează este un plan, nu un control.

Decideți ce se întâmplă cu fluxurile care există deja când politica se schimbă, pentru că o sesiune deschisă înainte de modificare poate continua după ea. Dacă un membru care pleacă trebuie să piardă accesul imediat, setul de reguli are nevoie de o modalitate de a încheia acea stare în loc să aștepte ca conexiunea să se închidă singură.

Faceți regulile persistente prin mecanismul care deține restul firewall-ului și înregistrați matricea alături de ele. O politică neînregistrată este rederivată din memorie în timpul următorului incident, de obicei de cineva grăbit.

Dovediți-o din ambele părți

Testați accesibilitatea în același grup, eșecul între grupuri și serviciul partajat de la un client din fiecare grup. Un singur test de la un singur client dovedește jumătate din matrice, iar jumătatea omisă este de obicei cea greșită. Repetați direcția de respingere de două ori, pentru că o sesiune din cache poate ascunde o eroare de aplicare. Notați ce pereche ați testat, ca următoarea persoană să nu o repete.

Repetați verificarea pe IPv6 dacă tunelul îl transportă și păstrați autentificarea obișnuită a aplicațiilor. Un prefix sursă nu este un cont, așa că trecerea politicii de rețea nu înseamnă că un serviciu ar trebui să aibă încredere în apelant.