Perfil de WireGuard para unha pasarela IPsec: que pedir no seu lugar

Os tempos de espera do handshake cunha pasarela silenciosa adoitan significar dous protocolos que nunca se atopan. Un par de WireGuard fala Noise mentres unha pasarela IPsec espera IKE. O enderezo e o port correctos non o cambian.

Reutilizar o extremo nun perfil non une os dous. O seguinte paso é unha solicitude a quen xestiona a pasarela.

Primeira solicitude: a versión do protocolo

IPsec designa unha familia e non un único fluxo de traballo. IKEv2 e IKEv1 difiren nos seus intercambios, nas súas opcións de autenticación e no seu comportamento ante un cambio de rede. Unha pasarela que só remata IKEv1 comportarase de forma moi distinta a unha que ofrece IKEv2. A configuración do cliente cambia con elo.

Pregunte que versión remata o servizo e se executa unha implementación baseada en estándares ou unha variante de provedor co seu propio cliente. Os menús dos sistemas operativos adoitan agochar esa resposta tras unha soa etiqueta. A etiqueta non é o protocolo.

Segunda solicitude: o método de autenticación do cliente

A autenticación é onde está a maior parte do traballo real. O servizo pode esperar un certificado de máquina cun uso estendido de clave concreto, un certificado de usuario, un método EAP sobre IKEv2 ou unha clave precompartida vinculada a unha identidade. Cal se aplica decide o que necesita o cliente.

Unha clave privada de WireGuard non é nada diso. É unha clave Curve25519 usada nun handshake concreto. Ningunha conversión a converte nun certificado nin nunha credencial EAP. Unha ferramenta que afirme o contrario está renomeando o ficheiro ou xerando algo sen relación.

A especificación de IKEv2 no RFC 7296 describe o que debe admitir unha implementación desa versión. É unha referencia para unha resposta vaga do operador, non unha guía de configuración do cliente.

Terceira solicitude: a identidade de confianza e os destinos

Pida a identidade da pasarela tal como o cliente debe vela, máis a áncora de confianza que a valida. Despois pregunte que rangos privados e resolutores empurra o servizo. Esas dúas respostas deciden o que transporta realmente o túnel.

Sen elas, unha conexión que funciona pode fallar a tarefa. Un túnel levantado sen un resolutor empurrado deixa os nomes internos sen resposta. Un selector de tráfico ausente deixa o destino fóra do túnel aínda que o handshake tivese éxito.

Unha sonda do extremo responde a unha pregunta distinta da do erro do cliente. Un port accesible sen asociación apunta á autenticación, mentres que un port inaccesible apunta ao camiño.

# 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 esa sonda antes de cambiar nada no cliente. Se os ports responden e a asociación segue fallando, o problema son as credenciais ou a política. Se non responden en absoluto, ningunha edición do perfil axudará.

Cando os dous protocolos teñen que convivir

Administrar as dúas redes é un motivo lexítimo para conservar os dous protocolos. O deseño habitual remata WireGuard e IPsec en interfaces separadas ou pasarelas separadas. O tráfico aprobado enrútase entón entre elas.

Ese deseño introduce unha fronteira de confianza e autorización, e debería quedar escrita como tal. Que pares poden cruzar, en que dirección e baixo a política de quen é unha decisión de encamiñamento e devasa. Ningún dos dous protocolos a proporciona.

O que non é é unha conversión transparente. O tráfico que chega por WireGuard reoríxase no túnel IPsec, e toda política intermedia se lle aplica.

Aclare primeiro os requisitos de protocolo e autenticación do servidor. Despois use o cliente e a ruta de inscrición que admite o operador, e manteña as claves privadas fóra dos conversores web mentres iso ocorre.