Por que os clientes OpenVPN não alcançam os seletores IPsec do gateway

Faça ping de um host atrás do túnel IPsec remoto a partir do gateway e ele responde limpo, então o túnel parece saudável e o ticket segue adiante. Depois um cliente conectado tenta o mesmo host e não recebe nada. Aquele ping nunca foi prova para o fluxo do cliente, porque saiu com o próprio endereço de origem do gateway e correspondeu a outro seletor IPsec. Entender por que os dois casos divergem é a maior parte da correção.

O ping do gateway testa um fluxo que seu cliente nunca usa

O endereço de origem decide qual política se aplica. Um pacote gerado no gateway sai com um endereço da LAN local ou do ponto final do túnel, e a política que corresponde a ele foi escrita exatamente para esse caso. O pacote de um cliente chega à interface OpenVPN com um endereço do pool de clientes, que é um seletor completamente diferente.

Por isso a falha parece um problema de roteamento quando na verdade é um problema de escopo de política. A alcançabilidade a partir do gateway prova que o peer está ativo e que as propostas foram negociadas, e não prova nada sobre se o pool está protegido.

Envie o prefixo remoto de que a aplicação realmente precisa

Tome o par ilustrativo 10.8.0.0/24 para clientes conectados e 172.30.239.0/25 para a rede remota protegida. O que um cliente precisa é de uma rota para esse segundo prefixo, não para a LAN do gateway e não para outro endereço de túnel. Uma rota enviada ao pool é o que faz o cliente entregar esse tráfego ao gateway. Sem ela, o pacote nunca chega à decisão de política que você está depurando.

Num servidor Community que aceita rotas enviadas, a diretiva assume a máscara real: push "route 172.30.239.0 255.255.255.128". O Access Server configura o mesmo destino pelas definições de rede privada ou de regras de acesso da versão instalada, com o modo roteado ou traduzido escolhido deliberadamente. Editar as cadeias de firewall geradas em vez da configuração proprietária é como uma instalação funcional se torna impossível de reproduzir.

Depois de conectar, leia a tabela de rotas do cliente e não a intenção do servidor. Uma rota que cobre apenas o pool significa que o envio nunca chegou, e uma rota predefinida pelo túnel é mais ampla que este requisito e vai surpreendê-lo mais tarde. Verifique a máscara e também o prefixo, porque um /25 enviado como /24 manda o tráfego de endereços vizinhos por um caminho que não consegue carregá-lo. Em seguida confirme que o cliente escolheu a interface do túnel para esse destino.

Faça os seletores incluírem o pool de clientes

Para acesso roteado que preserva os endereços dos clientes, a política IPsec tem de proteger o tráfego entre o pool e o prefixo remoto. Seletores escritos para a LAN do próprio gateway admitem o ping e descartam o pedido do cliente, e é exatamente a assimetria que iniciou esta investigação.

Inspecione a política negociada e também as propostas configuradas, por exemplo com ipsec statusall no strongSwan ou o comando de estado equivalente da sua implementação. Com IPsec baseado em políticas, a rota comum pode apontar para uma interface física enquanto o tráfego correspondente continua cifrado, portanto a ausência de um dispositivo de túnel não prova nada. Compare os pares de seletores com o pool e o prefixo que você anotou.

O NAT de origem genérico no gateway também pode quebrar a correspondência. Se uma regra de masquerade reescrever a origem do cliente antes da verificação de política, o pacote já não se parece com o seletor que você escreveu. É uma razão pela qual uma regra de masquerade ampla é uma má correção para um segundo VPN: muda qual política se aplica e qual endereço o lado remoto registra. Isente o tráfego que você pretende rotear, ou traduza-o deliberadamente e atualize os seletores.

Escolha roteamento ou tradução de propósito

O roteamento mantém o endereço do cliente visível para o lado remoto, então os registros remotos e as regras por origem continuam significativos, e exige que o gateway remoto conheça o caminho de retorno ao pool. A tradução esconde o pool atrás de um único endereço, o que elimina o problema da rota de retorno e destrói a identidade por cliente.

Escolha um único desenho e escreva-o, porque os dois exigem seletores diferentes e uma ordem de firewall diferente. Um masquerade aplicado a meio fica entre os dois e não satisfaz nenhum. A escolha escrita é também o que permite ao próximo engenheiro distinguir um erro de uma decisão deliberada.

Feche o ciclo no encaminhamento e na resposta

O gateway tem de encaminhar o protocolo e o destino que você pretende, o que significa encaminhamento IP ativo e uma cadeia de encaminhamento que permita o par. Depois o lado remoto tem de devolver as respostas pelo caminho IPsec, e isso é uma decisão de roteamento no gateway deles e não no seu. Ambas as metades são configuração comum, e ambas ficam facilmente a meio. Teste-as em separado para que uma regra de encaminhamento ausente não seja confundida com um túnel avariado.

Verifique com um pedido real de cliente para aplicação, observando-o atravessar a interface OpenVPN, a decisão IPsec e o host remoto. Inspecione a resposta como uma observação separada, porque um pedido que chega e uma resposta que nunca volta parecem iguais do lugar do cliente. Um pedido rastreado vale mais do que qualquer número de pings a partir do gateway.

Mantenha a autorização do destino estreita enquanto você testa, e confirme que um cliente sem a regra não consegue chegar ao serviço. Uma rota instalada mais uma associação estabelecida não é o mesmo que um acesso concedido.