Pasarela VPN combinada o separada: elija por dominio de fallo

Dos equipos parecen más resistentes que uno hasta que advierte que comparten la misma regleta, el mismo hipervisor y el mismo enlace ascendente. Contar cajas responde una pregunta que nadie hizo; la pregunta útil es qué falla al mismo tiempo. Escriba primero el contrato de fallo y deje que elija la topología. El runbook siguiente produce ese registro.

Qué se detiene durante un reinicio

Para una pasarela combinada, enumere qué desaparece durante un reinicio, una actualización fallida o una avería de hardware. Si el acceso a internet y la conectividad privada se detienen juntos, esa interrupción compartida ya forma parte de su requisito de disponibilidad, tanto si alguien lo escribió como si no. El mismo ejercicio se aplica a un solo equipo que termina varios roles: la lista de servicios que tumba es la especificación real.

Para pasarelas separadas, enumere qué sigue compartido: la energía, el host de virtualización, el enlace ascendente, el proveedor de identidad, la red de gestión. Dos equipos detrás de un conmutador fallido son un solo dominio de fallo con dos nombres de host. Una separación que ignora esas dependencias es un diagrama, no un diseño.

Cuente también la propiedad del mantenimiento. Otro equipo aporta configuración, monitorización, copias de seguridad y un segundo procedimiento de recuperación, y nada de eso es gratis.

Marque dónde se aplica cada regla

Siga un paquete desde el cliente hasta un recurso privado y de vuelta, y marque cada lugar donde se aplica una política. Un segundo enrutador añade otro punto donde la preferencia de ruta, la traducción o el estado de conexión pueden discrepar del primero. La mayoría de las fallas misteriosas en un diseño de dos pasarelas viven en esa costura.

ip route get 10.20.30.40
traceroute -n 10.20.30.40
conntrack -L -p tcp --dport 443

Anote dónde termina la protección VPN y dónde empieza la política interna. Si el camino entre los dos equipos es permisivo, la segunda caja no ha creado una frontera; solo ha movido el lugar donde una frontera podría haber estado. En una sola plataforma, las zonas de política distintas aún pueden ser eficaces, y su eficacia debe evaluarse según las reglas, no descartarse porque el hardware sea compartido.

Deténgase si no puede decir qué equipo aplica la regla que importa. Esa brecha es el hallazgo, no un detalle que resolver después.

La contención es una frontera, no un chasis

Un equipo separado contiene un compromiso solo cuando el camino a través de él se limita a lo que la otra parte necesita. Si ambos equipos aceptan cualquier tráfico del otro, un atacante que aterriza en uno tiene el mismo alcance que antes. La afirmación de contención pertenece al conjunto de reglas, no al inventario. Lea las reglas, diga qué flujos están permitidos y luego decida si la separación compró algo.

La misma lógica se aplica a los usuarios. Un usuario de VPN en quien se confía por la red de la que llegó confía en la ubicación en lugar de la identidad, y la guía de confianza cero de NIST describe la alternativa: autenticar y autorizar cada solicitud contra el recurso. Ese principio se mantiene sea cual sea el chasis que termine el túnel.

Si la separación existe para satisfacer una línea de cumplimiento en lugar de para cambiar un flujo, dígalo en el registro. Un control que nadie puede explicar es el primero que se retira bajo presión.

Recupere lo que realmente puede alcanzar

Pregunte qué camino de recuperación sobrevive cuando muere cualquiera de los dos roles. Cuando la única forma de llegar a una pasarela VPN rota pasa por esa pasarela, un equipo de repuesto en otro lugar no ayuda al administrador que debe arreglarla. Un camino fuera de banda, una consola y un retorno documentado son las piezas que hacen recuperable el diseño.

systemctl status strongswan
nft list ruleset
ip -brief address

Dimensione el diseño para la carga de trabajo completa admitida y no para un número de cifrado aislado, porque el filtrado y la inspección consumen el mismo hardware. Use la documentación del proveedor y sus propias mediciones en lugar de suponer que la separación es más rápida o más lenta. Luego escriba el registro de decisión: qué flujos están permitidos, qué dependencias son compartidas, qué tumba una ventana de mantenimiento, qué pruebas de capacidad tiene y quién es dueño de cada paso de recuperación. Ese registro es lo bastante corto para revisarlo y lo bastante concreto para volver a él.

El runbook termina cuando el contrato de fallo está escrito, el camino de reenvío tiene un punto de aplicación nombrado por regla, la contención se describe con flujos y no con el número de equipos, y la recuperación funciona desde fuera del componente fallido. Elija la disposición más simple que cumpla esos requisitos.