El client de WireGuard no pot arribar a un client d’OpenVPN?

Tots dos túnels es connecten, cada client pot arribar a la passarel·la, i en el moment que un prova l’adreça de l’altre els paquets desapareixen. No hi ha res de malament en cap de les dues encaixades, i cap quantitat de reemissió de claus ho canvia. La passarel·la porta paquets IP normals sense xifrar entre dues de les seves interfícies, així que els protocols no necessiten mai entendre’s entre ells; el que necessiten són tres coses que cap encaixada proporciona. Cobertura de destinació al client d’origen, propietat d’origen a la passarel·la i un camí de tornada a l’altre costat. El símptoma és el mateix per a les tres, i per això es diagnostiquen juntes.

El símptoma té una peça que falta alhora

Aquest disseny fa servir un pool de WireGuard 10.71.0.0/24 a wg1 i un pool d’OpenVPN 10.72.0.0/24 a tun1, tots dos acabant en una sola passarel·la. La petició en proves va de 10.71.0.5 a HTTPS a 10.72.0.30. Cada pas de sota tracta d’aquest únic flux. Cada comprovació té una empremta de fallada diferent tot i que l’usuari les viu igual, i normalment només en falta una de les tres alhora.

Comenceu confirmant que tots dos pools són realment en aquesta passarel·la i que el reenviament està activat a l’espai de noms on viuen els túnels. Una passarel·la que acaba tots dos protocols en espais de noms diferents no reenvia res entre ells, i val la pena descartar-ho abans de llegir cap configuració de parell.

Amplieu la cobertura de destinació del node radial

Al client de WireGuard, l’entrada de parell existent ha de seleccionar la passarel·la per a la destinació d’OpenVPN, cosa que vol dir que el prefix de destinació ha d’aparèixer a la llista permesa d’aquest parell. Afegir-lo no crea un segon túnel; canvia quin parell tria el client quan busca aquesta adreça, i amb wg-quick la ruta normalment segueix la llista automàticament.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Deixeu intactes les línies reals de clau i punt final, i recordeu que un gestor que faci servir Table = off no agafa cap ruta d’aquesta llista. En aquest cas el mateix prefix s’ha d’instal·lar a la taula de rutes del sistema per qui en sigui propietari, i una ruta que hi falta sembla exactament un prefix permès que hi falta.

Mantingueu la propietat d’origen a la passarel·la

L’entrada de parell d’aquest client a la passarel·la ha de continuar posseint exactament l’adreça d’origen d’aquest client. Les adreces permeses es comproven en tots dos sentits: trien un parell per al trànsit sortint i validen que l’origen d’un paquet entrant pertany al parell que l’ha enviat. Posar el pool d’OpenVPN a l’entrada del node radial perquè el node radial hi vol arribar és l’error que fa que el trànsit vagi cap al participant equivocat.

AllowedIPs = 10.71.0.5/32

Llegiu aquesta entrada com una declaració de propietat i no com una comoditat d’encaminament. Qualsevol altra cosa a què el client hagi d’arribar pertany a la llista de destinacions del client, no a la idea que la passarel·la té del que aquest parell pot enviar.

Doneu al costat d’OpenVPN una ruta de tornada

L’objectiu ara necessita una ruta de tornada cap a l’origen de WireGuard, i per als clients de pool normalment arriba com una ruta empenyuda des del servidor d’OpenVPN. Empenyeu-la només als clients que l’han de tenir, i confirmeu al client que s’ha acceptat en lloc de suposar que la directiva s’ha aplicat.

push "route 10.71.0.0 255.255.255.0"

La distribució de rutes no és autorització. Quan la destinació és darrere d’un altre client d’OpenVPN en lloc de dins del pool, la propietat de la pròpia LAN d’aquell client i els seus requisits de reenviament s’afegeixen al disseny, i la ruta empenyuda només és la primera meitat. Reformuleu el requisit com un graf abans d’afegir directrius: quin node posseeix quin prefix i quin node reenvia cap a ell.

Permeteu només el servei que volíeu permetre

Amb el reenviament activat i tots dos pools encaminables, la pregunta que queda és de política. Escriviu la regla per al flux concret i no per al parell d’interfícies en general, previsualitzeu-la abans d’aplicar-la i manteniu el camí de tornada amb estat perquè les respostes no es bloquin com a connexions noves. Una prova en sec no costa res i mostra exactament què s’afegiria.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Aquestes són regles de trànsit reenviat, diferents de les regles d’escolta de la passarel·la per als dos serveis VPN. Obrir els ports UDP exteriors no autoritza la petició interior, i autoritzar la petició interior no requereix SSH sense restriccions a la passarel·la ni un permís per defecte al reenviament. El tallafoc propi de l’objectiu i l’adreça d’escolta també han de coincidir, ja que un servei lligat a loopback rebutja el paquet més ben encaminat. Una política que només cobreix un sentit de la conversa sol fallar amb una petició correcta i una resposta silenciosa, que és el resultat més confús dels tres.

Les rutes recíproques solen significar que no cal traducció d’origen, cosa que conserva l’adreça de WireGuard a l’objectiu i fa llegibles els registres. No afegiu un emmascarament general perquè hi intervenen dos protocols, i no traieu una regla de traducció existent sense saber què hi depèn. Després verifiqueu l’únic flux de cap a cap, i proveu també una font o un port no permesos: una encaixada que funciona a cada costat no demostra ni la ruta creuada ni l’aïllament.