Tráfico del cliente VPN y estado del cortafuegos: flujo externo frente a interno

El saludo VPN se completa, el cliente obtiene una dirección y un servicio detrás de la puerta de enlace sigue rechazando la conexión. El cortafuegos suele hacer exactamente lo que se le dijo. Permitió el flujo externo del túnel, que es un paquete distinto de la conexión de aplicación desencapsulada. De ahí se siguen dos decisiones: qué flujo permite y si la frontera sigue el estado o no.

Hasta que separe esas dos cosas, cada cambio de regla es una conjetura.

El cortafuegos ve dos paquetes distintos

Antes de la desencapsulación, el cortafuegos ve tráfico dirigido al extremo VPN: un flujo UDP externo hacia el escucha. Después de la desencapsulación, un paquete reenviado lleva la dirección interna del cliente y el destino del servicio.

Un permiso para el flujo externo no autoriza la conexión TCP reenviada. Se pueden evaluar en cadenas distintas, contra interfaces distintas y con direcciones distintas tras la traducción.

Compare capturas desde posiciones equivalentes en ambos lados. Una captura en el borde del túnel y una captura en el servidor muestran tuplas distintas para la misma sesión.

Primera decisión: permitir el túnel o el servicio

Si el cliente solo necesita el extremo VPN en sí, el permiso externo puede bastar. Si necesita un servicio más allá de la puerta de enlace, hace falta un permiso de reenvío para ese destino y puerto. Una regla de túnel que también permite el servicio es una decisión de diseño que debería nombrar, no un accidente.

Mantenga estrechos el rango del cliente y el alcance del servicio. Un permiso de la subred del túnel a toda la LAN es una decisión de confiar en cada equipo, no un atajo para una aplicación.

Escriba las dos reglas por separado. La regla del túnel y la regla del servicio fallan de maneras distintas y se depuran con pruebas distintas. Cuando una falla, sabe qué capa inspeccionar primero.

Segunda decisión: con estado o sin estado en cada frontera

Una regla de flujo establecido puede admitir respuestas para un intercambio permitido, pero su comportamiento depende del producto. Un grupo de seguridad en la nube suele tener estado; una lista de control de subred a menudo no lo tiene y necesita un tratamiento explícito en ambas direcciones. No suponga que cada frontera del camino trata el estado igual. Enumere cada frontera y márquela con estado o sin estado antes de diseñar las reglas.

Si cambia una regla, los flujos rastreados existentes pueden seguir funcionando mientras los nuevos fallan, o al revés. Esa diferencia es una pista útil, no una razón para vaciar todo el estado de conexión en una puerta de enlace en producción.

Pruebe con una petición nueva y controlada y inspeccione los contadores relevantes. Una prueba limpia supera a un reinicio perturbador. Anote el nombre del contador en el registro del cambio para que la siguiente prueba use la misma evidencia.

Verifique el camino de vuelta con la misma política

Envíe una petición nueva del cliente al servicio y luego revise los contadores de ida y de vuelta en cada frontera. Confirme que la respuesta usa el camino que espera, sobre todo si hay traducción de por medio.

Mantenga estrechos el rango de cliente previsto y el alcance del servicio, y verifique el camino de vuelta con el mismo conjunto de reglas que permitió la petición. Una regla que solo funciona porque un flujo antiguo sigue abierto no es una regla que funcione.