Perfil de WireGuard per a una passarel·la IPsec: què cal demanar en lloc d'això

Els temps d'espera de l'encaixada de mans amb una passarel·la silenciosa solen significar dos protocols que no es troben mai. Un parell de WireGuard parla Noise mentre una passarel·la IPsec espera IKE. L'adreça i el port correctes no ho canvien.

Reutilitzar el punt final en un perfil no uneix els dos. El següent pas és una sol·licitud a qui gestiona la passarel·la.

Primera sol·licitud: la versió del protocol

IPsec designa una família i no un únic flux de treball. IKEv2 i IKEv1 difereixen en els seus intercanvis, les seves opcions d'autenticació i el seu comportament davant un canvi de xarxa. Una passarel·la que només acaba IKEv1 es comportarà molt diferent d'una que ofereix IKEv2. La configuració del client canvia amb això.

Pregunteu quina versió acaba el servei i si executa una implementació basada en estàndards o una variant de proveïdor amb client propi. Els menús dels sistemes operatius sovint amaguen aquesta resposta darrere d'una sola etiqueta. L'etiqueta no és el protocol.

Segona sol·licitud: el mètode d'autenticació del client

L'autenticació és on hi ha la major part de la feina real. El servei pot esperar un certificat de màquina amb un ús de clau estès concret, un certificat d'usuari, un mètode EAP sobre IKEv2 o una clau prèviament compartida lligada a una identitat. Quin s'aplica decideix què necessita el client.

Una clau privada de WireGuard no és cap d'aquestes coses. És una clau Curve25519 utilitzada en una encaixada de mans concreta. Cap conversió la converteix en un certificat ni en una credencial EAP. Una eina que afirmi el contrari està reanomenant el fitxer o generant una cosa no relacionada.

L'especificació d'IKEv2 a l'RFC 7296 descriu què ha de suportar una implementació d'aquesta versió. És una referència per a una resposta vaga de l'operador, no una guia de configuració del client.

Tercera sol·licitud: la identitat de confiança i les destinacions

Demaneu la identitat de la passarel·la tal com el client l'ha de veure, més l'àncora de confiança que la valida. Després pregunteu quins rangs privats i resolutors empeny el servei. Aquestes dues respostes decideixen què transporta realment el túnel.

Sense elles, una connexió que funciona pot fallar la tasca. Un túnel aixecat sense resolutor empès deixa els noms interns sense resposta. Un selector de trànsit absent deixa la destinació fora del túnel tot i que l'encaixada de mans hagi reixit.

Una sonda del punt final respon una pregunta diferent de l'error del client. Un port abastable sense associació apunta a l'autenticació, mentre que un port inabastable apunta al camí.

# 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

Executeu aquesta sonda abans de canviar res al client. Si els ports responen i l'associació continua fallant, el problema són les credencials o la política. Si no responen gens, cap edició del perfil no ajudarà.

Quan els dos protocols han de coexistir

Administrar les dues xarxes és un motiu legítim per mantenir els dos protocols. El disseny habitual acaba WireGuard i IPsec en interfícies separades o passarel·les separades. El trànsit aprovat es dirigeix després entre elles.

Aquest disseny introdueix una frontera de confiança i autorització, i cal deixar-la escrita com a tal. Quins parells poden creuar, en quina direcció i sota la política de qui és una decisió d'encaminament i tallafocs. Cap dels dos protocols no la proporciona.

El que no és és una conversió transparent. El trànsit que arriba per WireGuard es reorigina dins del túnel IPsec, i tota política entremig s'hi aplica.

Primer aclariu els requisits de protocol i autenticació del servidor. Després feu servir el client i el camí d'inscripció que l'operador admet, i manteniu les claus privades fora dels convertidors web mentre passa.