Le handshake de PiVPN fonctionne, les pages bloquent : vérifiez la MASQUERADE

Votre téléphone affiche le tunnel comme connecté, le client annonce une adresse privée, et la première page reste bloquée à mi-chargement. Cette combinaison envoie la plupart des gens vers les réglages de chiffrement et la température du processeur, où rien n’est réellement cassé. Le tunnel s’est monté, donc la négociation est terminée ; ce qui a échoué, c’est l’étape suivante, quand le serveur tente de remettre les paquets du client à internet. Suivez le même chemin que ces paquets, et l’incohérence est généralement visible sur une ligne de la table NAT.

Partez de ce que le client peut atteindre et de ce qu’il ne peut pas

Depuis le client connecté, chargez une page qui vit sur l’internet public et notez si elle échoue immédiatement ou bloque à mi-parcours. Ouvrez ensuite une ressource sur l’adresse privée du serveur VPN lui-même et comparez les deux résultats.

Une adresse de tunnel qui répond au ping alors que les sites publics expirent est la signature d’un problème de transfert ou de traduction, pas d’une poignée de main cassée. Le panneau d’état du client ne peut pas les distinguer, car il sait seulement que le canal de contrôle est monté. Vérifiez sur le serveur l’interface du tunnel avec ip -br addr show tun0 et confirmez que l’adresse attribuée au client tombe dans le pool que vous avez configuré. Si le pool et l’adresse du client ne concordent pas, corrigez cela d’abord, car chaque règle ci-dessous correspond au pool.

Ensuite, demandez au serveur quelle interface il utiliserait pour joindre une adresse publique. ip route get 203.0.113.9 imprime l’appareil et la source choisis sur sa première ligne. Notez le nom de cet appareil, car c’est la valeur que la règle NAT doit contenir.

Lisez la règle qui décide si les paquets sortent

MASQUERADE ne réécrit un paquet que lorsque celui-ci quitte par l’interface nommée dans la règle. Une règle limitée à un appareil filaire ne fait rien pour le trafic qui sort en Wi-Fi, et le paquet conserve son adresse source privée jusqu’au routeur amont. Ce routeur n’a aucune route de retour vers votre pool de tunnel, il rejette donc la réponse, et le client voit une connexion qui s’ouvre puis meurt. Le symptôme augmente avec la quantité de page qui arrive avant que la première réponse ne soit nécessaire.

Listez la table vivante et lisez la colonne de l’interface de sortie au lieu de chercher seulement le mot MASQUERADE. La sortie en forme d’ajout est plus facile à comparer qu’une liste formatée :

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Sur un Raspberry Pi qui utilisait autrefois Ethernet et utilise désormais le Wi-Fi, le nom périmé est presque toujours toute l’histoire. L’installateur a enregistré l’appareil présent au moment de la configuration, et le jeu de règles enregistré le rejoue à chaque démarrage. Comparez l’appareil issu de la recherche de route avec celui de la règle avant de changer autre chose. S’ils correspondent, l’interface n’est pas votre problème et vous devriez passer aux compteurs de la dernière section. S’ils diffèrent, la correction est une modification d’un mot dans le fichier de persistance.

Corrigez le jeu de règles enregistré, pas seulement celui en cours

Modifier uniquement la table vivante tient jusqu’au prochain redémarrage, ce qui est exactement assez long pour vous convaincre que le problème est résolu. Les règles qui reviennent au démarrage vivent dans un fichier qu’un paquet de persistance du pare-feu recharge. Sur les images Pi basées sur Debian, ce fichier est généralement /etc/iptables/rules.v4.

Faites une copie avant d’y toucher, puis remplacez l’interface de sortie de la ligne MASQUERADE par l’appareil que vous avez noté, par exemple -o wlan0 au lieu de -o eth0. Laissez la plage source telle quelle, sauf si votre pool de clients a changé. Rechargez et confirmez que la règle nomme maintenant le bon appareil :

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Deux réglages adjacents s’oublient facilement. sysctl net.ipv4.ip_forward doit indiquer 1, et le routeur amont ne doit pas filtrer lui-même les adresses source privées.

Prouvez que la règle se déclenche, puis isolez ce qui reste lent

Les compteurs sont la seule preuve honnête qu’une règle a correspondu. Lancez la liste détaillée, démarrez un téléchargement sur le client et relancez-la. Les colonnes de paquets et d’octets à côté de votre règle devraient augmenter, et une règle qui reste à zéro ne correspond toujours pas. Si les compteurs bougent mais que les pages échouent encore, comparez la plage source au pool réel avec grep -n "^server " /etc/openvpn/server.conf. S’ils bougent et que les pages se chargent mais que le débit est faible, la traduction est faite et le problème restant est ailleurs.

Comparez deux transferts depuis le même client, l’un vers un hôte du réseau local et l’autre par le tunnel vers ce même hôte. Lent dans les deux cas pointe vers le lien montant ou la liaison Wi-Fi du Pi, pas vers le VPN. Lent uniquement par le tunnel pointe vers le MTU et les retransmissions, que vous pouvez inspecter avec ip -s link show tun0 avant de changer le moindre réglage de chiffrement.

Pour annuler l’expérience, restaurez la copie et rechargez-la, puis confirmez que la règle d’origine et ses compteurs sont revenus. Notez l’appareil de sortie et la commande de rechargement dans les notes du serveur, car le prochain changement de lien montant redécouvrira la même incohérence. Une règle qui nomme le mauvais appareil reste invisible jusqu’à ce que le trafic en ait besoin.