Ĉena nomo ne estas hoko: iptables kontraŭ nftables

Ambaŭ fajroŝirmiloj povas filtri plusenditan VPN-trafikon, kaj ili ligas regulojn al la paketa vojo laŭ malsamaj manieroj. iptables havas enkonstruitajn ĉenojn ene de tabelo, do FORWARD ekzistas kiel nomita hoka punkto. nftables apartigas la nomon de ĉeno de ĝia tipo, hoko kaj prioritato, kio signifas, ke ordinara ĉeno nomata FORWARD tute nenion filtras. Kompari la du modelojn klarigas, kial enskribo, kiu ŝajnas ĝusta en unu ilo, havas neniun efikon en la alia.

Ĉeno estas ujo. Ĉu la kerno konsultas ĝin, dependas de la efektivigo kaj de tio, kiel la regulkompleto ligas ĝin.

Du modeloj, du malsamaj ligoj

En iptables la tabelo filter liveras tri enkonstruitajn ĉenojn — INPUT, FORWARD kaj OUTPUT — kaj -N kreas ĉenon difinitan de la uzanto, kiu efikas nur tiam, kiam oni saltas al ĝi el unu el ili. La manlibro de nftables anstataŭe difinas bazajn ĉenojn, kiuj deklaras sian tipon, hokon kaj prioritaton, kaj ordinarajn ĉenojn, kiuj tion ne faras. Baza ĉeno povas porti ajnan nomon, kiun vi volas, kaj ordinara ĉeno nomata FORWARD ne gajnas iujn ajn ecojn de sia etikedo. Tio estas la tuta diferenco, kaj ĝi estas nevidebla en lernilo, kiu montras nur regultekston.

Kongruecaj dorsflankoj aldonas duan kialon ne deduki konduton el komanda nomo. La dokumentaro de iptables notas operaciojn, kiuj diferencas sub iptables-nft, do traktu denaskan nftables, iptables-nft kaj malnovan regulkompleton kiel tri sistemojn, ne kiel tri literumojn de unu.

Legu la eraron en ĝia reala kunteksto

Mankanta tabelo, permesa fiasko, neatingebla kerno-funkcio kaj mankanta nomita ĉeno estas kvar malsamaj trovoj, kaj nur unu temas pri la ĉeno. Notu la ilan version, la petitan adresfamilion kaj tabelon, la retan nomspacon kaj la unuan precizan eraron. Poste kontrolu, kiu komponanto posedas la regulkompleton: fajroŝirmila servo aŭ produkto-administrata pordego povas generi proprajn ĉenojn kaj ordon. Aldoni denaskan ĉenon apud ili lasas la administritan politikon netuŝita kaj igas la inventaron pli konfuza.

La nomspaco de ujo povas teni alian regulkompleton ol la gastiganto, do komando lanĉita en malĝusta kunteksto ne povas montri, kiu ĉeno vidis plusenditan paketon. Plialtigi privilegiojn ĉar atendita ĉeno ne estis videbla ne estas diagnozo.

Nombriloj pruvas atingon, ne verdikton

Regulnombriloj diras al vi, ke regulo estis atingita. Ili ne diras, ke posta regulo permesis la operacion, kaj ili ne pruvas, ke ĉiu alternativa vojo estis rifuzita. Legu ilin dum unu sendanĝera rajtigita fluo, kune kun la regula ordo kaj la ĉena ligo, kaj traktu ilin kiel unu observon anstataŭ verdikto. Ne-nula nombrilo ĉe forĵeta regulo signifas, ke trafiko trafis ĝin; ĝi diras nenion pri trafiko, kiu ne trafis.

IP-plusendado en la kerno estas tute aparta agordo. Ekzistanta ĉeno ne ŝaltas plusendadon, kaj mankanta konata etikedo ne signifas, ke plusendado ĉesis.

Priskribu la fluon, kiun vi atendas protekti

Notu unu klientan peton post malkapsuligo: ĝian fonton, ĝian celon, la adresfamilion, kaj ĉu ĝi finiĝas ĉe la pordego aŭ pasas tra ĝi. Loka serva enigo kaj plusendita trafiko observiĝas ĉe malsamaj punktoj, do ili bezonas malsamajn regulojn kaj malsamajn testojn. Por punktopontita VPN, kontrolu ankaŭ la pontan vojon, ĉar ĉeno je IP-nivelo ne kontrolas Ethernet-kadrojn aŭtomate.

Konservu sendependan reakiran aliron antaŭ ol ŝanĝi malproksiman pordegon. Poste konfirmu la celatan fluon kaj la postulitajn rifuzojn sub la sama regulkompleto. Nova malplena ĉeno kun konata nomo ne estas riparo.

La komparo finiĝas per unu demando: kiun hokon la kerno efektive vokas por ĉi tiu paketo? Respondu tion, kaj la ĉena nomo ĉesas gravi.