Gateway VPN combinado ou separado: escolha pelo domínio de falha

Dois equipamentos parecem mais resistentes do que um até notar que partilham a mesma régua de tomadas, o mesmo hipervisor e o mesmo link ascendente. Contar caixas responde a uma pergunta que ninguém fez; a pergunta útil é o que falha ao mesmo tempo. Escreva primeiro o contrato de falha e deixe-o escolher a topologia. O runbook abaixo produz esse registo.

O que para durante um reinício

Para um gateway combinado, liste o que desaparece durante um reinício, uma atualização falhada ou uma avaria de hardware. Se o acesso à internet e a conectividade privada param juntos, essa interrupção partilhada passa a fazer parte do seu requisito de disponibilidade, quer alguém a tenha escrito ou não. O mesmo exercício aplica-se a um único equipamento que termina vários papéis: a lista de serviços que ele derruba é a especificação real.

Para gateways separados, liste o que permanece partilhado: a energia, o anfitrião de virtualização, o link ascendente, o fornecedor de identidade, a rede de gestão. Dois equipamentos atrás de um switch avariado são um único domínio de falha com dois nomes de anfitrião. Uma separação que ignora essas dependências é um diagrama, não um desenho.

Conte também a propriedade da manutenção. Outro equipamento traz configuração, monitorização, cópias de segurança e um segundo procedimento de recuperação, e nada disso é gratuito.

Marque onde cada regra é aplicada

Siga um pacote do cliente até um recurso privado e de volta, e marque cada local onde é aplicada uma política. Um segundo router acrescenta outro ponto onde a preferência de rota, a tradução ou o estado da ligação podem discordar do primeiro. A maioria das falhas misteriosas num desenho de dois gateways vive nessa costura.

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

Anote onde termina a proteção VPN e onde começa a política interna. Se o caminho entre os dois equipamentos for permissivo, a segunda caixa não criou uma fronteira; apenas moveu o local onde uma fronteira poderia estar. Numa única plataforma, zonas de política distintas ainda podem ser eficazes, e a sua eficácia deve ser avaliada pelas regras em vez de descartada por o hardware ser partilhado.

Pare se não conseguir dizer qual equipamento aplica a regra que importa. Essa lacuna é o achado, não um detalhe a resolver mais tarde.

A contenção é uma fronteira, não um chassis

Um equipamento separado contém um compromisso apenas quando o caminho através dele está limitado ao que o outro lado precisa. Se ambos os equipamentos aceitam qualquer tráfego um do outro, um atacante que aterra num deles tem o mesmo alcance de antes. A afirmação de contenção pertence ao conjunto de regras, não ao inventário. Leia as regras, diga quais fluxos são permitidos e depois decida se a separação comprou alguma coisa.

A mesma lógica aplica-se aos utilizadores. Um utilizador de VPN em quem se confia pela rede de onde veio está a confiar na localização em vez da identidade, e as orientações NIST de confiança zero descrevem a alternativa: autenticar e autorizar cada pedido contra o recurso. Esse princípio mantém-se seja qual for o chassis que termina o túnel.

Se a separação existe para satisfazer uma linha de conformidade em vez de mudar um fluxo, diga-o no registo. Um controlo que ninguém consegue explicar é o primeiro a ser retirado sob pressão.

Recupere o que consegue realmente alcançar

Pergunte que caminho de recuperação sobrevive quando qualquer dos dois papéis morre. Quando a única forma de chegar a um gateway VPN avariado passa por esse gateway, um equipamento sobressalente noutro local não ajuda o administrador que tem de o reparar. Um caminho fora de banda, uma consola e um retrocesso documentado são as peças que tornam o desenho recuperável.

systemctl status strongswan
nft list ruleset
ip -brief address

Dimensione o desenho para a carga de trabalho completa suportada e não para um número de cifra isolado, porque a filtragem e a inspeção consomem o mesmo hardware. Use a documentação do fornecedor e as suas próprias medições em vez de assumir que a separação é mais rápida ou mais lenta. Depois escreva o registo de decisão: que fluxos são permitidos, que dependências são partilhadas, o que derruba uma janela de manutenção, que provas de capacidade tem e quem é dono de cada passo de recuperação. Esse registo é suficientemente curto para rever e suficientemente específico para revisitar.

O runbook termina quando o contrato de falha está escrito, o caminho de encaminhamento tem um ponto de aplicação nomeado por regra, a contenção é descrita por fluxos e não pelo número de equipamentos, e a recuperação funciona a partir de fora do componente avariado. Escolha a disposição mais simples que cumpra esses requisitos.