Dois túneis IPsec ativos ainda precisam de um plano de caminho de volta

Abra um terminal numa estação de trabalho de um site e ligue-se a um servidor do outro. Essa única conversa TCP agora tem de atravessar quatro gateways em vez de dois, e a parte interessante não é se funciona num dia bom. A parte interessante é qual par de gateways a direção de ida escolheu, qual par a resposta escolhe, e quem mantém o estado do fluxo enquanto isso acontece. Nada na tabela de rotas decide isso por si.

Desenhe quatro gateways antes de desenhar uma rota

Um desenho duplamente ativo com duas firewalls VPN independentes por site, um par por fornecedor, dá-lhe dois caminhos utilizáveis e três formas de os quebrar. Anote os endereços antes de configurar o que quer que seja: o cliente tal como é visto antes e depois de cada gateway, o servidor da mesma forma, o próximo salto de ida e o próximo salto de volta.

Essa tabela é o desenho. Tudo depois disso é uma questão de saber se os dispositivos concordam com a tabela.

Como o caminho de ida é escolhido

Uma camada de encaminhamento multipath de custo igual distribui os fluxos pelos próximos saltos através de hash dos campos do cabeçalho, o que RFC 2992 descreve em detalhe. Essa seleção pode ser totalmente sem estado: não precisa de qualquer entrada de rastreio de ligações, apenas de um hash estável sobre campos inalterados. Mantenha o conjunto de caminhos e as entradas do hash constantes e cada pacote do fluxo escolhe o mesmo próximo salto.

A seleção por fluxo evita a reordenação que o balanceamento pacote a pacote causaria em ligações com atrasos diferentes. Não promete que um custo de encaminhamento igual signifique uma latência medida igual, porque não significa. E quando a composição dos caminhos muda, os fluxos são remapeados, pelo que a sobrevivência da ligação durante uma falha é um requisito separado da seleção de caminho.

Do que o caminho de volta realmente precisa

Aqui o percurso deixa de ser simétrico. Um hash de ida estável não lhe diz nada sobre o que o site remoto fará com a resposta. Se uma firewall independente tiver de ver as duas direções da ligação para manter estado útil, uma rota de volta que a contorne deixa tráfego que não corresponde a nada. Duas caixas com conjuntos de regras semelhantes não são estado partilhado.

Confirme o comportamento bidirecional implementado, ou escreva uma política explícita que mantenha os limites necessários coerentes. Um palpite aqui é descoberto durante uma falha, por pessoas que não o estão a apreciar.

Onde a tradução decide por si

O NAT é a outra alavanca, e é opcional em vez de obrigatório. Identidades traduzidas específicas do caminho podem encaminhar as respostas de volta para o gateway que mantém o estado, o que é um desenho legítimo. Também acrescentam mapeamentos, rotas de volta e um proprietário desse estado, por isso aceite o fardo apenas por um requisito que consiga dizer em voz alta.

Se o requisito for simplesmente que ambos os caminhos transportem tráfego e que qualquer um sobreviva à perda de um fornecedor, o multipath por fluxo com encaminhamento de volta coerente é normalmente o desenho mais pequeno.

Percorra a aceitação por ordem

Teste nesta sequência e registe os endereços em cada passo: uma ligação nova no caminho A e o seu caminho de resposta, o mesmo no caminho B, depois a perda de um fornecedor, depois o restabelecimento. Para cada resultado, anote que fluxos estabelecidos se deslocaram, quais tiveram de se voltar a ligar e para onde foram os novos fluxos depois. Escreva primeiro o valor esperado e depois compare-o com a captura. Dois túneis estabelecidos não provam nada disso.

O desenho está concluído quando a tabela que escreveu corresponde ao que a captura mostra, não quando ambos os túneis estão de pé.