Pasarela VPN combinada ou separada: escolla por dominio de fallo

Dous equipos parecen máis resistentes ca un ata que advirte que comparten a mesma regleta, o mesmo hipervisor e a mesma ligazón ascendente. Contar caixas responde unha pregunta que ninguén fixo; a pregunta útil é que falla ao mesmo tempo. Escriba primeiro o contrato de fallo e deixe que elixa a topoloxía. O runbook seguinte produce ese rexistro.

Que se detén durante un reinicio

Para unha pasarela combinada, enumere que desaparece durante un reinicio, unha actualización fallida ou unha avaría de hardware. Se o acceso a internet e a conectividade privada se deteñen xuntos, esa interrupción compartida xa forma parte do seu requisito de dispoñibilidade, tanto se alguén o escribiu como se non. O mesmo exercicio se aplica a un só equipo que remata varios roles: a lista de servizos que bota é a especificación real.

Para pasarelas separadas, enumere que segue compartido: a enerxía, o host de virtualización, a ligazón ascendente, o provedor de identidade, a rede de xestión. Dous equipos detrás dun conmutador fallido son un só dominio de fallo con dous nomes de host. Unha separación que ignora esas dependencias é un diagrama, non un deseño.

Conte tamén a propiedade do mantemento. Outro equipo achega configuración, monitorización, copias de seguridade e un segundo procedemento de recuperación, e nada diso é gratuíto.

Marque onde se aplica cada regra

Segua un paquete desde o cliente ata un recurso privado e de volta, e marque cada lugar onde se aplica unha política. Un segundo encamiñador engade outro punto onde a preferencia de ruta, a tradución ou o estado de conexión poden discrepar do primeiro. A maioría das fallas misteriosas nun deseño de dúas pasarelas viven nesa costura.

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

Anote onde remata a protección VPN e onde comeza a política interna. Se o camiño entre os dous equipos é permisivo, a segunda caixa non creou unha fronteira; só moveu o lugar onde unha fronteira podería ter estado. Nunha soa plataforma, as zonas de política distintas aínda poden ser eficaces, e a súa eficacia debe avaliarse segundo as regras, non descartarse porque o hardware sexa compartido.

Détase se non pode dicir que equipo aplica a regra que importa. Esa fenda é o achado, non un detalle que resolver despois.

A contención é unha fronteira, non un chasis

Un equipo separado contén un compromiso só cando o camiño a través del se limita ao que a outra parte necesita. Se ambos os equipos aceptan calquera tráfico do outro, un atacante que aterra nun ten o mesmo alcance que antes. A afirmación de contención pertence ao conxunto de regras, non ao inventario. Lea as regras, diga que fluxos están permitidos e logo decida se a separación comprou algo.

A mesma lóxica se aplica aos usuarios. Un usuario de VPN en quen se confía pola rede da que chegou confía na localización en lugar da identidade, e a guía de confianza cero de NIST describe a alternativa: autenticar e autorizar cada solicitude contra o recurso. Ese principio mantense calquera que sexa o chasis que remate o túnel.

Se a separación existe para satisfacer unha liña de cumprimento en lugar de para cambiar un fluxo, dígao no rexistro. Un control que ninguén pode explicar é o primeiro que se retira baixo presión.

Recupere o que realmente pode alcanzar

Pregunte que camiño de recuperación sobrevive cando morre calquera dos dous roles. Cando a única forma de chegar a unha pasarela VPN rota pasa por esa pasarela, un equipo de reposto noutro lugar non axuda ao administrador que debe arranxala. Un camiño fóra de banda, unha consola e un retorno documentado son as pezas que fan recuperable o deseño.

systemctl status strongswan
nft list ruleset
ip -brief address

Dimensione o deseño para a carga de traballo completa admitida e non para un número de cifrado illado, porque o filtrado e a inspección consomen o mesmo hardware. Use a documentación do provedor e as súas propias medicións en lugar de supoñer que a separación é máis rápida ou máis lenta. Despois escriba o rexistro de decisión: que fluxos están permitidos, que dependencias son compartidas, que bota unha ventá de mantemento, que probas de capacidade ten e quen é dono de cada paso de recuperación. Ese rexistro é o bastante curto para revisalo e o bastante concreto para volver a el.

O runbook remata cando o contrato de fallo está escrito, o camiño de reenvío ten un punto de aplicación nomeado por regra, a contención se describe con fluxos e non co número de equipos, e a recuperación funciona desde fóra do compoñente fallido. Escolla a disposición máis simple que cumpra eses requisitos.