Tras el descifrado: qué política ve primero tu tráfico VPN

Un flujo VPN puede estar perfectamente cifrado y perfectamente autenticado y aun así terminar donde nadie lo planeó. El cable que conectas no determina qué regla procesa el paquete interno; lo hacen el gancho de política y la ruta. Por eso dos diseños que parecen idénticos en un diagrama de rack pueden tener una aplicación completamente distinta. Elegir entre ellos empieza por nombrar el control que ve primero el flujo descifrado.

Decide por el gancho de política, no por el puerto

Cada plataforma VPN evalúa el tráfico descifrado en algún punto antes de reenviarlo, y ese punto tiene un nombre en la configuración. En una plataforma es un filtro de política de grupo, en otra una política de interfaz o un par de zonas, y en un dispositivo que enruta puede ser simplemente la cadena forward. El gancho es lo que aplica la regla, mientras que el puerto del conmutador es solo donde termina el cable. Encontrar el gancho es la primera decisión, porque todo lo demás es colocación respecto a él.

Antes de mirar hardware, escribe el flujo: quién es el origen, a dónde va, qué protocolo lo transporta y qué servicio está permitido. Luego encuentra el control que aplica cada uno de esos cuatro hechos.

Dos rutas, dos historias de aplicación distintas

Dos formas son comunes y cada una puede ser correcta para un requisito distinto.

endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnet

La primera forma puede aplicar todo lo necesario en la puerta de enlace, siempre que la política esté escrita para ese destino y el servidor no tenga una ruta que la rodee. La segunda añade una frontera, pero solo si las rutas y la política hacen que el tráfico la atraviese de verdad. Un servidor en el mismo segmento que el punto final puede no seguir nunca el salto intermedio imaginado. El diagrama muestra la intención y la tabla de rutas muestra qué ocurre.

Verifica con una consulta de ruta y no con el dibujo. La interfaz por la que sale un paquete y el siguiente salto que elige deciden si la segunda forma se comporta como se diseñó.

ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20

Separa la topología del aislamiento

Compartir una subred no hace que un lugar sea poco fiable, y un tránsito dedicado no lo hace protegido. Lo que decide es la restricción realmente aplicada, el reenvío que realmente ocurre y quién administra cada pieza. Contar conmutadores no dice nada sobre ninguno de los tres. Decide desde la política y la ruta, y deja que la topología siga la decisión.

Trata también las poblaciones de tráfico por separado. Los grupos de acceso remoto, los prefijos sitio a sitio y las redes de línea privada pueden compartir un dispositivo y necesitar reglas distintas, porque su identidad y su riesgo difieren. Una regla escrita para una población cubre en silencio a las demás cuando comparten un plan de direcciones.

Comprueba fallo y gestión en cada ubicación

Cada ubicación tiene un modo de fallo, y la pregunta útil es qué sigue funcionando cuando un componente se detiene. Varias interfaces lógicas en un solo equipo muerto no dan recuperación independiente, y un cortafuegos posterior que comparte la misma alimentación o el mismo administrador no es una segunda frontera. Pregunta por dónde pasa la ruta de gestión, porque una consola accesible solo por el túnel no es ninguna ruta de recuperación; ssh [email protected] true desde fuera del túnel es la forma más barata de demostrar que la consola no depende de él. La documentación de política de grupo de una plataforma coloca su filtro en tráfico posterior al descifrado y previo al cifrado, que es exactamente el tipo de gancho nombrado que hay que buscar en cualquier producto.

Escribe la historia de fallo de cada candidato junto a la historia de aplicación. Una ubicación que gana en inspección y pierde en recuperación es un intercambio, y debe registrarse como tal en lugar de descubrirse durante un incidente.

Acepta con un flujo permitido y uno denegado

Con un plan de pruebas aprobado, comprueba tres cosas desde el origen VPN real: una aplicación que debería funcionar, un recurso que no debería, y la dirección por la que vuelve la respuesta. La denegación es la evidencia de que la política está activa, mientras que el flujo permitido solo demuestra que existe un camino.

Conserva la ruta elegida y el resultado de la política juntos, porque un resultado sin ruta no se puede reproducir y una ruta sin resultado no se puede defender. Ese par es mucho más útil para elegir un punto de conexión que cualquier afirmación sobre qué capa de conmutación es intrínsecamente más segura.