Per què nftables no veu el trànsit entre clients d'OpenVPN

Dos clients en un mateix servidor intercanvien fitxers, la transferència té èxit i cada regla de reenviament que apunteu al túnel informa de zero paquets. Les regles no estan trencades i la cadena no és fora de lloc. Amb el reenviament entre iguals activat, el paquet es lliura dins del procés del servidor i la pila de l'amfitrió no esdevé mai l'encaminador, així que el tallafoc del nucli no té res a comptar. Entendre aquesta separació decideix si manteniu la drecera o reconstruïu el camí a través del nucli.

Seguiu un paquet a través del servidor

En un túnel encaminat, el dimoni lliura el paquet desxifrat de cada client al dispositiu de túnel. Des d'allà l'amfitrió l'encamina, s'executa el ganxo de reenviament i una regla que coincideixi amb el dispositiu de túnel pot comptar o descartar el trànsit. Aquest és el camí que assumeixen la majoria d'exemples de tallafoc.

La drecera treu l'amfitrió del mig. El paquet desxifrat d'una sessió es lliura a una altra sessió dins del dimoni, i el paquet intern no s'emet mai al dispositiu de túnel ni l'encamina l'amfitrió. El trànsit encapsulat encara travessa la interfície física, així que una captura externa sembla ocupada mentre les regles internes callen. Una captura feta al dispositiu de túnel no mostra absolutament res, cosa que sorprèn qui espera veure-hi la transferència. Aquesta asimetria és la manera més ràpida de reconèixer la drecera des de fora del dimoni.

La prova del comptador que decideix quin camí es va fer servir

Adjunteu un comptador a la regla que hauria d'aplicar-se, executeu una transferència entre dos clients que aquesta regla hauria de blocar i llegiu el comptador després.

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

Si la transferència té èxit i el comptador es queda a zero, el nucli no va gestionar mai aquests paquets, i cap quantitat d'edició de regles ho canviarà. Repetiu la mateixa prova contra un servei del mateix servidor, perquè aquest flux sí que travessa la pila de l'amfitrió i el seu comptador es mou. Comparar els dos resultats és el que dona la resposta.

Dos detalls eviten una lectura falsa. Un nom d'interfície escrit en una etiqueta de cadena no filtra res per si sol, perquè la coincidència es fa als camps d'interfície dins de les regles. I un disseny pont de capa 2 es comporta encara d'una altra manera: allà els clients comparteixen un domini de difusió, així que la descoberta d'iguals és esperada i no una fallada d'encaminament.

Un commutador no és una llista d'accés

Aquesta és la part que costa una tarda. El reenviament entre iguals és un sol paràmetre d'engegat o apagat, i mentre és engegat el dimoni és l'únic punt de reenviament. El tallafoc de l'amfitrió no pot expressar qui pot arribar a qui, i els fitxers per client no converteixen el commutador en una matriu de polítiques.

Si necessiteu regles per igual, l'elecció és entre renunciar a la drecera i renunciar al tallafoc de l'amfitrió com a control. Apagar-lo restaura el reenviament del nucli, que requereix reenviament IP al servidor i regles explícites per als fluxos que voleu. Mantenir-lo engegat vol dir que la política viu a la configuració del dimoni, que a la pràctica és tots els iguals o cap.

Processos de servidor separats amb les seves pròpies reserves d'adreces i ports són el punt mitjà viable. Cada procés porta exactament una decisió d'accés, així que dos grups poden tenir regles diferents sense una matriu de polítiques. L'amfitrió pot encaminar entre les reserves quan és el que es vol, i llavors el tallafoc veu aquests fluxos perquè travessen l'amfitrió. El cost són ports extra, certificats extra i un perfil per grup.

Triar el punt de reenviament

Trieu el reenviament del nucli quan el tallafoc és el motor de política, quan necessiteu registre per flux o quan la comptabilitat importa. El cost és el cabal a través de la pila de l'amfitrió i més regles per mantenir. El benefici és que cada eina existent, dels comptadors als exportadors de fluxos, torna a descriure el trànsit. En un servidor petit aquest cost és invisible; en un repetidor ocupat no ho és.

Trieu el reenviament dins del procés quan el trànsit entre iguals és o tot permès o tot denegat i el servidor està dimensionat per a això. El cost és que els comptadors, les disciplines de cua i el seguiment de connexions ja no descriuen els fluxos interns; això només és acceptable si després ningú no hi confia.

Triï el que triï, escriviu-ho al costat de les regles del tallafoc. Un conjunt de regles que sembla permetre el trànsit entre iguals mentre el dimoni decideix igualment enganya la propera persona que depuri una transferència fallida. Qui només llegeixi les regles assumirà que el nucli és la porta.

Què comprovar abans de canviar regles

Llegiu la configuració que el servidor ha carregat realment, no el fitxer que recordeu haver editat, i confirmeu si l'opció d'iguals hi és. Si l'heu canviada, assegureu-vos que el servei s'ha recarregat i no només ha reescrit un fitxer al disc.

Després repetiu la prova amb un flux de client a servidor per demostrar que la regla coincideix com a mínim, i reviseu les rutes enviades, perquè una ruta que falta sembla exactament un blocatge del tallafoc des del costat del client. Canvieu l'ordre de les regles només quan sapigueu quin punt de reenviament posseeix la decisió.