Pourquoi PPTP et L2TP/IPsec s'arrêtent-ils avant la demande du nom d'utilisateur ?
L'absence d'invite de nom d'utilisateur signifie que PPP n'a jamais démarré, donc la panne se situe dans le transport, l'échange de clés ou la mise en place du tunnel. Vérifiez l'ordre des étapes avant de réinstaller.
L'absence d'invite de nom d'utilisateur est un cadeau de diagnostic : PPP n'a pas encore démarré, donc le compte, le mot de passe et la stratégie de domaine n'ont pas encore été consultés. Dans une connexion PPTP ou L2TP/IPsec, le client ne demande les identifiants qu'une fois le tunnel existant et le serveur ayant entamé une session PPP. Tout ce qui peut échouer avant cet instant relève du transport, de l'échange de clés ou de la mise en place du tunnel, une surface bien plus petite que « le VPN est cassé ».
Une invite absente réduit la panne à trois étapes
Notez la dernière étape qui a visiblement réussi, car chacune a un propriétaire et un correctif différents. Deviner les réglages du compte alors que vous êtes bloqué deux étapes plus tôt, c'est ainsi qu'un après-midi disparaît.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
Un client qui expire sans invite n'a jamais obtenu d'association IPsec, donc la panne est dans IKE ou dans le fait que vos paquets atteignent ou non la passerelle. Celui qui annonce vérifier les identifiants puis décroche est allé plus loin que le message ne le suggère. Une invite suivie d'un rejet relève de l'authentification PPP, et cela appartient à un article sur le compte, pas à celui-ci.
Première étape : le protocole qu'un pare-feu abandonne en silence
PPTP a besoin de TCP 1723 pour son canal de contrôle et du protocole IP 47 pour le chemin des données, et les deux voyagent séparément. Beaucoup de réseaux transmettent 1723 et abandonnent le protocole 47, ce qui produit un tunnel qui négocie puis ne transporte absolument rien. Un routeur qui fait du NAT a aussi besoin d'un passage compatible GRE, et un chemin d'accès uniquement IPv6 ne peut transporter PPTP dans aucune configuration.
L2TP sur IPsec dépense le port 500 pour IKE et le port 4500 pour la traversée NAT, puis enveloppe le trafic L2TP lui-même dans 1701, tandis qu'ESP transporte la charge protégée dès que l'association existe. Autorisez les deux ports de contrôle mais pas ESP, et vous obtenez exactement le symptôme du titre : une progression visible, puis un client mort avant toute boîte d'identifiants. Tester depuis un partage de connexion mobile est un moyen peu coûteux de séparer un problème de client d'un problème de chemin.
Deuxième étape : une clé qui n'est pas la clé, une proposition qui n'est pas offerte
Une clé prépartagée qui ne correspond pas échoue vite et discrètement, et la version habituelle est une clé qui paraît correcte à l'écran tout en portant un saut de ligne collé ou un espace final. Sur un client Linux la boîte de dialogue n'est pas forcément la source de vérité : le greffon L2TP de NetworkManager garde les secrets dans des fichiers sous /etc/ipsec.d/, et un ancien fichier par connexion que /etc/ipsec.secrets inclut encore sera utilisé à la place de celui que vous venez de saisir. Copiez ce fichier en lieu sûr, retirez-le du chemin d'inclusion, puis retapez la clé à la main.
L'autre moitié de cette étape est la proposition. Les deux extrémités doivent s'accorder sur le même jeu d'algorithmes de phase 1 — chiffrement, intégrité et groupe Diffie-Hellman — et sur des transformations ESP correspondantes pour la phase 2, sinon l'association ne se forme pas du tout. Une passerelle qui n'offre que 3DES, SHA1 et MODP1024 refusera un client configuré pour des algorithmes plus forts, et son journal nomme la transformation refusée. Le journal nomme la discordance si vous le lisez au lieu de redémarrer le service encore une fois. Plutôt que de copier une chaîne d'algorithmes depuis un fil de forum, demandez à la passerelle quelles transformations elle négociera réellement : ike-scan pointé vers son adresse renvoie les transformations qu'elle négociera. Si la seule offre est une cryptographie que votre politique n'autorise plus, le correctif appartient à la passerelle, pas à une rétrogradation du client.
Sous Windows, la clé et la méthode d'authentification vivent dans le profil VPN, et une discordance apparaît avant l'invite d'identifiants plutôt qu'après. Lorsque le récepteur est un Windows Server, vérifiez que le rôle d'accès distant est installé, que le certificat correspond au nom auquel les clients se connectent et qu'aucun filtre de ports n'est plus étroit que les protocoles ci-dessus.
Troisième étape : le tunnel existe et PPP ne démarre jamais
Quand IKE est terminé et que l'invite n'apparaît toujours pas, regardez le démon du tunnel plutôt que le pare-feu. L2TP a besoin de quelque chose qui écoute sur UDP 1701 — xl2tpd ou kl2tpd sous Linux, le service d'accès distant sous Windows — et un service installé mais arrêté ressemble, côté client, à un paquet abandonné. Vérifiez l'écoute avant de rouvrir des règles que vous avez déjà validées. Ensuite PPP doit négocier, et le premier échange LCP est l'endroit où atterrit généralement un échec silencieux.
Un piège de cette étape n'est pas du tout une panne réseau : Windows n'autorise qu'une seule connexion d'un type de VPN donné à la fois, donc une seconde tentative renvoie l'erreur 937, « une autre connexion de ce type est en cours d'utilisation ». C'est une règle locale, et on la contourne avec un autre appareil, un autre type de tunnel ou en partageant l'unique connexion qui existe déjà.
Lisez le journal dans l'ordre des étapes au lieu de deviner
Arrêtez le client, relancez-le, et lisez les composants dans l'ordre où ils écrivent dans le journal. C'est-à-dire d'abord le démon IPsec — strongSwan ou Libreswan, et ipsec --version vous dit lequel — puis le démon L2TP, puis pppd. Quel que soit le composant qui a écrit en dernier avant la panne, il marque l'étape à examiner, car tout ce qui vient après lui dans la séquence n'a pas tourné du tout.
Vérifiez avec une connexion neuve plutôt qu'avec une session enregistrée, car un client qui se reconnecte depuis le cache peut sauter des parties de l'échange et reproduire un résultat périmé. Confirmez l'accessibilité, l'échange de clés, le tunnel et PPP un par un, dans cet ordre. L'invite absente cesse alors d'être un mystère et devient la deuxième ligne d'une liste que vous pouvez réellement parcourir. Cette liste est aussi ce que vous remettez à l'équipe réseau, à qui l'on demanderait sinon de vérifier le pare-feu pour une panne qui vit dans un démon non démarré.