Les clients VPN se connectent mais sans internet : trois pièces manquantes

Le client obtient une adresse, le serveur répond aux ping et, pourtant, chaque page expire. La plupart des gens commencent à modifier le profil du client à ce stade, ce qui est généralement un effort perdu : une fois le tunnel monté, le serveur doit se comporter comme un routeur. Trois conditions doivent être réunies en même temps avant qu’un paquet sorte et qu’une réponse revienne, et le symptôme est identique quelle que soit celle qui manque.

Pourquoi un tunnel qui fonctionne n’a toujours pas de sortie

Le noyau doit transférer les paquets entre les interfaces, ce qui est désactivé par défaut sur la plupart des distributions Linux. Le trafic doit être traduit vers une adresse à laquelle le monde extérieur peut répondre, sauf si chaque routeur en amont connaît déjà la route de retour vers le sous-réseau du tunnel. Le chemin de transfert du pare-feu doit autoriser le trafic dans les deux sens, y compris les réponses.

Chacune de ces conditions peut être corrigée séparément, et c’est là le piège. Activer le transfert sans règle de traduction laisse les paquets partir avec une source privée et sans chemin de retour. Ajouter la traduction sans règle de transfert laisse le noyau abandonner le paquet une étape plus tard.

Testez donc les trois couches plutôt que le client, et changez-en une à la fois pour que le résultat ait un sens.

Le transfert est un commutateur du noyau qu’il faut rendre persistant

Vérifiez la valeur actuelle avant de la modifier, puis définissez-la et confirmez que le changement a pris effet.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

La première commande indique la valeur actuelle, la deuxième la définit à l’exécution et la troisième prouve que l’écriture a fonctionné. La valeur à l’exécution disparaît au prochain redémarrage, ce qui explique qu’une session qui fonctionne puisse casser après une maintenance sans aucun changement de configuration.

Rendez-la permanente dans un fichier sous /etc/sysctl.d/, puis appliquez ce fichier plutôt que de redémarrer pour le savoir. Sous FreeBSD, l’équivalent est net.inet.ip.forwarding, avec gateway_enable=YES dans rc.conf pour la persistance. Un appareil qui signale le transfert désactivé explique toute une classe de rapports « des paquets arrivent et rien ne revient ». Vérifiez le réglage après chaque mise à jour aussi, car un noyau reconstruit ou une image d’appareil remplacée peuvent le réinitialiser sans prévenir personne.

Choisissez masquerade ou une adresse de traduction fixe

Avec une adresse extérieure dynamique, masquerading est la forme correcte la plus simple. Nommez le sous-réseau du tunnel comme source et l’interface extérieure comme sortie.

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

Avec une adresse publique statique, la traduction de source vers cette adresse exacte est plus prévisible et plus facile à auditer.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

La seconde forme porte un piège de maintenance : une adresse codée en dur qui change ensuite maintient le tunnel en marche tandis que l’accès à internet s’arrête silencieusement. Utilisez masquerade ou mettez la règle à jour chaque fois que le fournisseur vous déplace. L’interface compte aussi, car un routeur qui partage son propre tunnel amont doit traduire par ce tunnel et non par le WAN physique.

La table de filtrage est la troisième porte

Le transfert et la traduction peuvent être tous deux corrects alors que le paquet meurt encore dans la table de filtrage. ufw est un coupable fréquent : sa politique de transfert est livrée en DROP, et le reste de l’installation peut sembler parfaitement correct alors que ce seul réglage tue le trafic. La relever est une décision de sécurité délibérée et non une case à cocher.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

La première règle autorise le nouveau trafic du tunnel vers l’extérieur, et la seconde uniquement les réponses en retour. Restreignez les deux au sous-réseau du tunnel et à la destination voulue, car une acceptation globale sur l’interface du tunnel transforme le VPN en point de sortie ouvert pour quiconque peut s’authentifier.

Un tunnel ponté demande une autre réponse. L’adresse appartient au pont, pas au port physique, donc asservir l’interface retire l’adresse qu’elle avait auparavant et l’hôte paraît injoignable jusqu’à ce que le pont lui-même en reçoive une, ce que dhclient br0 peut fournir. Cette panne ressemble à un problème VPN et est un problème de couche deux. Vérifiez l’adresse propre du pont avant de toucher au pare-feu, car un changement de filtre ne peut pas réparer un hôte qui n’a plus d’adresse d’où envoyer.

Où regarder quand une page ne charge jamais

Pingez l’adresse du tunnel du serveur pour prouver que le tunnel existe. Puis lancez un traceroute du client vers une adresse publique et lisez où il s’arrête : au serveur, le paquet arrive mais n’est ni transféré ni traduit ; au-delà du serveur, le problème est en amont et hors de vos mains.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

La première commande prouve que le tunnel transporte le trafic jusqu’au serveur lui-même, et la seconde montre jusqu’où un paquet parvient vers l’extérieur. Une trace qui se termine à l’adresse du tunnel désigne le transfert ou la traduction sur le serveur, tandis qu’une trace qui s’arrête un saut plus loin désigne le fournisseur ou la route de retour du routeur amont.

Sur le serveur, surveillez l’interface extérieure pendant qu’un client charge une page. Un trafic qui sort avec une adresse source privée signifie que la traduction manque, et une absence totale de réponse signifie que le chemin de transfert ou la route de retour amont le rejette.

Si des clients distants doivent aussi atteindre des hôtes du LAN du serveur, rappelez-vous que le LAN a besoin d’une route de retour vers le sous-réseau du tunnel. C’est du routage et non de la traduction, et c’est l’étape que l’on oublie le plus souvent une fois que le chemin vers internet fonctionne enfin.