De ce o regulă de blocare a clientului OpenVPN nu ajunge niciodată în FORWARD

Doi clienți de pe același server OpenVPN se pot atinge unul pe celălalt chiar și după ce ați adăugat o regulă DROP pentru pool-ul lor. Regula stă în lanțul FORWARD, traficul curge limpede, iar contorul acelei reguli rămâne la zero. Concluzia firească este că firewall-ul este stricat. Mai des, pachetul nici nu a intrat în lanț.

Există două căi pe care un pachet de peer le poate urma printr-un server OpenVPN, iar ele sunt hotărâte de configurație, nu de firewall. Să știi care cale este folosită îți spune dacă o regulă a gazdei este măcar în locul potrivit.

Două căi pe care poate merge un pachet de peer

Când opțiunea de forwarding intern este dezactivată, un pachet de la clientul A ajunge pe interfața tunelului cu o destinație în interiorul adresei atribuite clientului B. Tabela de rutare a serverului îl trimite înapoi prin aceeași interfață a tunelului, pentru că serverul deține ruta către adresa lui B. Este un flux de intrare și ieșire prin gazdă, iar calea de forwarding IPv4 îl evaluează.

Când opțiunea de forwarding intern este activată, procesul serverului potrivește pachetul cu un client conectat și îl scrie înapoi direct acelui client. Pachetul este tratat în interiorul daemonului și nu mai intră niciodată în dispozitivul tunelului, așa că calea de forwarding a gazdei este sărită complet. Manualul OpenVPN 2.6 descrie această opțiune ca forwarding intern de la client la client, și exact de aceea o regulă a firewall-ului gazdei nu o poate vedea.

Există o a treia variantă în implementările care mută canalul de date într-un modul de kernel. Decizia de forwarding și criptarea ies din spațiul utilizatorului, iar dacă netfilter vede fluxul depinde de felul în care este construită calea de transfer. Nu presupune niciodată că un set vechi de reguli se comportă pe un server cu transfer la fel ca pe unul din spațiul utilizatorului. Confirmă modul din configurația care rulează, nu din versiunea pachetului.

Când contorul nu se mișcă niciodată

Un contor zero înseamnă că pachetul nu s-a potrivit cu acea regulă în acel punct, iar motivele sunt mai multe. Primul este ocolirea de mai sus: traficul nu a ajuns niciodată la lanț. Al doilea este o nepotrivire de interfață, direcție, sursă sau destinație, ceea ce este obișnuit când pool-ul a fost renumerotat, iar regula încă numește prefixul vechi.

Al treilea este poziția. O regulă mai devreme în lanț poate accepta fluxul înainte ca DROP-ul tău să fie evaluat, iar o regulă mai târziu poate fi cea care decide de fapt rezultatul. Citește lanțul în ordine cu contoarele vizibile, apoi verifică al cărei reguli contor crește când repeți testul.

Fă un singur schimb controlat între doi clienți ale căror adrese reale le-ai confirmat din starea serverului însuși, nu dintr-un lease pe care îl ții minte. Dacă contorul relevant tot nu se mișcă, suspectează calea înainte de a rescrie potrivirea. Dacă se mișcă, dar conexiunea tot reușește, drop-ul este suprascris mai târziu și problema este ordinea. Acel răspuns hotărăște dacă reparația este o schimbare de regulă sau o schimbare de topologie, așa că obține-l înainte de a edita ceva.

Alegerea unei granițe care poate filtra

Dacă politica trebuie să trăiască în firewall-ul gazdei, pune traficul unde firewall-ul îl poate vedea. Dezactivarea forwarding-ului intern este modalitatea susținută de a face traficul dintre peers să treacă prin interfața tunelului și prin calea de forwarding, cu prețul de a trimite fiecare pachet de peer prin stiva gazdei.

Apoi potrivește fluxul cu precizie. Traficul sosește pe interfața tunelului și iese prin interfața tunelului, în ambele direcții, așa că regulile care iau în calcul doar interfața fizică nu se vor potrivi. Regulile bazate pe adrese au nevoie de pool-ul curent și trebuie să țină cont de direcția de retur la fel ca de cea înainte.

Multe implementări sunt servite mai bine de filtrarea la nivel de client sau de grup, unde identitatea este cunoscută și politica urmează utilizatorul în locul unei adrese care se schimbă la reconectare. Acesta este un mecanism diferit de un lanț al gazdei, iar cele două nu ar trebui amestecate fără un motiv clar.

Nu transporta neschimbat setul de reguli al unei topologii vechi printr-o migrare. Pool-urile de adrese, numele interfețelor și modurile de forwarding influențează toate dacă o regulă se potrivește, iar o regulă copiată care funcționa cândva este cel mai înșelător tip de dovadă. Pornește de la fluxul pe care vrei să îl permiți și scrie regula care i se potrivește.

Testarea izolării în loc de încrederea într-o regulă

Testează cazul interzis și cazul permis în aceeași rulare. Pornește o conexiune nouă de la un client la celălalt și confirmă că eșuează, apoi confirmă că o conexiune care ar trebui permisă încă funcționează. Dacă se testează doar primul, un firewall care blochează tot pare un succes.

Repetă după reîncărcarea configurației serverului și după ce un client se reconectează, pentru că forwarding-ul intern și alocările de pool sunt stare de execuție. Verifică contoarele în ambele direcții, fiindcă o regulă care se potrivește pe o direcție și nu pe răspuns produce izolare parțială, greu de observat într-un test rapid.

Izolarea este rezultatul observat la granița care chiar transportă fluxul. O regulă DROP undeva în gazdă nu este dovadă; o conexiune eșuată plus un contor mișcat pe regula care a cauzat-o este.