IPsec dentro de IPsec: quais endereços o túnel externo deve transportar

O IPsec aninhado é mais fácil de raciocinar quando as duas camadas terminam em máquinas diferentes. Quatro gateways, dois túneis e uma única pergunta que decide se o desenho funciona: o que o túnel externo realmente vê quando o interno termina com o pacote? Responda a isso e os seletores, as rotas e a ordem de resolução de problemas seguem. Erre e passará um dia depurando um túnel que está tecnicamente ativo.

O modelo de quatro gateways

Os gateways externos A e B constroem o primeiro túnel entre os dois locais. Atrás de A está o gateway interno C com endereço de trânsito 10.60.0.2; atrás de B está o gateway interno D com endereço de trânsito 10.70.0.2. As redes de aplicações vivem atrás de C e D, e cada endereço do exemplo é deliberadamente não sobreposto.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Dividir as camadas por quatro hosts significa que cada máquina impõe uma fronteira. Um único host executando as duas camadas precisa conciliar dois conjuntos de políticas, duas tabelas de rotas e dois modos de falha numa só máquina, o que é possível e muito mais difícil de observar.

Cada camada remove apenas a sua própria proteção

C cifra um pacote de aplicação para D. O resultado é endereçado de C para D, e é isso que chega a A. Tudo a jusante depende dessa reescrita.

A volta a cifrá-lo para B. B decifra a camada externa, vê um pacote de C para D e encaminha-o ainda cifrado. D remove a proteção interna e entrega o pacote de aplicação.

Assim, A e B veem os pontos finais internos e os seus metadados, mas não são as partes que decifram a carga útil da aplicação. Isso é uma propriedade real do desenho e não uma afirmação de que C, D ou os hosts de aplicações sejam confiáveis.

Os seletores externos nomeiam os gateways internos

É aqui que a maioria destas construções falha. Para um túnel externo baseado em políticas, os seletores que negoceia devem conter os endereços que A e B realmente tratam: 10.60.0.2/32 e 10.70.0.2/32, na ordem local e remota correta.

Colocar as sub-redes finais das aplicações nos seletores externos não funciona, porque quando um pacote chega a A, a encapsulação interna já reescreveu o que A deve proteger. A política externa então não corresponderia a nada, e o túnel subiria sem transportar dados.

Não restrinja a permissão externa a UDP 500. A ligação interna tem o seu próprio caminho de dados, que usa ESP ou encapsulação UDP conforme o que foi negociado, e a política externa tem de permitir esse protocolo.

Verifique o resultado com swanctl --list-sas em cada gateway e confirme que as associações de segurança filhas relatam os endereços que pretendia, não os que supôs. Se a lista mostrar as sub-redes das aplicações, a política externa foi escrita para a camada errada. Corrija os seletores antes de depurar o encaminhamento, porque o encaminhamento parecerá correto e os contadores não se moverão.

O encaminhamento e a armadilha da recursão

Os seletores não substituem o encaminhamento. A e B têm de encaminhar tráfego entre C e D nos dois sentidos, o que significa encaminhamento IP ativo, rotas que apontam para o túnel e um caminho de retorno que exista do outro lado.

Se o túnel externo usar interfaces XFRM, as rotas selecionam a interface enquanto as políticas negociadas ainda limitam o que ela transporta. Uma interface não alarga o que está protegido; apenas muda a forma como o núcleo apanha o pacote.

A armadilha é a recursão. A rota de A para o ponto final externo de B tem de seguir a rede subjacente, não o túnel que A está a estabelecer, senão a encapsulação tenta viajar dentro de si mesma e a ligação nunca se completa.

Inspecione a tradução antes de acrescentar camadas

Veja qualquer NAT de origem em A e B antes de ajustar qualquer outra coisa. Uma regra que reescreve o endereço de C antes de a política IPsec se aplicar pode quebrar os seletores acordados, e também pode mudar o que D recebe do outro lado.

O mascaramento amplo não se torna mais seguro por ter duas camadas. Esconde qual endereço o extremo remoto vê, e essa é exatamente a informação de que precisa quando o túnel está ativo e a aplicação não.

Se uma regra NAT for realmente necessária, anote com que endereço cada lado pensa que fala. Essa única linha resolve a maioria das discussões sobre se a culpa é do túnel ou da tradução. Também diz ao próximo engenheiro onde olhar quando a regra for removida um ano depois. Um ping não fará nada disso.

Prove o fail-closed e verifique a MTU

O desaparecimento de uma rota não é, por si só, uma política fail-closed. Outra tabela, uma rota por omissão ou uma regra de política podem fornecer silenciosamente uma alternativa, e a única forma de saber é descer o túnel externo e observar o que o tráfego de aplicações faz. Faça-o de propósito, numa janela, em vez de o descobrir por acidente.

Teste três estados: túnel externo em baixo, túnel interno em baixo e recuperação depois de ambos voltarem. Use contadores de políticas em cada gateway, porque duas sessões IKE estabelecidas provam apenas que a negociação do plano de controlo foi bem-sucedida.

Orçamente as duas encapsulações. Um IKE a funcionar é um resultado de pacotes pequenos, e os pacotes de aplicação de tamanho completo ainda podem falhar quando são adicionados dois cabeçalhos; teste com um tamanho de carga útil conhecido no caminho real em vez de assumir que os números somam. A aritmética é fácil, o caminho não.