El canvi de regla del tallafoc no funciona: ordre de les regles i estat de la connexió

Heu editat la regla, heu recarregat el conjunt de regles i el túnel es comporta exactament com abans. Aquest resultat té dues causes habituals i necessiten proves diferents. O la regla nova queda després de una regla anterior que ja ha acceptat el paquet, o bé l'intercanvi que observeu és una connexió seguida que el canvi no torna a avaluar mai. Una regla en un fitxer expressa intenció; el que decideix el paquet és el camí actiu amb què es troba. Feu les comprovacions següents en ordre i manteniu una via de tornada mentre ho feu.

L'ordre de les regles i l'estat de la connexió són avaries diferents

Les cadenes ordenades s'avaluen de dalt a baix i la primera regla que arriba a un veredicte final acaba el recorregut per aquella cadena. Inseriu una acceptació àmplia per sobre d'una regla de bloqueig escrita amb cura i la regla de bloqueig esdevé documentació: és al conjunt de regles, té un comptador a zero i cap paquet no hi arribarà mai. El mateix text aplicat a una altra cadena tampoc no demostra res. A nftables, les cadenes base s'adjunten a hooks amb prioritats, així que una acceptació en una cadena no impedeix que una altra cadena en un hook o una prioritat diferents vegin el mateix paquet.

El seguiment de connexions produeix el segon símptoma i des de fora sembla idèntic. Un cop un flux és a la taula d'estats, una acceptació per a establert o relacionat a prop del capdamunt de la cadena retorna abans que es consulti la regla nova. Les conversions NAT tenen la mateixa propietat: la traducció es va fixar quan va començar el flux, així que una regla de postrouting editada no reescriu una sessió que ja funciona. Per això un canvi sembla funcionar a les 09:00 per a una connexió nova i sembla no fer res per a la sessió que algú va obrir a les 08:55.

Els grups de seguretat del núvol afegeixen un tercer model que enxampa qui va aprendre amb iptables. Les seves regles d'entrada són una llista d'autoritzacions avaluada com a conjunt i no com un recorregut de primera coincidència, són amb estat, i treure una regla d'autorització no acaba amb fluxos que ja es segueixen. Suposar semàntica de primera coincidència en una plataforma que no la té porta a conclusions segures i equivocades.

Llegiu el conjunt de regles actiu, no el fitxer que heu editat

Comenceu per allò que el nucli aplica ara mateix. Una configuració desada que mai no es va aplicar explica una quantitat sorprenent de comportaments inalterats, i descartar-ho costa una sola ordre:

nft list ruleset
iptables-save

Després pregunteu si la vostra regla s'assoleix de cap manera. Els comptadors de paquets responen això directament i ho responen millor que qualsevol raonament sobre la intenció:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Una regla de bloqueig amb zero paquets després d'un intent de prova real no és un problema de política, és un problema de posició. Moure-la és un canvi d'una línia, i la sintaxi és exactament el que va causar l'error original. Amb iptables, -I insereix i -A afegeix al final; amb nftables, insert col·loca una regla al començament de la cadena mentre que add afegeix al final. Quan una regla ha de guanyar, digueu-ho explícitament en lloc de confiar en l'ordre que es va carregar per casualitat.

Demostreu si el flux se segueix

Abans de culpar la regla, comproveu si el trànsit és del tot una connexió seguida. Demaneu a la taula d'estats el flux concret en lloc d'abocar-la sencera:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

El llistat mostra l'estat i el temps d'espera restant, i així és com distingiu una sessió establerta d'un intent nou; el mode d'esdeveniments imprimeix les actualitzacions a mesura que passen, cosa útil mentre torneu a connectar un client. Si el flux hi és amb estat establert abans que toquéssiu res, cap edició de les regles de filtratge no canviarà el seu destí. Això no és un error del tallafoc, és el contracte del filtratge amb estat.

Resistiu la drecera de buidar tota la taula en una passarel·la de producció. conntrack -F està disponible i també destrueix cada flux seguit de la màquina, inclosa la sessió de gestió des de la qual treballeu i el túnel que porta la vostra consola. Les entrades individuals es poden esborrar quan realment cal, però un flux nou des d'un port d'origen nou sol ser un experiment més net.

Alguns camins no se segueixen i es comporten a l'inrevés. El trànsit marcat com a notrack a la taula raw, alguns túnels que eviten els hooks normals i l'encaminament asimètric que parteix un flux entre dues passarel·les produeixen paquets avaluats d'un en un, o un estat que mai no es crea als dos extrems. Si els comptadors es mouen per a cada paquet, sospiteu d'aquest tipus de camí abans de sospitar de l'ordre.

Proveu des d'un flux nou amb una via de tornada

Abans de provar una regla que podria tallar l'accés remot, establiu una via de recuperació: la consola del proveïdor, una consola sèrie, una adreça de gestió fora de banda o una segona interfície que la regla no pugui coincidir. Un temporitzador de reversió és un bon company, ja que restaurarà el conjunt de regles anterior encara que la vostra sessió mori a mig test.

Després proveu amb un intercanvi que l'estat no hagués pogut cobrir ja. Desconnecteu i torneu a connectar el client perquè es creï una cinca nova, i observeu els dos extrems mentre passa:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Feu la prova en tots dos sentits. Una regla que bloqueja el nou handshake d'entrada encara pot permetre el camí de resposta, o al revés, i un resultat unidireccional és la raó habitual perquè un bloqueig funcioni a mitges. Torneu a connectar un cop després de la prova per confirmar l'estat estacionari i comproveu que l'accés de gestió legítim ha sobreviscut; una regla escrita per coincidir amb un port té el costum de coincidir amb un rang més ampli del previst.

Registreu la finalitat i la posició amb la regla

Una regla sense una finalitat registrada és una regla que ningú no gosa eliminar. Al costat de cada entrada de bloqueig, guardeu el flux que protegeix, la cadena i el hook on viu, la posició que ha de mantenir respecte de les acceptacions més àmplies i la prova que ho va demostrar. Quan algú editi el conjunt de regles del voltant sis mesos després, aquella nota és l'únic avís que la posició era deliberada.

Abans de tancar el canvi, confirmeu quatre coses: el conjunt de regles en execució coincideix amb el fitxer, la regla nova té comptadors diferents de zero després d'un intent nou, el sentit invers i l'accés de gestió encara funcionen, i us heu tornat a connectar un cop per demostrar l'estat estacionari i no l'estat d'una sessió anterior al canvi. Si alguna d'aquestes coses no està verificada, el canvi no està acabat, faci el que faci el túnel.