De ce nftables nu vede traficul OpenVPN dintre clienți

Doi clienți de pe un server fac schimb de fișiere, transferul reușește, iar fiecare regulă de redirecționare îndreptată spre tunel raportează zero pachete. Regulile nu sunt stricate, iar lanțul nu este pus greșit. Când redirecționarea între parteneri este activată, pachetul este livrat în interiorul procesului serverului, iar stiva gazdei nu devine niciodată router, așa că firewall-ul nucleului nu are ce număra. Înțelegerea acestei separări decide dacă păstrezi scurtătura sau reconstruiești calea prin nucleu.

Urmărește un pachet prin server

Într-un tunel rutat, demonul predă pachetul decriptat al fiecărui client dispozitivului de tunel. De acolo gazda îl rutează, cârligul de redirecționare rulează, iar o regulă care corespunde dispozitivului de tunel poate număra sau elimina traficul. Aceasta este calea pe care o presupun majoritatea exemplelor de firewall.

Scurtătura scoate gazda din mijloc. Pachetul decriptat al unei sesiuni este predat altei sesiuni în interiorul demonului, iar pachetul interior nu este niciodată emis pe dispozitivul de tunel și nu este rutat de gazdă. Traficul încapsulat traversează totuși interfața fizică, așa că o captură exterioară pare ocupată în timp ce regulile interioare rămân mute. O captură făcută pe dispozitivul de tunel nu arată absolut nimic, ceea ce surprinde pe oricine se așteaptă să vadă acolo transferul. Această asimetrie este cea mai rapidă cale de a recunoaște scurtătura din afara demonului.

Testul cu numărătoare care decide ce cale a rulat

Atașează o numărătoare la regula care ar trebui să se aplice, rulează un transfer între doi clienți pe care regula ar trebui să-i blocheze, apoi citește numărătoarea.

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

Dacă transferul reușește și numărătoarea rămâne la zero, nucleul nu a tratat niciodată acele pachete, iar nicio editare a regulilor nu va schimba asta. Repetă același test împotriva unui serviciu de pe serverul însuși, pentru că acel flux traversează într-adevăr stiva gazdei și numărătoarea lui se mișcă. Compararea celor două rezultate este cea care dă răspunsul.

Două detalii împiedică o citire falsă. Un nume de interfață scris într-o etichetă de lanț nu filtrează nimic de unul singur, pentru că potrivirea se face pe câmpurile de interfață din interiorul regulilor. Iar un proiect punte de nivel 2 se comportă din nou altfel: acolo clienții împart un singur domeniu de difuzare, așa că descoperirea partenerilor este așteptată, nu o defecțiune de rutare.

Un comutator nu este o listă de acces

Aceasta este partea care costă o după-amiază. Redirecționarea între parteneri este o singură setare pornit sau oprit, iar cât timp este pornită demonul este singurul punct de redirecționare. Firewall-ul gazdei nu poate exprima cine poate ajunge la cine, iar fișierele pe client nu transformă comutatorul într-o matrice de politici.

Dacă ai nevoie de reguli pe partener, alegerea este între a renunța la scurtătură și a renunța la firewall-ul gazdei ca instrument de control. Oprirea acestuia restaurează redirecționarea nucleului, ceea ce cere redirecționare IP pe server și reguli explicite pentru fluxurile dorite. A-l lăsa pornit înseamnă că politica trăiește în configurația demonului, ceea ce în practică înseamnă toți partenerii sau niciunul.

Procese de server separate cu propriile lor pool-uri de adrese și porturi sunt calea de mijloc viabilă. Fiecare proces poartă exact o decizie de acces, așa că două grupuri pot avea reguli diferite fără o matrice de politici. Gazda poate ruta între pool-uri când asta este intenția, iar atunci firewall-ul vede acele fluxuri pentru că traversează gazda. Costul este porturi suplimentare, certificate suplimentare și un profil pe grup.

Alegerea punctului de redirecționare

Alege redirecționarea nucleului când firewall-ul este motorul de politici, când ai nevoie de jurnalizare pe flux sau când contabilitatea contează. Costul este debitul prin stiva gazdei și mai multe reguli de întreținut. Beneficiul este că fiecare instrument existent, de la numărători la exportatorii de fluxuri, descrie din nou traficul. Pe un server mic acest cost este invizibil; pe un releu ocupat nu este.

Alege redirecționarea în proces când traficul dintre parteneri este fie complet permis, fie complet interzis și serverul este dimensionat pentru asta. Costul este că numărătorile, disciplinele de coadă și urmărirea conexiunilor nu mai descriu fluxurile interioare; asta este acceptabil doar dacă nimeni nu se bazează pe ele mai târziu.

Orice ai alege, scrie-l lângă regulile firewall-ului. Un set de reguli care pare să permită traficul dintre parteneri în timp ce demonul decide oricum induce în eroare următoarea persoană care depanează un transfer eșuat. Cine citește doar regulile va presupune că nucleul este poarta.

Ce să verifici înainte de a schimba regulile

Citește configurația pe care serverul a încărcat-o efectiv, nu fișierul pe care îți amintești că l-ai editat, și confirmă dacă opțiunea pentru parteneri este prezentă. Dacă ai modificat-o, asigură-te că serviciul s-a reîncărcat și nu doar a rescris un fișier pe disc.

Apoi repetă testul cu un flux de la client la server pentru a dovedi că regula se potrivește măcar, și verifică rutele trimise, pentru că o rută lipsă arată exact ca o blocare a firewall-ului din partea clientului. Schimbă ordinea regulilor doar după ce știi ce punct de redirecționare deține decizia.