Comment un transfert local SSH transporte une session TCP OpenVPN

Trois transports s'empilent ici, et chacun a son propre cadrage. La charge utile du VPN voyage dans une session TLS, cette session TLS voyage dans une connexion TCP vers un port de bouclage, et les octets de cette connexion voyagent dans SSH vers un hôte relais, qui ouvre la vraie connexion TCP vers l'écouteur du VPN. Rien dans l'agencement ne change ce que OpenVPN authentifie, et rien dedans ne rend un écouteur UDP joignable par TCP. Lisez la suite comme une description du chemin des octets, pas comme une recette pour contourner un contrôle réseau.

Ce que le transfert local déplace réellement

Le client SSH écoute sur un port local. Quand un processus local se connecte, le client empaquette les octets dans son canal chiffré, et le côté serveur ouvre une nouvelle connexion TCP vers la destination nommée dans la demande de transfert.

Cette destination est résolue par le relais, pas par votre machine, c'est pourquoi un nom qui n'existe qu'à l'intérieur du réseau distant fonctionne encore. Cela signifie aussi que le relais doit pouvoir atteindre l'écouteur du VPN et avoir une route de retour vers lui. Un nom qui se résout sur votre ordinateur portable ne dit rien de ce que le relais peut voir.

Démarrer la session SSH prouve seulement que le relais est joignable et authentifié. Cela ne dit rien sur l'état de l'écouteur suivant, sur l'acceptation de la connexion par un pare-feu entre le relais et l'écouteur, ni sur l'acceptation de votre profil par le VPN.

Dirigez le client vers l'écouteur local

Un exemple déclaré : le relais peut atteindre un écouteur TCP à gw.internal.example:443, et un port local élevé expose ce chemin à cette machine seulement.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

Le manuel d'OpenSSH décrit le transfert local comme l'acceptation locale de connexions TCP et l'ouverture de la connexion suivante depuis le côté distant. Liez l'écouteur à la boucle locale plutôt qu'à toutes les interfaces, car un transfert joignable depuis le réseau est un relais ouvert avec votre nom dessus. Une liaison générique expose aussi le port à tout autre compte local sur une machine partagée.

Puis mettez le client VPN en mode TCP et pointez-le vers 127.0.0.1:24011. Si le profil utilise UDP, cette conception ne peut pas aider : le transfert transporte un flux d'octets, et il n'y a aucun chemin de datagrammes à travers lui.

Gardez les deux authentifications séparées

SSH authentifie l'hôte relais. OpenVPN authentifie toujours le pair VPN, et la destination de bouclage ne change pas cette exigence. Désactiver les vérifications de certificat parce que la socket pointe maintenant vers localhost est le pire raccourci disponible dans cette conception. Il transforme un agencement de transport en agencement de confiance, et personne n'a approuvé le second.

Gardez intacts l'ancre de confiance du profil, le contrôle du rôle de serveur et la vérification du nom. Si votre client compare le nom du serveur à l'adresse qu'il a appelée, la boucle locale peut avoir besoin d'un réglage de nom explicite plutôt que d'un contrôle désactivé, et la documentation du profil est l'endroit où confirmer quel champ est comparé.

Traitez le relais comme une seconde partie dans l'histoire de confiance : son administrateur peut voir les métadonnées de connexion et peut rediriger le transfert si la configuration change. L'agencement a besoin de l'approbation à la fois du relais et du propriétaire du service VPN, pas seulement de celui qui en a besoin aujourd'hui.

Ne construisez pas de boucle sous le tunnel

Une fois que le VPN installe des routes, la connexion SSH qui le transporte a encore besoin d'un chemin vers le relais qui ne passe pas par le tunnel. Si la route par défaut passe au VPN et que le relais n'est joignable que par ce même tunnel, le transport s'effondre et le VPN part avec lui. La panne ressemble à un tunnel tombé plutôt qu'à une erreur de routage, et c'est pourquoi elle est mal diagnostiquée.

Le correctif habituel est une route d'hôte vers l'adresse du relais épinglée à l'interface physique avant la montée du tunnel, plus une vérification que la route survit à une reconnexion. Vérifiez-la par une recherche de route pour l'adresse du relais plutôt qu'en supposant que l'ordre était correct.

Attendez-vous aussi à ce que cette pile soit plus lente et plus fragile qu'une connexion directe, car il y a maintenant deux transports ordonnés et un autre point de terminaison à maintenir. C'est un moyen de franchir une frontière réseau, pas une technique de performance.

Fermez l'écouteur quand vous avez terminé

Arrêtez la session SSH quand le tunnel n'est plus nécessaire, et confirmez que le port local est libéré. Un transfert oublié garde un chemin authentifié ouvert sur une machine qui peut être partagée.

Examinez aussi les destinations de transfert autorisées du relais, car une configuration permissive transforme tout compte compromis en pivot général. Notez le port, le relais et la destination ensemble, pour que la personne suivante sache à quoi servait le transfert et s'il est toujours approuvé.