OpenVPN en tunnel complet : ajouter une sortie internet côté serveur

Un client s’authentifie, reçoit une adresse du pool et atteint les services de l’hôte VPN, mais toute destination publique expire. Voilà à quoi ressemble un tunnel sans sortie, et cela reste ainsi tant que quatre choses distinctes ne sont pas vraies. Le client doit accepter une route par défaut, le serveur doit transférer, le pare-feu doit autoriser le transit, et les réponses ont besoin d’un chemin de retour vers le pool. Les quatre défaillances partagent un seul symptôme, alors changez un seul élément par essai et notez le résultat.

Poussez la route par défaut et vérifiez ce que le client a installé

La ligne côté serveur est courte, et elle ne concerne que les clients qui acceptent les options poussées. La forme def1 installe deux demi-routes par défaut au lieu de supprimer la route par défaut existante, ce qui maintient la connexion actuelle en vie tout en capturant chaque destination.

push "redirect-gateway def1"

Après la reconnexion, lisez la table de routage du client plutôt que de faire confiance au profil. Sous Linux, les deux entrées /1 apparaissent à côté de la route par défaut d’origine, et Windows affiche la même paire sous la forme 0.0.0.0/1 et 128.0.0.0/1. Un client qui ignore les options poussées, ou qui est configuré pour les refuser, conserve son ancienne route par défaut et n’envoie jamais le trafic internet dans le tunnel. Tranchez cette question avant de modifier quoi que ce soit sur le serveur, car aucune règle côté serveur ne peut compenser.

Le transfert est un réglage du serveur, pas un réglage du VPN

Lisez l’indicateur de transfert avant de toucher au routage. Un zéro à cet endroit signifie que le noyau reçoit le paquet du client et refuse de le transmettre, ce qui ressemble exactement à un blocage du pare-feu vu de l’autre extrémité. Définissez la valeur via le répertoire de configuration du système pour qu’elle survive à un redémarrage.

sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system

Ensuite, vérifiez que l’hôte lui-même dispose d’une route fonctionnelle vers la sortie internet. Une requête depuis le shell du serveur prouve que le chemin amont est utilisable et ne dit absolument rien sur le transfert du paquet d’un client, alors traitez ces deux points comme deux tests séparés. Si le serveur n’atteint pas la destination, aucune quantité de configuration de transfert n’aidera.

Autorisez exactement le transit que vous voulez, et rien d’autre

Les paquets transférés traversent le chemin forward ; le trafic adressé à l’hôte VPN lui-même traverse input. Ce sont des décisions distinctes, et ouvrir le chemin input n’autorise pas le transit à travers la machine. Les confondre est la raison la plus fréquente pour laquelle un pare-feu semble tout autoriser alors que les clients expirent encore.

Une politique minimale accepte les nouvelles connexions du pool vers l’interface de sortie et accepte les réponses qui appartiennent à des flux établis. Placez-la dans le propriétaire de jeu de règles qu’utilise votre distribution, plutôt que d’ajouter une règle en double à chaque démarrage ; les règles dupliquées s’accumulent et les compteurs cessent de signifier quoi que ce soit.

sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Basculer chaque chaîne en accept fait passer le test et supprime la raison d’être du pare-feu. Gardez le périmètre sur le pool et l’interface de sortie, et laissez tranquille le transfert sans rapport.

Donnez aux réponses un endroit où aller

Les adresses du pool sont privées, donc un serveur public ne peut pas y livrer une réponse directement. Soit l’hôte VPN traduit l’adresse source en sortie, soit un équipement en amont détient une route de retour vers le pool.

sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE

Ajoutez exactement une couche de traduction. Un second NAT plus en amont masque le premier et rend les deux journaux presque inutiles quand quelque chose casse plus tard. Si un routeur en amont route déjà le pool en retour, ajouter une traduction sur l’hôte est redondant, et le chemin de retour dépend alors de la configuration de ce routeur plutôt que de la vôtre.

Les instances cloud ajoutent une porte de plus, car certaines plateformes écartent les paquets dont l’adresse source n’est pas celle de l’instance, sauf si ce contrôle est assoupli. Ce réglage se trouve hors de l’invité et s’oublie facilement quand une machine de test locale fonctionne.

Prouvez-le depuis le client, pas depuis le shell du serveur

Commencez par une requête IPv4 numérique, puis une résolution de nom, puis l’application. Un ping prouve le transfert et la traduction ;il ne prouve rien sur la résolution, car les options DNS ne prennent effet que lorsque l’intégration du client les installe.

curl -4 -m 5 http://198.51.100.10/
dig +short example.com

Notez les changements et l’étape d’annulation au fil de l’eau, afin que la politique de sortie puisse être annulée en une action quand un test échoue. Cette recette ne couvre que l’IPv4 ; inventoriez l’IPv6 séparément avant d’affirmer que le déploiement transporte tout le trafic.