Atteindre un site HTTPS uniquement accessible par VPN via un transfert SSH

Une machine dispose déjà d'un accès VPN approuvé, une seconde machine a besoin d'exactement un service HTTPS privé, et un transfert SSH local peut combler cet écart sans donner de tunnel à la seconde machine. Le transfert transporte une seule destination TCP plutôt que tout le réseau, et c'est précisément cette limite qui compte. Parcourez les cinq étapes ci-dessous dans l'ordre, car chacune échoue pour une raison différente et une étape ultérieure ne peut pas rattraper un manque antérieur. Si une condition préalable manque, cette conception ne la résout pas et aucun réglage de commande n'y changera rien.

Étape un : confirmer les trois conditions préalables

Trois choses doivent déjà être vraies avant qu'une commande n'ait d'importance. Il vous faut l'autorisation d'utiliser la première machine comme hôte de transfert, un accès SSH fonctionnel à celle-ci et une politique de serveur qui autorise la destination prévue. Un compte SSH créé pour le transfert de fichiers peut avoir le transfert désactivé, et un serveur qui autorise le transfert peut encore restreindre les destinations accessibles par son intermédiaire. Demandez avant de tester, car utiliser le poste de travail d'un collègue comme point de saut sans accord est un problème de politique, même lorsque la commande fonctionne parfaitement.

Deux commandes règlent la moitié technique de cette liste. La première prouve que le compte et la clé fonctionnent sans invite interactive, et la seconde affiche la politique effective du serveur plutôt que l'exemple commenté dans le fichier de configuration.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Étape deux : lier un port de loopback et garder la session active

Sur la machine qui exécute l'application cliente, ouvrez un transfert local vers le service privé. Liez-le explicitement au loopback afin qu'il ne soit pas publié sur le réseau local, et choisissez un port élevé qu'aucun service local n'occupe déjà. Gardez la session active pendant votre travail, car la fermer ferme l'écouteur. ExitOnForwardFailure transforme une liaison refusée ou un port occupé en sortie immédiate plutôt qu'en session qui reste active sans transfert, et c'est le mode de défaillance qui fait perdre le plus de temps.

La connexion privée est établie depuis l'hôte de saut, donc son DNS, ses routes, sa politique VPN et son accès au service doivent tous fonctionner. La session SSH ne crée pas une joignabilité que l'hôte de saut n'a pas, et elle ne peut pas réparer une route que le VPN n'a jamais poussée. Confirmez l'écouteur là où il se trouve réellement plutôt que de vous fier au silence de la commande.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Étape trois : conserver le nom HTTPS lorsque la socket est locale

Naviguer vers https://127.0.0.1:9443/ change le nom du serveur TLS et l'autorité de l'application. Un certificat émis pour portal.lab.example ne sera pas validé contre une adresse de loopback, et l'erreur obtenue ressemble à un certificat cassé plutôt qu'à un raccourci de transfert. Pour un test en ligne de commande, conservez l'URL réelle et ne changez que la destination de la socket. C'est ce que fait --connect-to, et le manuel de curl documente la forme à quatre champs utilisée ci-dessous.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

Le nom reste dans l'URL, dans la poignée de main TLS et dans l'en-tête Host, tandis que la connexion TCP va vers l'écouteur local. L'option sans proxy maintient le test sur ce transfert plutôt que de laisser un proxy HTTP configuré l'intercepter, et garder la vérification des certificats activée est ce qui rend le résultat significatif.

Étape quatre : savoir ce qu'un seul transfert ne peut pas couvrir

Un seul transfert TCP couvre un port de destination. Une page qui redirige vers un second nom d'hôte, charge des ressources depuis un hôte à l'intérieur du réseau privé ou envoie vers un autre port a besoin de son propre transfert, et chacun d'eux exige le même contrôle de politique que le premier. Les parcours navigateur ajoutent leurs propres exigences, car il faut dire au navigateur d'envoyer le vrai nom vers le port local via une configuration de proxy ou une correspondance locale. Un test en ligne de commande réussi ne prouve donc pas que le navigateur y parviendra, même s'il prouve le chemin.

UDP, la découverte SMB et la connexion au domaine ne passent pas du tout par un transfert TCP. Si le besoin réel est un accès réseau général, cette conception est le mauvais outil et une passerelle d'accès distant prise en charge est le bon choix.

Étape cinq : nettoyer et consigner

Arrêtez la session une fois le test terminé et confirmez que l'écouteur a disparu. Si le port choisi était déjà occupé, choisissez un autre port de loopback inutilisé et mettez à jour ensemble l'URL, la commande de test et la note, plutôt que d'arrêter un service local sans rapport pour libérer le numéro. Laisser un transfert ouvert sur un portable transforme un diagnostic en service non géré.

Notez l'hôte de saut, la destination transférée, le port local et qui a approuvé l'arrangement. Un transfert qui n'existe que dans l'historique shell de quelqu'un est à un redémarrage d'une enquête répétée, et la personne suivante ne saura pas laquelle des trois conditions préalables a déjà été vérifiée.