Connecté à OpenVPN mais rien ne charge : un parcours depuis le client

La fenêtre du client affiche Connecté, l'adresse du tunnel est là, et le navigateur tourne encore. Cette combinaison est normale, car une poignée de main réussie prouve seulement que le tunnel a été construit ; elle ne dit rien sur le fait que le serveur transmettra vos paquets, réécrira leur source ou répondra à vos requêtes DNS. L'erreur que font la plupart des gens est d'ouvrir d'abord la configuration du serveur. Travaillez plutôt depuis le client vers l'extérieur, car chaque étape ci-dessous vous dit si la suivante mérite même d'être vérifiée.

Commencez par le client et travaillez vers l'extérieur

Faites trois tests dans cet ordre et notez où le premier échoue. Faites un ping vers l'adresse du tunnel du serveur, ce qui prouve que le tunnel lui-même transporte du trafic. Faites un ping vers une adresse publique par numéro, ce qui prouve la transmission et la traduction sans impliquer la résolution de noms. Essayez ensuite de résoudre un nom d'hôte, seul test qui sollicite le DNS. Chaque résultat retire toute une couche des soupçons.

Ne sautez pas au troisième test parce qu'un navigateur semble plus rapide. Un chargement de page raté couvre les trois couches à la fois, et c'est en partant de là que les gens finissent par reconstruire un tunnel qui fonctionnait. Une page qui échoue ne vous dit pas laquelle des trois a cassé.

Deux captures montrent où les paquets s'arrêtent

Avec un ping vers une adresse publique lancé depuis le client, prenez une capture sur l'interface du tunnel et une sur le lien montant censé atteindre internet. Lancez les deux en même temps pour que les horodatages concordent.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Si les requêtes apparaissent sur le tunnel et jamais sur le lien montant, le serveur les a jetées entre le tunnel et le câble, et la cause est la transmission ou la politique de pare-feu de transmission, pas le NAT. Si elles apparaissent sur les deux, le serveur a fait sa part et la réponse manque plus loin, ce qui pointe vers la traduction, un filtre en amont ou une restriction du fournisseur.

Prenez le nom du lien montant dans la table de routage, pas dans un tutoriel. Les images cloud et les adaptateurs renommés correspondent rarement à l'interface d'exemple d'un guide, et une capture prise sur le mauvais périphérique ressemble exactement à un serveur qui ne transmet pas :

ip -4 route get 9.9.9.9

Le champ dev de cette sortie est le nom dont la règle NAT aura besoin plus tard, alors gardez-le.

La transmission est un commutateur du noyau et une politique de pare-feu

Le noyau doit d'abord accepter de transmettre. Lisez la valeur actuelle, puis rendez le réglage permanent au lieu de l'écrire seulement dans le noyau en cours d'exécution :

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

La transmission n'est que la moitié. Sur un hôte sous UFW, la politique de transmission se règle dans /etc/default/ufw et doit être ACCEPT avant qu'un rechargement prenne effet. Un rejet par défaut sur le chemin de transmission laisse la poignée de main parfaitement saine tout en écartant silencieusement chaque paquet qui tente de sortir par le tunnel, ce qui est exactement le symptôme avec lequel vous avez commencé.

Les hôtes qui gèrent nftables directement ont la même question dans une autre syntaxe. Regardez les compteurs de la chaîne de transmission pendant qu'un test client tourne, car une chaîne consultée et une chaîne qui rejette se ressemblent à l'identique dans un fichier de configuration.

Nommez la vraie interface de sortie dans la règle NAT

La traduction de source appartient à l'interface qui quitte réellement l'hôte, avec le pool que le serveur distribue. Les deux moitiés de cette règle doivent décrire la réalité, et aucune n'est facultative.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

L'échec classique est une règle copiée d'un guide qui dit -o eth0 sur une machine dont l'adaptateur porte un autre nom. La règle s'installe sans avertissement, ne correspond à rien, et le client n'a toujours pas internet. Le pool est l'autre moitié de la même erreur : si le serveur distribue 10.44.0.0/24 et que la règle couvre 10.8.0.0/24, rien ne correspondra jamais.

Regardez les compteurs plutôt que de croire le texte de la règle. Le listing indique les paquets par règle, et une règle qui ne correspond jamais reste à zéro, aussi correcte qu'elle paraisse. Donnez-lui une minute de trafic client réel avant d'en tirer quoi que ce soit :

iptables -t nat -L POSTROUTING -v -n

Un compteur de paquets à zéro après un vrai test client signifie que la correspondance est fausse, pas que le tunnel est cassé. Une fois qu'elle correspond, enregistrez le jeu de règles pour qu'il survive à un redémarrage ; un correctif qui ne vit que dans l'historique de votre shell disparaît au premier redémarrage.

Si le serveur est aussi une instance NAT cloud, la plateforme a son mot à dire. Une instance qui traduit les adresses a généralement besoin de la vérification source et destination désactivée là où le fournisseur propose ce réglage, et le port VPN lui-même doit être joignable de l'extérieur.

Le DNS est la deuxième panne derrière la première

Un ping par adresse qui fonctionne alors que les noms échouent est un problème de résolveur, et il a sa propre cause. Un client qui garde son résolveur local envoie ces requêtes dans un tunnel complet et attend une réponse qui n'arrive jamais, car le résolveur local est désormais du mauvais côté de la route.

Poussez un résolveur depuis le serveur pour que le client sache où demander. Deux entrées donnent au client un repli si la première est injoignable, et les deux devraient être des résolveurs que le tunnel autorise réellement.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Les clients Windows peuvent ensuite retomber sur le résolveur local de toute façon, et c'est exactement ce que block-outside-dns existe pour empêcher, au prix de la perte des noms que seul le réseau local peut résoudre. Les clients Linux sous systemd-resolved ignorent souvent un résolveur poussé tant qu'un script ne l'installe pas, alors vérifiez resolvectl status pour le périphérique du tunnel avant de conclure que le push a été ignoré.

Terminez le parcours comme un utilisateur le vit. Chargez une vraie page depuis le client, confirmez l'adresse d'où elle sort, redémarrez le serveur, reconnectez-vous et répétez les trois tests. Ce second passage est le seul qui prouve que les règles enregistrées, la politique de pare-feu et le résolveur poussé ont tous survécu ensemble.