Perfil WireGuard para um gateway IPsec: o que perguntar em vez disso

Os tempos limite do handshake com um gateway silencioso normalmente significam dois protocolos que nunca se encontram. Um par WireGuard fala Noise enquanto um gateway IPsec espera IKE. Endereço e porta corretos não mudam isso.

Reutilizar o endpoint num perfil não liga os dois. O próximo passo é um pedido a quem opera o gateway.

Primeiro pedido: a versão do protocolo

O IPsec designa uma família e não um único fluxo de trabalho. IKEv2 e IKEv1 diferem nos seus intercâmbios, nas opções de autenticação e no comportamento durante uma mudança de rede. Um gateway que termina apenas IKEv1 comportar-se-á de forma muito diferente de um que oferece IKEv2. A configuração do cliente muda com isso.

Pergunte que versão o serviço termina e se executa uma implementação baseada em padrões ou uma variante de fornecedor com cliente próprio. Os menus dos sistemas operativos escondem muitas vezes essa resposta atrás de uma única etiqueta. A etiqueta não é o protocolo.

Segundo pedido: o método de autenticação do cliente

A autenticação é onde está a maior parte do trabalho real. O serviço pode esperar um certificado de máquina com um determinado uso estendido de chave, um certificado de utilizador, um método EAP sobre IKEv2 ou uma chave pré-partilhada ligada a uma identidade. Qual se aplica decide do que o cliente precisa.

Uma chave privada WireGuard não é nada disso. É uma chave Curve25519 usada num handshake concreto. Nenhuma conversão a transforma num certificado nem numa credencial EAP. Uma ferramenta que afirme o contrário está a renomear o ficheiro ou a gerar algo sem relação.

A especificação do IKEv2 na RFC 7296 descreve o que uma implementação dessa versão tem de suportar. É uma referência para uma resposta vaga do operador, não um guia de configuração do cliente.

Terceiro pedido: a identidade confiável e os destinos

Peça a identidade do gateway tal como o cliente a tem de ver, mais a âncora de confiança que a valida. Depois pergunte que intervalos privados e resolvedores o serviço empurra. Essas duas respostas decidem o que o túnel transporta realmente.

Sem elas, uma ligação a funcionar pode ainda falhar a tarefa. Um túnel de pé sem resolvedor empurrado deixa os nomes internos sem resposta. Um seletor de tráfego em falta deixa o destino fora do túnel, embora o handshake tenha sido bem-sucedido.

Uma sonda do endpoint responde a uma pergunta diferente da do erro do cliente. Uma porta acessível sem associação aponta para a autenticação, enquanto uma porta inacessível aponta para o caminho.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

Execute essa sonda antes de alterar seja o que for no cliente. Se as portas respondem e a associação continua a falhar, o problema são as credenciais ou a política. Se não respondem de todo, nenhuma edição do perfil ajudará.

Quando os dois protocolos têm de coexistir

Administrar as duas redes é um motivo legítimo para manter os dois protocolos. O desenho habitual termina WireGuard e IPsec em interfaces separadas ou gateways separados. O tráfego aprovado é então encaminhado entre eles.

Esse desenho introduz uma fronteira de confiança e autorização, e deve ser registada como tal. Que pares podem atravessar, em que direção e sob a política de quem é uma decisão de encaminhamento e firewall. Nenhum dos protocolos a fornece.

O que não é é uma conversão transparente. O tráfego que chega por WireGuard é reoriginado no túnel IPsec, e cada política pelo meio aplica-se-lhe.

Esclareça primeiro os requisitos de protocolo e autenticação do servidor. Depois use o cliente e o percurso de registo que o operador suporta, e mantenha as chaves privadas fora dos conversores web enquanto isso acontece.