Vultr présente Cycle.io comme un moyen de faciliter les opérations d'infrastructure. Lorsqu'un tunnel SSH tombe en panne, commencez pourtant par une preuve simple : à quelle étape la connexion échoue-t-elle ? Ce guide concerne un transfert local déjà prévu vers un service web privé de votre VPS.
1. Dessiner le trajet réellement demandé
Dans cet exemple, votre navigateur contacte le port local 18080, SSH rejoint vps.example.com, puis le VPS contacte son propre port 8080. Remplacez le compte, le serveur et le port distant par ceux de votre service.
Le 127.0.0.1 situé à gauche décrit l'écoute sur votre ordinateur. Celui situé à droite désigne ici la destination vue depuis le VPS. Confondre ces deux côtés conduit à chercher la panne sur la mauvaise machine.
Relevez la commande initiale et le message d'erreur avant de modifier quoi que ce soit. Notez aussi le dernier changement : service redéployé, port déplacé, accès SSH modifié ou ordinateur remis en veille. Cette chronologie est une piste, pas encore une preuve.
2. Relancer un seul tunnel au premier plan
Fermez le tunnel d'essai précédent avec Ctrl+C si vous le contrôlez, puis lancez :
ssh -v -N \ -L 127.0.0.1:18080:127.0.0.1:8080 \ admin@vps.example.com-v fournit des messages de diagnostic ; -N évite d'ouvrir une commande distante. Gardez le terminal visible pendant que vous ouvrez http://127.0.0.1:18080 dans le navigateur local. Utilisez HTTPS à la place si le service cible l'exige ; ne contournez pas un avertissement de certificat.
Si le port local est occupé, identifiez votre tunnel précédent ou choisissez un autre port local libre et adaptez l'adresse du navigateur. Ne terminez pas au hasard un processus que vous n'avez pas identifié.
Si SSH refuse l'authentification, corrigez d'abord le compte ou la clé. Si l'identité du serveur change, vérifiez-la par une voie fiable au lieu de supprimer aveuglément l'avertissement.
3. Vérifier la destination sans l'exposer
Si l'authentification réussit mais la requête échoue ensuite, examinez le service sur le VPS : fonctionne-t-il et écoute-t-il au port attendu ? Faites effectuer ce contrôle dans l'environnement du serveur, car le tunnel doit joindre la destination depuis ce côté.
Une erreur HTTP renvoyée par l'application et une connexion TCP refusée sont des observations différentes. Notez le message exact et l'heure. N'ouvrez pas le port privé au public pour contourner le problème ; cela changerait votre architecture d'accès.
Transmettez une fiche courte avec le trajet prévu, l'étape fautive et le dernier changement connu. Retirez noms de comptes et adresses sensibles avant de partager les diagnostics. Après correction, testez le parcours utile, puis fermez le tunnel temporaire avec Ctrl+C. Le résultat attendu est une connexion fonctionnelle dont vous comprenez chaque extrémité.
Sources : Vultr, OpenSSH — ssh.
Retrouvez-le dans nos publications
Les étapes clés de cet article, en carrousel. Suivez-nous pour découvrir les prochaines. Nos publications sont rédigées en anglais.