VPN de sitio a sitio: ¿qué dirección necesita realmente una regla?

Ambos extremos informan de un túnel establecido, la sucursal remota responde desde la puerta de enlace y la aplicación sigue agotando el tiempo para los usuarios de un lado. El consejo habitual dice que hay que añadir una regla de cortafuegos en ambas direcciones. A veces es correcto, a veces duplica una regla que ya existe y a veces la segunda regla es la que rompe el estado. Qué caso se aplica depende de dónde vea el paquete el cortafuegos.

El tráfico de retorno con estado cambia el recuento

Un cortafuegos con estado registra la solicitud y admite la respuesta sin una segunda regla, así que un diseño que solo necesita una regla es normal. Una lista de acceso sin estado no tiene esa memoria, y la respuesta debe permitirse explícitamente. Ambos son correctos en su propia plataforma, y por eso los consejos se contradicen.

Lea la documentación de reenvío de la plataforma que tiene delante y compruebe si la política que está editando tiene estado donde ve el paquete. Una denegación explícita para el tráfico establecido, o un orden de reglas que evalúa la respuesta antes de la tabla de estados, convierte un diseño funcional en uno desconcertante. El número de reglas es un detalle de implementación, mientras que el requisito es que ambas direcciones de una conversación permitida puedan completarse.

Dónde ve el cortafuegos los paquetes descifrados

En un túnel basado en políticas, el cortafuegos puede evaluar el paquete cifrado antes del descifrado y el paquete descifrado después, en interfaces diferentes. Una regla escrita para la interfaz equivocada está presente, es correcta y nunca coincide. Así es como un conjunto de reglas copiado de un despliegue funcional puede fallar en hardware idéntico.

El IPsec basado en rutas y la mayoría de las implementaciones modernas presentan una interfaz de túnel, de modo que el paquete descifrado llega allí y se aplican las reglas de interfaz habituales. Confirme qué modelo usa el despliegue antes de copiar un conjunto de reglas de una guía escrita para el otro. La interfaz de túnel también es el lugar donde mirar cuando necesita saber si un paquete se descifró siquiera.

El enrutamiento asimétrico rompe la suposición

Un cortafuegos con estado supone que ve ambas mitades de la conversación. Si la respuesta vuelve por otra puerta de enlace, ese dispositivo no mantiene estado para la solicitud y la descarta según su propia política. El síntoma es un fallo unidireccional que ninguna regla del lado emisor puede reparar. Siga la ruta de la respuesta antes de editar nada.

Compruebe la ruta de la respuesta antes de añadir una regla amplia de permiso en ambos lados. Tolerarlo todo en cada interfaz oculta el error de enrutamiento y amplía el acceso al mismo tiempo, que es la peor combinación disponible.

Compruebe ambas direcciones con direcciones de origen reales

Pruebe con la dirección que el lado remoto observa realmente, ya que la traducción puede hacer que una regla de origen no coincida con nada. Ejecute la captura en ambas puertas de enlace al mismo tiempo.

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 solicitud que aparece en la puerta de enlace remota con una dirección de origen inesperada explica una regla que nunca coincide, y una respuesta que llega a la interfaz equivocada explica un desajuste de estado. Luego pruebe un destino dentro del alcance aprobado y otro fuera, para que el límite se demuestre en lugar de suponerse.

Registre la dirección de origen después de la traducción, la interfaz que utilizó el paquete descifrado y la regla que coincidió. Esos tres hechos responden al siguiente ticket sin repetir toda la investigación.