Quem responde realmente no endereço dedicado da VPN?

Um endereço que fica sem uso na alocação da organização não é um ouvinte, e adicioná-lo a uma firewall não cria nenhum. Algo tem de terminar o IKE nesse endereço, e o mecanismo varia conforme a gateway possua o endereço ou um dispositivo a montante o traduza. É o caminho do pacote que distingue os dois casos, e é ele que determina que funcionalidade da plataforma precisa antes de alguém abrir um pedido de alteração. Modele primeiro o caminho, depois escolha.

O caminho do pacote por trás do endereço

Um par envia IKE para o endereço que recebeu, por UDP 500 ou por UDP 4500 quando há travessia de NAT. O dispositivo que detiver esse endereço no caminho ou recebe o datagrama localmente e responde-lhe, ou reencaminha-o para outro local. Essas são as únicas duas possibilidades, e tudo o resto neste artigo decorre de qual delas é verdadeira.

Receber localmente significa que existe um socket nesse dispositivo, ligado a esse endereço. Reencaminhar significa que o datagrama é reescrito e enviado para outro ponto final, que fica então com o socket. Uma regra de firewall que permite UDP 500 não lhe diz nada sobre qual das duas coisas está a acontecer.

Escreva o registo antes de tocar em algo: o endereço com que os pares contactam, como a rede a montante o entrega, a interface local ou o ponto final lógico que o recebe, e o processo que responde ao IKE. Quatro linhas, e cada uma pode ser verificada. Quando uma delas é desconhecida, essa incógnita é trabalho de projeto e não um detalhe de implementação a decidir mais tarde. Preenchê-las depois de o pedido de alteração ser aprovado é como uma regra de tradução acaba no dispositivo errado.

Modelo A: a gateway possui o endereço

No primeiro modelo a gateway detém o endereço ela própria, seja como endereço secundário numa interface existente, como endereço numa interface dedicada, ou como loopback que a plataforma suporta como ponto final de túnel. São três funcionalidades diferentes com três caminhos de configuração diferentes, e uma plataforma que suporta uma pode não suportar as outras.

Confirme que a plataforma e a versão suportam exatamente esta disposição antes de projetar em torno dela. Um bloco encaminhado, um endereço adicional numa interface e um ponto final loopback não são intercambiáveis, e a documentação de uma versão não promete que a seguinte se comporte da mesma forma.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

O socket à escuta é a prova. Se nada estiver ligado ao endereço, a gateway não é o terminador, diga o que disser a tabela de rotas, e uma captura de pacotes mostrará os datagramas a chegar sem nada que lhes responda.

Não coloque uma segunda interface numa sub-rede que já existe noutro local da topologia e não assuma que a plataforma resolverá isso. Sub-redes de interface sobrepostas produzem uma seleção de origem ambígua e, em muitas plataformas, uma recusa limpa de configuração.

Modelo B: um dispositivo a montante tradu-lo

No segundo modelo uma firewall a montante detém o endereço dedicado e reencaminha o tráfego para outra gateway VPN. Isso é uma tradução de destino com caminho de retorno, e é um projeto perfeitamente válido desde que documentado como tal.

O que não é, é prova de que o dispositivo a montante adquiriu um socket VPN local. A tradução reencaminha pacotes; não torna a caixa superior num respondedor IKE. Se a regra a montante for removida ou o seu caminho de retorno quebrar, a VPN para, mesmo que a gateway esteja saudável e os seus próprios ouvintes intactos.

Registe os dois endereços: aquele com que os pares contactam e aquele que a gateway vê de facto. Registe depois o transporte e o caminho de retorno, porque uma tradução que funciona para UDP 500 mas não para ESP encapsulado liga-se e depois falha em transportar tráfego, o que é uma falha confusa de depurar mais tarde.

A identidade não é o endereço exterior

O IPsec separa o ponto final do túnel do tráfego que protege, e a arquitetura mantém essas decisões em locais diferentes. Alterar o endereço com que os pares contactam não altera automaticamente que prefixos internos são permitidos, que rotas são instaladas ou a que recursos a sessão pode chegar.

A identidade autenticada é de novo separada. O IKEv2 transporta uma carga de identidade e uma troca de autenticação que não têm de coincidir com o endereço exterior do pacote, e é precisamente por isso que um projeto traduzido ainda pode autenticar corretamente.

Essa independência é útil e também uma armadilha. Dois nomes DNS que resolvem para um ouvinte comum não selecionam backends VPN diferentes, e um certificado que nomeia uma identidade não satisfará um par que espera outra. Confirme o que o par valida antes de assumir que só o endereço o decide.

Aceite o projeto observando uma ligação

Inspecione onde uma nova ligação autorizada é realmente entregue, que identidade responde e que fluxo privado é depois permitido. Três observações, três camadas diferentes, e uma consulta pública bem-sucedida do endereço não testa nenhuma delas.

Guarde também o caso negativo: um par que não deveria ser aceite, ou um prefixo interno que não deveria ser alcançável, verificado após a alteração. O registo que escreveu no início é o que torna esse teste possível sem reconstruir o projeto de memória.

O sentido de tudo isto é permitir ao proprietário da rede escolher um método de alocação suportado em vez de confiar numa afirmação geral sobre o que cada firewall consegue fazer com um endereço extra. É exatamente essa afirmação o ponto onde estes projetos falham, porque soa plausível em todas as plataformas e em geral não é verdadeira em nenhuma. O registo de quatro linhas resolve isso para a sua plataforma em dez minutos.