Le client WireGuard n’atteint pas un client OpenVPN ?

Les deux tunnels se connectent, chaque client atteint la passerelle, et à l’instant où l’un essaie l’adresse de l’autre, les paquets disparaissent. Rien ne cloche dans l’une ou l’autre poignée de main, et aucune réémission de clés n’y change quoi que ce soit. La passerelle transporte des paquets IP ordinaires non chiffrés entre deux de ses propres interfaces, les protocoles n’ont donc jamais besoin de se comprendre ; ce qu’il leur faut, ce sont trois choses qu’aucune poignée de main ne fournit. La couverture de destination sur le client d’origine, la propriété de la source au niveau de la passerelle et un chemin de retour de l’autre côté. Le symptôme est identique pour les trois, d’où un diagnostic mené ensemble.

Il manque une pièce à la fois au symptôme

Cette conception utilise un pool WireGuard 10.71.0.0/24 sur wg1 et un pool OpenVPN 10.72.0.0/24 sur tun1, tous deux terminés sur une même passerelle. La requête testée part de 10.71.0.5 vers HTTPS sur 10.72.0.30. Chaque étape ci-dessous porte sur ce seul flux. Chaque vérification a une signature de panne différente, même si l’utilisateur les vit de la même façon, et il n’en manque en général qu’une des trois à la fois.

Commencez par confirmer que les deux pools sont bien sur cette passerelle et que le transfert est activé dans l’espace de noms où vivent les tunnels. Une passerelle qui termine les deux protocoles dans des espaces de noms différents ne transfère rien entre eux, et cela vaut la peine d’être écarté avant de lire la moindre configuration de pair.

Étendez la couverture de destination du site distant

Sur le client WireGuard, l’entrée de pair existante doit sélectionner la passerelle pour la destination OpenVPN, ce qui signifie que le préfixe de destination doit figurer dans la liste autorisée de ce pair. L’ajouter ne crée pas un second tunnel ; cela change le pair que le client choisit lorsqu’il cherche cette adresse, et avec wg-quick la route suit normalement la liste automatiquement.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Laissez intactes les vraies lignes de clé et de point de terminaison, et rappelez-vous qu’un gestionnaire utilisant Table = off ne prend aucune route de cette liste. Dans ce cas, le même préfixe doit être installé dans la table de routage du système par celui qui le possède, et une route manquante y ressemble exactement à un préfixe autorisé manquant.

Conservez la propriété de la source sur la passerelle

L’entrée de pair de ce client sur la passerelle doit continuer à posséder exactement l’adresse source de ce client. Les adresses autorisées sont vérifiées dans les deux sens : elles choisissent un pair pour le trafic sortant et elles valident que la source d’un paquet entrant appartient au pair qui l’a envoyé. Mettre le pool OpenVPN dans l’entrée du site distant parce que celui-ci veut l’atteindre est l’erreur qui dirige le trafic vers le mauvais participant.

AllowedIPs = 10.71.0.5/32

Lisez cette entrée comme une déclaration de propriété et non comme une commodité de routage. Tout le reste de ce que le client doit atteindre relève de la liste de destinations du client, pas de l’idée que la passerelle se fait de ce que ce pair a le droit d’envoyer.

Donnez au côté OpenVPN une route de retour

La cible a maintenant besoin d’une route vers la source WireGuard, et pour les clients d’un pool elle arrive généralement sous forme de route poussée depuis le serveur OpenVPN. Ne la poussez qu’aux clients qui doivent l’avoir, et confirmez sur le client qu’elle a été acceptée au lieu de supposer que la directive a été appliquée.

push "route 10.71.0.0 255.255.255.0"

La distribution de routes n’est pas une autorisation. Lorsque la destination se trouve derrière un autre client OpenVPN plutôt que dans le pool, la propriété de son propre LAN et ses exigences de transfert s’ajoutent à la conception, et la route poussée n’est que la première moitié. Reformulez l’exigence sous forme de graphe avant d’ajouter des directives : quel nœud possède quel préfixe, et quel nœud transfère vers lui.

N’autorisez que le service que vous vouliez autoriser

Le transfert activé et les deux pools routables, la question restante est celle de la politique. Écrivez la règle pour le flux précis et non pour la paire d’interfaces en général, prévisualisez-la avant de l’appliquer, et conservez le chemin de retour avec état pour que les réponses ne soient pas bloquées comme de nouvelles connexions. Une simulation ne coûte rien et montre exactement ce qui serait ajouté.

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

Ce sont des règles de trafic transféré, distinctes des règles d’écoute de la passerelle pour les deux services VPN. Ouvrir les ports UDP extérieurs n’autorise pas la requête intérieure, et autoriser la requête intérieure n’exige ni SSH sans restriction vers la passerelle ni autorisation par défaut sur le transfert. Le pare-feu de la cible et son adresse d’écoute doivent eux aussi concorder, car un service lié à loopback refuse le paquet le plus soigneusement routé. Une politique qui ne couvre qu’un sens de la conversation échoue généralement par une requête réussie et une réponse silencieuse, ce qui est le résultat le plus déroutant des trois.

Des routes réciproques signifient généralement qu’aucune traduction de source n’est nécessaire, ce qui préserve l’adresse WireGuard sur la cible et rend les journaux lisibles. N’ajoutez pas de masquerade global parce que deux protocoles sont impliqués, et ne supprimez pas une règle de traduction existante sans savoir ce qui en dépend. Vérifiez ensuite l’unique flux de bout en bout, et testez aussi une source ou un port interdit : une poignée de main qui fonctionne de chaque côté ne prouve ni la route croisée ni l’isolation.