Pourquoi un seul client VPN se connecte derrière le même routeur

Deux portables se trouvent sur le même réseau domestique, et le VPN du bureau n'en accepte qu'un seul. Le second expire ou attend que le premier se déconnecte, et personne n'a touché à un réglage du client entre les deux tentatives. Les identifiants sont ceux qui fonctionnaient il y a une minute, et c'est l'indice que l'authentification n'est pas la panne. Trois mécanismes produisent ce schéma, et le journal du serveur lui-même indique auquel vous avez affaire.

Lisez le journal de la passerelle avant de toucher un client

L'enregistrement du serveur pour les deux tentatives répond à la première question, et il y répond de l'une de trois manières. Si la seconde tentative n'apparaît jamais dans ce journal, le paquet n'a jamais atteint l'écouteur, et le routeur domestique ou le chemin du fournisseur porte le problème. Si le journal note une tentative et la rejette, le tunnel est arrivé, donc la question est l'identité, la licence ou un plafond de sessions, et non quelque chose sur le fil. Si le journal note une session réussie alors que le client signale encore un échec, regardez le chemin de retour ou le fait que deux clients reçoivent la même adresse de tunnel.

Un partage de connexion depuis un téléphone sépare ces familles à peu de frais : lancez le second client sur les données mobiles pendant que le premier reste connecté. Une réussite là-bas met en cause le réseau domestique, et le même échec là-bas met en cause la passerelle, ce qui laisse le routeur innocent. Aucun des deux résultats n'est concluant seul, mais chacun élimine la moitié de l'espace de recherche en une tentative.

Notez le résultat avant de changer quoi que ce soit, car les trois issues du journal mènent à trois réparations sans rapport. Une note qui nomme laquelle des trois vous avez vue vaut plus qu'une capture d'écran d'erreur du client.

Ce que le routeur fait de GRE et de NAT-T

PPTP est le coupable classique : le canal de contrôle est TCP 1723 tandis que le chemin de données est GRE, le protocole IP 47. Beaucoup de routeurs grand public embarquent un assistant PPTP qui suit une seule connexion de contrôle, si bien qu'un second client derrière le même NAT ouvre son canal de contrôle puis ne reçoit aucun chemin de données. Rediriger un port TCP portant le numéro 47 ne fait rien pour GRE, car GRE est un numéro de protocole et non un port.

L2TP sur IPsec se comporte autrement par conception : IKE utilise UDP 500, la traversée NAT déplace la charge protégée vers UDP 4500, et l'encapsulation existe précisément pour que plusieurs clients derrière une adresse puissent joindre la même passerelle. Cette conception n'empêche pas une passerelle ou un boîtier intermédiaire d'imposer un plafond de sessions par adresse, et depuis le canapé les deux échecs se ressemblent. Le protocole natif de SoftEther connaît la même classe de problème : un routeur sans traversée fonctionnelle accepte le premier client du réseau local et rejette le second. Testez l'ALG ou le commutateur de traversée du routeur dans les deux positions, car un assistant écrit pour un client plus ancien peut corrompre des paquets qu'un client actuel envoie.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Des plafonds d'identité qui ressemblent à des plafonds de transport

Le routeur n'est pas le seul suspect, et le journal le distingue de l'alternative. Quand un serveur OpenVPN fixe un nom commun à une adresse de tunnel, les deux appareils reçoivent cette adresse, et sans duplicate-cn la session la plus récente évince l'ancienne. Activer cette option laisse les deux connectés mais leur laisse une identité, un certificat et une décision de révocation, ce qui est pire qu'il n'y paraît. Le second appareil ne peut alors plus jamais être révoqué seul, si bien qu'un commutateur de confort retire discrètement un contrôle dont vous pourriez avoir besoin plus tard.

Lisez le journal du serveur et son fichier d'état ensemble, car l'un montre la décision d'authentification et l'autre qui est connecté en ce moment. Deux entrées partageant un nom commun et une adresse virtuelle confirment une collision d'identité et non un plafond du routeur. Les passerelles commerciales ajoutent leurs propres plafonds, comme une offre autorisant une seule session simultanée, un nombre de licences ou une règle autorisant une session par adresse publique, et aucun réglage du routeur n'y change quoi que ce soit.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Faites correspondre la réparation à l'entrée du journal

Un rejet dans le journal appelle des identifiants distincts par appareil, une limite plus élevée de la part de celui qui exploite le service, ou un second point de terminaison de passerelle pour une machine. Si aucune seconde tentative n'atteint jamais le serveur, la réparation durable est un routeur qui transmet le protocole et tient plus d'une session, ou un transport que le routeur gère bien, comme un seul flux TCP ou UDP. Choisir entre les deux est une décision sur la durée de vie du matériel, non sur les réglages du client.

Ne copiez pas le profil d'un appareil qui fonctionne sur la seconde machine en considérant l'affaire réglée. Cela transforme un problème de connexion en problème de contrôle d'accès, car un portable perdu ne se distingue plus de la copie encore utilisée. Cela masque aussi la panne d'origine, qui revient dès qu'un troisième appareil apparaît.

Vérifier deux sessions actives

Connectez les deux appareils en même temps, lancez l'application prévue sur chacun, puis reconnectez l'un d'eux et recommencez. Une seconde icône qui apparaît un instant ne prouve rien sur le trafic, et une session qui tombe au bout de dix minutes est un autre défaut avec un autre responsable. Comparez ce que le serveur signale à la fin avec ce que les utilisateurs ont vu, car ces deux récits sont souvent en désaccord.

Si les deux sessions survivent et portent du trafic, la correction tient, et la note que vous avez écrite au début devient l'enregistrement de ce qui n'allait pas. Si une seule survit, revenez à la première étape et vérifiez laquelle des trois issues du journal vous avez maintenant, car la réponse a pu changer. Les assistants du routeur peuvent masquer un problème qui réapparaît sur un autre réseau, tandis qu'un plafond par adresse suit l'utilisateur et non l'appareil. Tester depuis un second réseau est le moyen le moins coûteux de savoir lequel de ces deux cas vous avez réellement corrigé.