VPN de lloc a lloc: quina direcció necessita realment una regla?

Els dos extrems informen d'un túnel establert, la branca remota respon des de la passarel·la i l'aplicació continua esgotant el temps per als usuaris d'un costat. El consell habitual diu d'afegir una regla de tallafoc en totes dues direccions. De vegades és correcte, de vegades duplica una regla que ja existeix i de vegades la segona regla és la que trenca l'estat. Quin cas s'aplica depèn d'on veu el paquet el tallafoc.

El trànsit de retorn amb estat canvia el recompte

Un tallafoc amb estat enregistra la petició i admet la resposta sense una segona regla, així que un disseny que només necessita una regla és normal. Una llista d'accés sense estat no té aquesta memòria, i la resposta s'ha de permetre explícitament. Tots dos són correctes a la seva pròpia plataforma, i per això el consell entra en conflicte.

Llegiu la documentació d'encaminament de la plataforma que teniu davant i comproveu si la política que editeu té estat on veu el paquet. Una denegació explícita per al trànsit establert, o un ordre de regles que avalua la resposta abans de la taula d'estats, converteix un disseny funcional en un d'embrollat. El nombre de regles és un detall d'implementació, mentre que el requisit és que les dues direccions d'una conversa permesa es puguin completar.

On el tallafoc veu els paquets desxifrats

En un túnel basat en polítiques, el tallafoc pot avaluar el paquet xifrat abans del desxifrat i el paquet desxifrat després, en interfícies diferents. Una regla escrita per a la interfície equivocada hi és, és correcta i no coincideix mai. Així és com un conjunt de regles copiat d'un desplegament funcional pot fallar en maquinari idèntic.

L'IPsec basat en encaminament i la majoria d'implementacions modernes presenten una interfície de túnel, de manera que el paquet desxifrat arriba allà i s'apliquen les regles normals d'interfície. Confirmeu quin model fa servir el desplegament abans de copiar un conjunt de regles d'una guia escrita per a l'altre. La interfície de túnel també és el lloc on mirar quan necessiteu saber si un paquet s'ha desxifrat o no.

L'encaminament asimètric trenca la suposició

Un tallafoc amb estat assumeix que veu les dues meitats de la conversa. Si la resposta torna per una altra passarel·la, aquell dispositiu no té estat per a la petició i la descarta segons la seva pròpia política. El símptoma és una fallada unidireccional que cap regla del costat emissor pot reparar. Seguiu el camí de la resposta abans de editar res.

Comproveu la ruta de la resposta abans d'afegir una regla àmplia de permetre als dos costats. Tolerar-ho tot a cada interfície amaga l'error d'encaminament i amplia l'accés alhora, que és la pitjor combinació disponible.

Comproveu les dues direccions amb adreces d'origen reals

Proveu amb l'adreça que el costat remot observa realment, ja que la traducció pot fer que una regla d'origen no coincideixi amb res. Executeu la captura a les dues passarel·les alhora.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Una petició que apareix a la passarel·la remota amb una adreça d'origen inesperada explica una regla que no coincideix mai, i una resposta que arriba a la interfície equivocada explica un desajust d'estat. Després proveu una destinació dins de l'abast aprovat i una de fora, perquè el límit es demostri en lloc de suposar-se.

Anoteu l'adreça d'origen després de la traducció, la interfície que va fer servir el paquet desxifrat i la regla que va coincidir. Aquests tres fets responen el proper tiquet sense repetir tota la investigació.