Adapter le client VPN Linux au protocole de l'équipement ancien

Quatre familles de protocoles couvrent presque tout équipement encore installé en baie, et chacune échoue différemment sous Linux. Les ports publiés et les propositions configurées de l'extrémité distante décident de votre paquet, pas de la distribution que vous exécutez par hasard. Installer ce qu'un message de forum mentionne puis modifier jusqu'à ce que quelque chose se connecte, c'est ainsi qu'un après-midi disparaît. Lisez l'équipement, installez en deuxième, vérifiez en troisième.

Notez ce que publie l'extrémité distante

Notez le protocole, les ports et l'authentification attendus par l'équipement avant d'ouvrir un gestionnaire de paquets. Quatre familles couvrent l'essentiel du matériel ancien, et le tableau ci-dessous est toute la décision sur un écran.

Le manuel et les règles de pare-feu de l'équipement lui-même sont plus fiables que le nom du protocole sur sa page de connexion. Un appareil qui annonce IPsec ne parle peut-être qu'IKEv1, et une version de firmware que personne n'a appliquée est peut-être ce qui finira par ajouter IKEv2. Vérifiez le chemin de données autant que le port de configuration, car c'est là que le matériel ancien et les réseaux modernes divergent. Se tromper à cette étape, c'est déboguer son client contre une fonction que l'autre extrémité n'a jamais eue.

PPTP : prouvez GRE avant de modifier pppd

PPTP sous Linux n'est pas un démon que l'on démarre mais un appel à pppd, et les paramètres de connexion vivent dans un fichier peer nommé que pppd lit lorsqu'il est appelé. Les distributions le paquettent toujours, même si les faiblesses connues du protocole le rendent inadapté à tout ce qui est sensible, alors réservez-le strictement à un équipement qui n'offre rien d'autre. Surveillez GRE pendant que le client négocie, avec une capture courte plutôt qu'une supposition. L'échec qui coûte le plus de temps n'est pas l'authentification mais le chemin de données manquant.

pppd call branch-office
tcpdump -ni any proto gre -c 5

Si la configuration aboutit et que le lien ne transporte jamais de trafic, soupçonnez le chemin GRE avant de toucher aux identifiants. Les groupes de sécurité cloud ont besoin d'une règle explicite pour le protocole 47, et certains réseaux le bloquent totalement sans erreur visible. Testez depuis le réseau que vous utiliserez réellement, pas depuis un laboratoire qui autorise tout.

L2TP/IPsec : une proposition juste vaut mieux que dix tentatives

Lisez le journal du démon plutôt que la boîte de dialogue du bureau, car celle-ci fusionne plusieurs échecs distincts en un seul message. Une erreur NO_PROPOSAL_CHOSEN relève de la première phase : le client a proposé un chiffrement, un hachage ou un groupe Diffie-Hellman que le serveur n'acceptera pas. Énumérez ce que l'équipement prend en charge et écrivez une proposition qui y correspond, car les combinaisons au hasard produisent le plus souvent la même erreur plus lentement. Sur un bureau, le client pratique est le greffon L2TP de NetworkManager avec strongSwan ou Libreswan en dessous.

Une chaîne de proposition qui signifie une chose pour un greffon de bureau peut en signifier une autre pour le démon à qui il confie le travail, alors gardez une syntaxe adaptée à la couche que vous modifiez. Si l'équipement exige aussi un secret de tunnel, c'est une étape distincte de la clé IPsec. Vérifiez laquelle des deux l'interface demande avant d'y saisir quoi que ce soit.

IKEv1 agressif avec XAuth, et le cas du portail

Une extrémité de type FortiGate veut généralement le mode agressif avec XAuth et une adresse en mode configuré, ce qu'un greffon graphique peut ne pas exposer du tout. Le démon natif s'en charge, et le bloc ci-dessous est la forme de cette configuration, pas un fichier complet. Consultez la documentation actuelle du fournisseur pour les valeurs de proposition.

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

Les anciennes versions de strongSwan utilisaient xauth=client là où la version 5 utilise leftauth2=xauth, un extrait copié peut donc échouer sur la seule syntaxe. Pour un portail TLS, openconnect, qui parle le protocole AnyConnect, gère Cisco et la plupart des marques renommées, et il lui faut un périphérique TUN plus les privilèges pour le configurer. Passez l'adresse du portail exactement comme le navigateur l'affiche, y compris tout chemin attendu par l'équipement, puis vérifiez l'adresse attribuée avant de tester quoi que ce soit derrière. Créer l'interface à l'avance supprime une classe de surprises pendant la configuration.

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

Connectez, puis vérifiez dans un ordre fixe

N'exécutez qu'un seul gestionnaire VPN à la fois, car un profil NetworkManager et un démon lancé à la main se disputeront les routes et le DNS. Désactivez le profil avant de tester une connexion manuelle, et confirmez qu'aucune interface de tunnel ancienne ne subsiste. Vérifiez ensuite dans cet ordre : adresse du tunnel, route vers l'unique hôte interne dont vous avez besoin, résolution de noms, et enfin une requête réelle. Une icône verte prouve l'authentification et rien d'autre.

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

Si une étape échoue, arrêtez-vous là au lieu de tester la suivante, car une panne DNS en aval d'une route cassée ne vous apprend rien. Enregistrez une copie du profil qui fonctionne avant d'expérimenter, car un fichier de connexion supprimé se perd facilement et se reconstruit laborieusement. Conservez les valeurs de proposition dans la même note que le modèle de l'équipement et la version du firmware, car cette note fait la différence entre une migration et un projet d'archéologie lorsque le boîtier est remplacé.