Préfixe public via OpenVPN : corriger le chemin de retour

Regardez le tunnel monter et le client pinguer l’autre côté, puis une adresse publique qui appartient derrière le VPN répond d’ailleurs, ou pas du tout. Ce symptôme n’a généralement rien à voir avec le chiffrement ou les certificats. Un préfixe routé par le fournisseur est livré comme une route IP, et le transporter via OpenVPN signifie reproduire cette route à deux niveaux et préserver l’adresse source sur le chemin de retour. Ponter le WAN n’est pas nécessaire, et ajouter l’adresse à une interface ne crée pas la route amont.

Le préfixe doit d’abord être routé vers vous

Demandez au fournisseur comment le bloc est livré. Un préfixe routé vers l’adresse principale de votre serveur est autre chose que des adresses que le fournisseur s’attend à atteindre directement sur un segment WAN. Seul le premier modèle fonctionne avec la conception ci-dessous.

Si le fournisseur route 198.51.100.64/28 vers votre serveur d’entrée, les paquets de cette plage arrivent au serveur et s’y arrêtent, sauf si vous les transférez. Si le fournisseur ponte plutôt la plage sur votre lien amont, le serveur doit répondre en ARP pour elle, ce qui est un autre problème.

Testez le modèle de livraison avant de toucher à OpenVPN : depuis l’extérieur, pinguez une adresse du bloc et regardez quelle interface la reçoit. Si rien n’arrive, aucune configuration de tunnel n’aidera. Si l’adresse répond directement sur le WAN, le fournisseur ponte au lieu de router, et la conception ci-dessous ne s’applique pas.

Deux niveaux de routage : route du noyau et iroute

OpenVPN a besoin du préfixe à deux endroits. Le noyau doit savoir que le préfixe appartient à l’appareil du tunnel, pour que les paquets transférés entrent dans OpenVPN au lieu de la route par défaut. OpenVPN doit aussi savoir quel client authentifié possède le préfixe, et c’est l’entrée iroute dans le répertoire propre au client.

La route côté serveur ressemble à ceci, le préfixe et le masque devant correspondre à l’attribution :

ip route add 198.51.100.64/28 dev tun0

La configuration propre au client attribue la propriété. Placez-la dans le fichier CCD nommé d’après le nom commun du certificat client, et confirmez que ce répertoire est bien celui que le serveur lit réellement :

iroute 198.51.100.64 255.255.255.240

La documentation OpenVPN des réseaux routés décrit les deux niveaux et pourquoi ils sont séparés. Une route du noyau sans iroute envoie des paquets dans le tunnel sans propriétaire, et OpenVPN les rejette. Un iroute sans la route du noyau laisse les paquets sur le chemin par défaut du serveur. Les deux erreurs ressemblent à un tunnel cassé côté client.

Où vit l’adresse du service

Le préfixe délégué n’est pas la même chose que les adresses propres du tunnel. Numérotez la liaison depuis l’espace privé si vous voulez, et placez l’adresse publique du service là où le service s’exécute réellement.

Sur un client Linux qui termine le service localement, une seule adresse d’hôte suffit :

ip address add 198.51.100.70/32 dev lo

Si le préfixe est routé plus loin vers un hôte VM ou un autre LAN, configurez plutôt ce chemin descendant et sa route de retour. Attribuer chaque adresse du bloc au client VPN n’est pas nécessaire et crée des conflits plus tard.

Conservez la source publique sur le chemin de retour

Une réponse du préfixe délégué doit sortir par le tunnel et atteindre la route du fournisseur. Si l’hôte distant l’envoie via son propre FAI, l’adresse source semble usurpée, et le fournisseur ou la destination la rejette. La solution est une règle basée sur la source ou une table de routage dédiée, pas un NAT plus large. Sans cela, le service fonctionne depuis le pair du tunnel et échoue partout ailleurs.

Au serveur d’entrée, une règle de masquerade large est le coupable habituel. Elle réécrit la source publique vers l’adresse principale du serveur, et le client ne voit jamais la vraie :

iptables -t nat -S POSTROUTING

Limitez le NAT aux clients VPN privés qui en ont besoin et laissez le préfixe délégué non traduit. Confirmez ensuite que le serveur transfère bien le préfixe, car une chaîne de transfert avec refus par défaut le rejette silencieusement.

Vérifiez les deux directions avant de lui faire confiance

La vérification, ce sont quatre observations, pas une. Confirmez que la route du fournisseur arrive, que le noyau envoie le préfixe dans le tunnel, qu’OpenVPN l’attribue au bon client et que la réponse revient avec la source publique intacte. Chaque observation a sa propre commande, donc un échec pointe une couche plutôt que toute la conception. Exécutez-les dans cet ordre après chaque changement de configuration.

Demandez au noyau quel chemin prend une adresse déléguée, et observez le tunnel pendant qu’une requête tourne :

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Le filtrage de chemin inverse peut annuler une route correcte. Vérifiez le réglage effectif sur le tunnel et sur le lien amont, et rappelez-vous qu’un mode strict rejette le trafic dont la source ne correspond pas à l’interface par laquelle il est arrivé :

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Enfin, testez le cas d’échec. Arrêtez le tunnel et confirmez que le préfixe public ne fuit pas par le lien amont ordinaire. Rétablir le VPN devrait ramener le service sans élargir les ports que l’hôte expose.