Le tunnel VPN ne se connecte jamais : où les paquets s'arrêtent réellement

Le client réessaie sans cesse, le journal s'arrête avant la fin de la poignée de main, et le serveur n'enregistre absolument rien. Ce schéma détourne des identifiants et pointe vers le chemin : quelque chose entre les deux extrémités refuse de transporter le protocole dont le tunnel a besoin. Déterminez où les paquets s'arrêtent avant de toucher à l'une ou l'autre des configurations, car un protocole filtré et un mot de passe erroné produisent la même erreur aimable dans la plupart des clients. Les tests sont classés par coût, le moins cher d'abord.

Prouvez où le trafic s'arrête

Capturez en même temps sur l'interface sortante du client et sur le serveur. Comparez ce qui est parti avec ce qui est arrivé, et notez dans quel sens la différence apparaît.

Rien sur le serveur signifie que le chemin ou le premier NAT écarte le trafic, tandis que des arrivées sans réponses désignent un pare-feu sur le serveur ou une route de retour inexistante. Un routeur qui termine souvent des tunnels ne tient généralement pas de journal utile, la capture devient donc l'enregistrement. Notez le port de destination et le numéro de protocole, car les deux défaillances se ressemblent dans une boîte de dialogue client.

PPTP meurt sans le protocole 47

PPTP transporte le contrôle sur TCP 1723 et ses données dans GRE, qui est le protocole IP 47 et non un numéro de port. Rediriger seulement 1723 produit le résultat classique : la connexion s'authentifie puis se tait, car aucune règle n'existe pour le protocole qui porte la charge utile. Le client ne peut pas distinguer cela d'un mot de passe refusé, c'est pourquoi la capture doit précéder les modifications de configuration.

Le passthrough s'exécute dans le sens inverse d'une redirection entrante, et le firmware utilise assez souvent une seule étiquette pour les deux pour perdre tout le monde. Sur un client Linux, le pare-feu local peut écarter GRE bien avant que le routeur n'intervienne, donc le protocole 47 a besoin de sa propre règle et l'assistant conntrack doit être chargé. L'ufw d'Ubuntu conserve ces règles dans le fichier before, car les règles allow ordinaires ne peuvent pas exprimer un numéro de protocole. Rechargez ensuite le pare-feu au lieu de redémarrer la machine.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP et IPsec derrière deux NAT

L2TP dans IPsec a besoin d'UDP 500 pour l'échange de clés, d'UDP 4500 dès que NAT est détecté, et d'ESP comme protocole 50. Chacun est filtré indépendamment, donc une règle qui en autorise un ne prouve rien sur les deux autres. Deux routeurs en série traduisent chaque paquet deux fois, et les extrémités ne s'accordent plus sur ce qui a été négocié.

Pontez le modem extérieur, ou désactivez le NAT sur le routeur intérieur, pour que l'adresse publique atteigne l'appareil qui termine le tunnel. Là où ni l'un ni l'autre n'est possible, le tunnel doit être lancé depuis l'intérieur de la limite du double NAT, non y être terminé.

Réseaux d'opérateurs et partage d'adresses

Une adresse WAN dans 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 ou 100.64.0.0/10 signifie que le routeur n'a pas d'adresse publique et qu'aucune redirection entrante depuis internet ne peut l'atteindre. Le NAT de niveau opérateur filtre en plus les protocoles qu'il n'attend pas, et GRE est une victime fréquente sur les liaisons mobiles. Comparez l'adresse WAN sur le routeur lui-même, pas celle qu'un site de consultation indique pour un client derrière lui.

Faire tourner le même routeur sur une ligne filaire sépare un constat d'opérateur d'une erreur de configuration en un seul test. Là où l'opérateur refuse le protocole, les options restantes sont un autre transport sur 443 ou un tunnel lancé depuis l'intérieur.

Lisez la liste des écouteurs avant de fermer des ports

Un scan de ports alarmant n'est souvent que le jeu de fonctions livré activé. Inventoriez les écouteurs, associez chaque socket à une fonction, puis désactivez la fonction au lieu de bloquer le port, pour que les deux vues ne divergent pas.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

Les valeurs par défaut de SoftEther sont un bon exemple : TCP 443, 992 et 5555, les fonctions L2TP/IPsec et tunnel DNS ajoutant leurs propres sockets. Désactiver ces fonctions retire les écouteurs au lieu de les cacher, et le test depuis un hôte externe indique si l'opérateur laisse passer le port. Un écouteur qui répond localement peut rester fermé en amont, alors comparez l'adresse WAN du routeur lui-même avec ce que rapporte un service externe.