Tots dos tallafocs poden filtrar el trànsit VPN reenviat, i enganxen les regles al camí del paquet de maneres diferents. iptables té cadenes integrades dins d’una taula, així que FORWARD existeix com a punt de ganxo amb nom. nftables separa el nom d’una cadena del seu tipus, ganxo i prioritat, cosa que significa que una cadena normal anomenada FORWARD no filtra absolutament res. Comparar els dos models explica per què una entrada que sembla correcta en una eina no té cap efecte en l’altra.

Una cadena és un contenidor. Que el nucli la consulti depèn de la implementació i de com el conjunt de regles l’enganxa.

Dos models, dos enganxaments diferents

A iptables, la taula filter porta tres cadenes integrades, INPUT, FORWARD i OUTPUT, i -N crea una cadena definida per l’usuari que només té efecte quan s’hi salta des d’una d’elles. El manual de nftables, en canvi, defineix cadenes base, que declaren el seu tipus, ganxo i prioritat, i cadenes normals, que no ho fan. Una cadena base pot portar qualsevol nom que vulgueu, i una cadena normal anomenada FORWARD no guanya cap propietat de la seva etiqueta. Aquesta és tota la diferència, i és invisible en un tutorial que només mostra text de regles.

Els rerefons de compatibilitat afegeixen una segona raó per no inferir el comportament del nom d’una ordre. La documentació d’iptables esmenta operacions que difereixen sota iptables-nft, així que tracteu nftables natiu, iptables-nft i un conjunt de regles antic com a tres sistemes i no com tres grafies d’un de sol.

Llegiu l’error en el seu context real

Una taula que falta, un error de permisos, una instal·lació del nucli no disponible i una cadena amb nom que falta són quatre troballes diferents, i només una tracta de la cadena. Anoteu la versió de l’eina, la família d’adreces i la taula sol·licitades, l’espai de noms de xarxa i el primer error exacte. Després comproveu quin component posseeix el conjunt de regles: un servei de tallafocs o una passarel·la gestionada per un producte poden generar les seves pròpies cadenes i el seu ordre. Afegir una cadena nativa al costat d’elles deixa la política gestionada intacta i fa l’inventari més confús.

L’espai de noms d’un contenidor pot contenir un conjunt de regles diferent del de l’amfitrió, així que una ordre executada en el context equivocat no pot mostrar quina cadena va veure un paquet reenviat. Elevar privilegis perquè una cadena esperada no era visible no és cap diagnòstic.

Els comptadors proven l’abast, no el veredicte

Els comptadors de regles us diuen que s’ha arribat a una regla. No us diuen que una regla posterior hagi permès l’operació, ni proven que tots els camins alternatius hagin estat denegats. Llegiu-los durant un flux autoritzat i inofensiu, juntament amb l’ordre de les regles i l’enganxament de la cadena, i tracteu-los com una observació i no com un veredicte. Un comptador diferent de zero en una regla de descart significa que el trànsit hi va arribar; no diu res del trànsit que no hi va arribar.

El reenviament IP del nucli és un paràmetre completament a part. Que existeixi una cadena no activa el reenviament, i que falti una etiqueta coneguda no vol dir que el reenviament s’hagi aturat.

Descriu el flux que espereu protegir

Anoteu una sol·licitud de client després de la desencapsulació: la seva origen, la seva destinació, la família d’adreces i si acaba a la passarel·la o hi passa. L’entrada del servei local i el trànsit reenviat s’observen en punts diferents, així que necessiten regles i proves diferents. Per a una VPN amb pont, verifiqueu també el camí del pont, perquè una cadena a nivell IP no controla automàticament les trames Ethernet.

Preserveu un accés de recuperació independent abans de canviar una passarel·la remota. Després confirmeu el flux previst i les denegacions necessàries sota el mateix conjunt de regles. Una cadena nova i buida amb un nom conegut no és una reparació.

La comparació acaba en una pregunta: quin ganxo crida realment el nucli per a aquest paquet? Responeu-la i el nom de la cadena deixa de tenir importància.

Articles relacionats