Numele unui lanț nu este un cârlig: iptables față de nftables

Ambele firewall-uri pot filtra traficul VPN redirecționat, iar regulile le atașează la calea pachetului în moduri diferite. iptables are lanțuri încorporate într-un tabel, așa că FORWARD există ca punct de cârlig cu nume. nftables separă numele unui lanț de tipul, cârligul și prioritatea acestuia, ceea ce înseamnă că un lanț obișnuit numit FORWARD nu filtrează nimic. Compararea celor două modele explică de ce o intrare care pare corectă într-un instrument nu are niciun efect în celălalt.

Un lanț este un recipient. Dacă nucleul îl consultă depinde de implementare și de felul în care setul de reguli îl atașează.

Două modele, două atașări diferite

În iptables, tabelul filter vine cu trei lanțuri încorporate, INPUT, FORWARD și OUTPUT, iar -N creează un lanț definit de utilizator care are efect doar când se sare la el dintr-unul dintre ele. Manualul nftables definește în schimb lanțuri de bază, care își declară tipul, cârligul și prioritatea, și lanțuri obișnuite, care nu fac asta. Un lanț de bază poate purta orice nume, iar un lanț obișnuit numit FORWARD nu primește nicio proprietate de la eticheta sa. Aceasta este întreaga diferență, și este invizibilă într-un tutorial care arată doar textul regulilor.

Backend-urile de compatibilitate adaugă un al doilea motiv de a nu deduce comportamentul din numele unei comenzi. Documentația iptables notează operații care diferă sub iptables-nft, așa că tratați nftables nativ, iptables-nft și un set de reguli vechi ca trei sisteme, nu ca trei grafii ale unuia singur.

Citiți eroarea în contextul ei real

Un tabel lipsă, o eroare de permisiune, o facilitate de nucleu indisponibilă și un lanț numit lipsă sunt patru constatări diferite, iar doar una privește lanțul. Notați versiunea instrumentului, familia de adrese și tabelul cerute, spațiul de nume de rețea și prima eroare exactă. Apoi verificați ce componentă deține setul de reguli: un serviciu de firewall sau o poartă administrată de produs poate genera propriile lanțuri și ordonare. Adăugarea unui lanț nativ lângă ele lasă politica administrată neatinsă și inventarul mai confuz.

Spațiul de nume al unui container poate conține un set de reguli diferit de cel al gazdei, așa că o comandă rulată în contextul greșit nu poate arăta care lanț a văzut un pachet redirecționat. Ridicarea privilegiilor pentru că un lanț așteptat nu era vizibil nu este un diagnostic.

Contoarele dovedesc atingerea, nu verdictul

Contoarele de reguli vă spun că o regulă a fost atinsă. Nu vă spun că o regulă ulterioară a permis operația și nu dovedesc că fiecare cale alternativă a fost refuzată. Citiți-le în timpul unui singur flux autorizat și inofensiv, împreună cu ordinea regulilor și atașarea lanțului, și tratați-le ca o singură observație, nu ca un verdict. Un contor diferit de zero pe o regulă de drop înseamnă că traficul a lovit-o; nu spune nimic despre traficul care nu a lovit-o.

Redirecționarea IP din nucleu este o setare complet separată. Existența unui lanț nu activează redirecționarea, iar absența unei etichete familiare nu înseamnă că redirecționarea s-a oprit.

Descrieți fluxul pe care doriți să îl protejați

Notați o singură cerere de client după decapsulare: sursa, destinația, familia de adrese și dacă se termină la poartă sau trece prin ea. Intrarea serviciului local și traficul redirecționat sunt observate în puncte diferite, așa că au nevoie de reguli și teste diferite. Pentru un VPN în punte, verificați și calea punții, deoarece un lanț la nivel IP nu supraveghează automat cadrele Ethernet.

Păstrați un acces independent de recuperare înainte de a modifica o poartă la distanță. Apoi confirmați fluxul dorit și refuzurile necesare sub același set de reguli. Un lanț gol nou cu un nume familiar nu este o reparație.

Comparația se termină într-o singură întrebare: care cârlig este apelat cu adevărat de nucleu pentru acest pachet? Răspundeți la asta, iar numele lanțului încetează să mai conteze.