Sur le serveur domestique, exécutez autossh avec les arguments suivants pour créer un tunnel SSH persistant vers le serveur relais.

Serveur domestique~$ autossh -M 10900 -fN -o "PubkeyAuthentication=yes" -o "StrictHostKeyChecking=false" -o "PasswordAuthentication=no" -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 1.1.1.1:10022 : hôte local : 22 [email protégé]

Le paramètre "-M 10900" précise le port du serveur relayserver qui sera surveillé et qui servira à échanger des données de test lors de la surveillance de la session SSH. Ce port ne doit être utilisé par aucun autre programme sur le serveur relais.

L'option "-fN" est redirigée vers la commande ssh, qui permettra au tunnel SSH de s'exécuter en arrière-plan.

L'option "-o XXXX" indique à la commande ssh ce qui suit :

• Utilisez l'authentification par clé plutôt que l'authentification par mot de passe.
• Accepter automatiquement les clés d'hôte SSH (inconnues)
• Échangez des messages persistants toutes les 60 secondes.
• Envoyez jusqu'à trois messages keep-alive sans recevoir de réponse.

Le reste des paramètres de tunneling inverse SSH sont les mêmes que dans les exemples précédents.

Si vous souhaitez que le tunnel SSH s'ouvre automatiquement au démarrage du système, vous pouvez ajouter la commande autossh ci-dessus à /etc/rc.local.

Conclusion

Cet article explique comment utiliser un tunnel SSH inversé pour accéder Serveur Linux, qui se trouve derrière un pare-feu ou une passerelle NAT protégeant le réseau contre monde extérieur. Il a été démontré comment procéder pour le cas réseau domestique en utilisant un privé virtuel public Serveurs VPS. Vous devez être prudent lorsque vous utilisez cette technique sur les réseaux d'entreprise. Un tel tunnel peut être considéré comme une violation de la politique de l'entreprise car il contourne les pare-feu de l'entreprise et peut ouvrir les réseaux de l'entreprise à des attaques externes. Il existe une forte probabilité que cette approche soit utilisée de manière incorrecte ou à des fins délibérément mauvaises. N'oubliez donc jamais que vous êtes avant tout vous-même responsable de tous les réglages que vous effectuez.

Parfois, ceux qui utilisent le protocole réseau SSH pour télécommande serveur, il est nécessaire d'organiser un VPN. Et cela est nécessaire pour ouvrir un tunnel SSH. Dans cet article, nous verrons de quoi il s'agit, comment créer des tunnels SSH de différentes manières et quels outils sont disponibles pour cela.

Qu’est-ce que le tunneling SSH et pourquoi est-il nécessaire ?

En fait, tout est extrêmement simple. Par exemple, vous disposez d'un serveur distant et d'un ordinateur local. À un moment donné, vous devrez télécharger certaines données sur l'hôte, ou vice versa, télécharger certains fichiers du serveur vers votre ordinateur. Parce que protocole réseau Cela ne fonctionne pas exactement comme une interface Web classique ; vous devrez créer un tunnel SSH pour télécharger les informations. Ce sera comme un canal par lequel vous pourrez échanger des données avec des serveurs, et il existe à la fois un tunnel SSH aller et retour.

Et cela vous aidera à créer des tunnels SSH Technologie VPN. Son essence est que le VPN vous permet de créer des réseaux privés et sécurisés en plus de ceux existants.

C'est ainsi que vous pouvez implémenter un tunnel dans le protocole réseau. Mais pour cela, vous aurez besoin d'un utilitaire spécial, suffisant pour à l'heure actuelle sur Internet. L'un des meilleurs du genre est SSH Tunnel Easy. Nous commencerons par sa critique.

Tunnel SSH facile

Malheureusement, vous ne trouverez pas beaucoup de critiques et de manuels sur la configuration de ce programme en ligne. Le fait est qu'il est populaire à l'étranger et y est vendu entre 30 et 50 dollars. Mais il y a eu beaucoup de « cracks » sur RuNet depuis longtemps, vous allez donc certainement télécharger SSH Tunnel Easy sur votre ordinateur.

La particularité de SSH Tunnel Easy est que ce programme résout complètement le problème de l'utilisateur : il crée un tunnel SSH. Autrement dit, vous n'avez pas besoin de vous précipiter d'une application à l'autre, puisque tout fonctions nécessaires déjà disponible dans SSH Tunnel Easy. Le programme vous permet de configurer non seulement le transfert de données, mais téléchargement automatique fichiers via plusieurs canaux. Sinon, au lieu de SSH Tunnel Easy, vous devriez installer de nombreux programmes qui ne seraient toujours pas capables d'implémenter ce que propose l'application en question.

SSH Tunnel Easy résout le problème des connexions parallèles. Le fait est que lorsqu'ils tentent de se connecter simultanément au serveur via plusieurs canaux parallèles avec une demande de transfert de données, l'hôte SSH ne peut souvent pas le supporter et se bloque. SSH Tunnel Easy empêche le blocage du serveur car il crée un protocole réseau distinct pour chaque canal de téléchargement. Cette solution astucieuse vous permettra de créer des tunnels d'aller et de retour, qui seront divisés en plusieurs branches, ce qui évitera les affaissements et les dysfonctionnements à long terme !

Établir un tunnel et un VPN à l'aide d'OpenSSH

Si vous ne voulez pas chercher des moyens simples, vous pouvez utiliser programme standard OpenSSH pour organiser un tunnel de téléchargement utilisant le protocole réseau SSH. Cette méthode est bien adaptée à ceux qui ont un système d'exploitation installé Système Ubuntu ou Linux. Vous devez d’abord installer OpenSSH. Pour cela, entrez dans la console commande suivante: sudo aptitude install openssh-server.

Le fait est que n'importe quel tunnel, inverse, direct et même multicanal, peut être créé à l'aide de fonctionnalités standards Ouvrez SSH. Mais pour ce faire, vous devez comprendre les capacités de cette application et être capable de configurer ses configurations. Pour créer un tunnel, vous devez au moins autoriser le tunnel à l'intérieur fichier de configuration, qui définit les paramètres du protocole SSH. Pour activer le tunneling, entrez ligne suivante déposer : PermitTunnel point à point. Après cela, vous devrez redémarrer le programme serveur OpenSSH. Pour ce faire, entrez la commande suivante : service ssh restart.

Veuillez noter d'emblée qu'il y a un gros problème avec une telle organisation de tunnels. Et cela réside dans le fait que pour connecter le tunnel, vous devrez vous connecter à l'hôte via un compte super administrateur. Et comme vous le savez, il s'agit d'une violation flagrante des règles de sécurité du protocole SSH. Et bien que l’utilisateur root soit activé par défaut, il n’est pas du tout sécurisé. Si votre mot de passe est volé, vous perdrez tout - le site sera littéralement volé et vidé. Par conséquent, créez un mot de passe crypté très complexe ou activez l'authentification à l'aide de clés publiques.

Une fois connecté en tant que root, vous pouvez créer un tunnel en utilisant ligne de commande. Vous devrez exécuter la commande via sudo ou en tant que root. Et vous devrez enregistrer une action comme -w local_tunnel:reverse_tunnel. Au lieu du tunnel local et de retour, entrez des chiffres. Vous pouvez entrer deux zéros - un tunnel tun0 sera alors créé pour le serveur et le client.

L'étape suivante consiste à configurer deux tunnels afin qu'ils puissent transférer des données entre eux. Voici un exemple de mise en place de tunnels : pour le tunnel serveur - ifconfig tun0 10.0.0.1/30 pointopoint 10.0.0.2, et pour le tunnel client - ifconfig tun0 10.0.0.2/30 pointopoint 10.0.0.1.

Mais ce n'est pas tout. Pour créer un téléchargement automatique de données via un tunnel, vous devez le spécifier dans les paramètres comme passerelle par défaut. Mais dans ce cas, le chemin vers le DNS et le serveur sera perdu. Par conséquent, les passerelles actuelles doivent être enregistrées dans la table de routage via commande d'itinéraire add -host XX.XX.XX.XX gw HH.HH.HH.HH (XX est l'adresse IP du DNS sur une ligne et l'adresse IP du serveur sur l'autre ; et HH est l'adresse IP de la passerelle actuelle qui doit être supprimée dans les deux commandes).

Maintenant, nous supprimons la passerelle actuelle et en ajoutons une nouvelle. Supprimer en utilisant lignes de route par défaut. Et nous en enregistrons un nouveau en utilisant une fonction similaire : route add default gw 10.0.0.1 (dans votre cas, l'IP peut être différente, selon ce que vous avez spécifié lors de la création du tunnel).

Après avoir défini de tels paramètres, tout ce qui ne va pas chaînes standards, est automatiquement redirigé vers un protocole réseau sécurisé via le tunnel. Autrement dit, un tunnel automatique a été créé qui traverse toutes les données et le trafic. Mais un autre problème demeure : le trafic parvient au serveur, mais rien ne lui arrive. Et puis tout ce que vous avez à faire est de configurer la diffusion adresses réseau NAT pour les clients SSH. Pour implémenter cela, vous devez ajouter une nouvelle règle : iptables -t nat -A POSTROUTING -s 10.0.0.2 -j MASQUERADE. Il ne reste plus qu'à activer la redirection IP via le noyau et à configurer son activation à chaque démarrage. Après cela, le tunneling peut être considéré comme réussi ! Comme vous pouvez le constater, avec OpenSSH, tout est beaucoup plus compliqué, mais néanmoins, si vous essayez, alors tout est réel.

VPN ouvert

Bien entendu, la concurrence entre les programmes a fait son travail : vous pouvez désormais créer un canal VPN de plusieurs manières. L’un d’eux est Open VPN. Il peut également être utilisé sous Linux. Ainsi, pour installer Open VPN, vous devrez vous rendre sur le terminal et saisir la ligne suivante : apt-get install openvpn openvpn-docs, après quoi l'application sera téléchargée et installée. Un mot de passe administrateur peut vous être demandé.

Open VPN peut être configuré de différentes manières, en fonction de la complexité globale de la tâche. Par exemple, si vous avez besoin d'un tunneling entre deux ordinateurs, la configuration sera très simple, mais s'il y a plusieurs ordinateurs, vous devrez alors composer avec les configurations.

Ainsi, pour créer un tunnel simple entre deux ordinateurs, vous devrez générer clé spéciale. Cela se fait à l'aide de la requête : openvpn —genkey —secret static.key. La clé créée doit être transférée à la fois sur le serveur et sur le client dans le dossier openvpn généré lors de l'installation, situé dans le répertoire Etc. Dans ce dossier, vous créerez un fichier de configurations, que vous nommerez différemment pour le serveur et le client. Sur le serveur, générez server.conf, et pour le client, écrivez client.conf. Paramètres standards vous pouvez trouver le fichier de configuration sur le site Candidatures ouvertes VPN.

Après avoir ajouté des configurations spéciales que vous copiez depuis le site officiel d'Open VPN, il vous suffira de lancer l'application à la fois sur le serveur et sur l'ordinateur, de vérifier le ping sur le canal et d'activer l'exécution automatique permanente de l'application après avoir activé le système à l'aide du code : chkconfig openvpn activé. Après cela, vous pourrez échanger des données entre le serveur et le client.

D'une part, Open VPN est très application pratique, qui permet de générer rapidement un tunnel entre serveurs, mais d’un autre côté, vous ne pourrez pas créer un VPN pour connecter aussi facilement plusieurs clients à l’hôte. Pour ce faire, vous devrez vraiment sauter par-dessus la tête et vous noyer dans les paramètres - c'est tellement difficile. Il est donc préférable d’utiliser d’autres utilitaires pour résoudre de tels problèmes.

Quels sont les autres moyens de créer un tunnel aller et retour via SSH ?

Les méthodes décrites pour résoudre ce problème ne constituent pas la liste complète des outils dont dispose par défaut un programmeur. Grâce au même Linux, vous pouvez créer un tunnel de plusieurs manières. Et maintenant, nous allons examiner une méthode très simple pour connecter un ordinateur à un serveur distant, ainsi que pour établir une connexion avec un autre ordinateur connecté au SSHD.

Supposons donc que vous deviez vous connecter à un service Internet situé à 10.10.2.1:80. Dans ce cas, l'hébergeur fonctionne via un domaine spécifique, par exemple site.ru. Tout ce que vous avez à faire est de transférer le tunnel via le serveur vers l'adresse IP souhaitée. Et cela se fait à l'aide des commandes -f, -N et -L. Le premier explique au protocole qu'il devra passer en arrière-plan après avoir activé la connexion, le second annule toutes les commandes ultérieures, le troisième redirige les connexions vers un hôte spécifique vers l'adresse IP dont nous avons besoin. Et voici à quoi ressemblera la commande : ssh -f -N [email protégé]-L 8080:10.10.2.1:80.

Comme vous pouvez le constater, c'est une solution assez simple. La méthode que vous choisissez dépend des tâches et de vos compétences !

Publié par : administrateur le 17 octobre 2017

Comment fonctionne le tunneling SSH

Un tunnel SSH, ou SSH Port Forwarding comme l'appelle man(1) ssh, est une fonctionnalité de protocole facultative qui s'exécute au-dessus de la session SSH normale familière. Le tunnel SSH vous permet d'envoyer Paquet TCP d'un côté de la connexion SSH à l'autre côté et diffuser l'en-tête IP à l'avance une certaine règle pendant le processus de transfert.

Il est très simple de comprendre le fonctionnement d'un tunnel SSH : si vous l'imaginez comme une connexion point à point. Tout comme en PPP, tout paquet arrivant à une extrémité de la connexion sera envoyé et reçu à l'autre extrémité du tunnel. De plus, en fonction de l'adresse du destinataire spécifiée dans l'en-tête IP, le paquet sera soit traité par le côté récepteur du tunnel (si le paquet lui est directement destiné), soit acheminé plus loin dans le réseau (si le destinataire est un autre réseau). nœud).

La principale différence entre un tunnel SSH et une connexion PPP est que seul le trafic TCP peut être encapsulé dans un tunnel SSH. (Remarque : il existe quelques astuces pour transmettre UDP sur un socket TCP à l'intérieur d'un tunnel SSH, mais cette solution dépasse le cadre de cet article.)

La deuxième différence est que dans une connexion point à point trafic entrant peut être initié de n’importe quel côté, alors que pour un tunnel SSH, il est nécessaire de définir explicitement le « point d’entrée » du trafic. « Point d'entrée » est un paramètre du formulaire<адрес>:<порт>, indiquant quel socket ouvrir pour entrer dans le tunnel (du côté local ou distant de la session SSH).

En plus du point d'entrée, vous devez en outre préciser une règle de la forme<адрес>:<порт>, selon lequel l'en-tête (plus précisément l'adresse et le port de destination) du paquet TCP doit être réécrit lors de la transmission. Le point d’entrée peut être défini depuis l’une ou l’autre extrémité du tunnel. Les touches –L (local) et –R (distant) sont responsables de ce paramètre. Par local et distant, nous entendons les côtés du tunnel du point de vue du côté d'origine, c'est-à-dire l'hôte qui établit la session SSH.

Cela semble un peu déroutant jusqu'à présent, alors regardons-le avec un exemple spécifique.

Tunnel SSH direct - donnant accès au serveur derrière NAT

Alex travaille comme administrateur système pour une petite entreprise de tartes aux pommes appelée Qwerty Cakes. L’ensemble du réseau de l’entreprise est situé dans un domaine de diffusion 192.168.0.0/24. Pour accéder à Internet, on utilise un routeur logiciel basé sur Linux, dont l'adresse est 192.168.0.1 côté réseau de l'entreprise et 1.1.1.1 côté Internet. Le démon OpenSSD est opérationnel sur le routeur, qui est accessible via le socket 1.1.1.1:22. A l'intérieur du réseau, un portail d'entreprise, sur lequel Alex doit apporter des modifications jusqu'à demain matin Interface Internet. Cependant, Alex ne veut pas rester au travail tard, il veut accéder au portail depuis chez lui depuis son ordinateur personnel avec l'adresse 2.2.2.2.

Alex rentre à la maison et après le dîner établit la connexion suivante avec le routeur de l'entreprise :

Ce qui s'est passé? Alex a établi une session SSH entre les adresses 2.2.2.2 et 1.1.1.1, tout en ouvrant un « point d'entrée » local au tunnel 127.0.0.1:8080 sur son ordinateur personnel :

alex@Alex-PC :~$ sudo lsof -nPi | grep 8080

ssh 3153 alex 4u IPv4 9862 0t0 TCP 27.0.0.1:8080 (ÉCOUTER)

Tout paquet TCP qui atteint le socket 127.0.0.1:8080 depuis l'ordinateur d'Alex sera envoyé via connexion point à pointà l'intérieur d'une session SSH, auquel cas l'adresse de destination dans l'en-tête TCP sera réécrite de 127.0.0.1 à 192.168.0.2 et le port de 8080 à 80.

Désormais, pour accéder au portail de son entreprise, Alex n’a plus qu’à taper dans le navigateur :

Comment vont-ils paquets réseauà l'intérieur d'un tunnel SSH

Examinons de plus près ce qui est arrivé au paquet TCP lors de son passage dans le tunnel SSH :

1. Un paquet TCP avec l'adresse source 127.0.0.1 et l'adresse de destination et le port 127.0.0.1:8080 est entré dans le socket 127.0.0.1:8080, ouvert par processus chut;

2. Le processus ssh a reçu le paquet, conformément à la règle de traduction, a réécrit l'adresse et le port de destination en 192.168.0.2:80 et l'a envoyé au cours de la session SSH à la partie distante 1.1.1.1 ;

3. Le processus sshd sur le routeur 1.1.1.1 a reçu le paquet et, après avoir examiné l'adresse de destination, l'a envoyé à l'hôte 192.168.0.2, tout en réécrivant l'adresse source de 127.0.0.1 à l'adresse de sa propre interface 192.168.0.1, de sorte que le destinataire, qui ne connaît rien de l'existence d'un tunnel SSH, a renvoyé le paquet au routeur, et ne l'a pas envoyé à son propre hôte local 127.0.0.1.

alex@Alex-PC :~$ssh -L

127.0.0.1:8080:192.0.0.2:80 [email protégé]

DANS dans cet exemple, si le portail ou toute autre ressource à laquelle Alex doit accéder était situé sur le routeur lui-même (par exemple, à 192.168.0.1:80), alors la commande ressemblerait à ceci :

Si le service est disponible sur localhost (par exemple, SQL local serveur), vous pouvez alors y accéder :

alex@Alex-PC :~$ssh -L

127.0.0.1:13306:127.0.0.1:3306 [email protégé]

Des constructions comme -L 127.0.0.1:80:127.0.0.1:80 peuvent paraître assez étranges à première vue. Mais ils n’ont rien de compliqué si l’on considère que la décision concernant le routage des paquets est prise du côté distant du tunnel. Vous devez vous rappeler la règle de base : deuxième paire<адрес>:<порт>traitées par le côté distant du tunnel.

Par conséquent, un paquet avec une adresse de destination de 127.0.0.1 dans la règle de traduction sera traité par le deuxième côté de la session SSH, et rien d'autre.

Comme vous l'avez probablement déjà deviné, le point d'entrée du tunnel peut être créé non seulement sur l'interface de bouclage. Si le tunnel doit être rendu accessible non seulement à l'hôte local, mais également aux autres participants du réseau, alors l'adresse réelle de l'interface peut être spécifiée comme adresse de socket.

alex@Alex-PC :~$ssh -L

10.0.0.5:8080:192.0.0.2:80 [email protégé]

L'ordinateur d'Alex, Alex-PC, possède deux interfaces réseau avec les adresses 2.2.2.2 et 10.0.0.5. Pendant le processus d'établissement de session, ssh ouvrira le socket 10.0.0.5:8080 sur l'ordinateur Alex-PC. Alex peut désormais accéder au portail 192.168.0.2:80 depuis son ordinateur portable avec l'adresse 10.0.0.4 et depuis l'ensemble de son réseau domestique 10.0.0.0/24.

Tunnel SSH inversé : exposez vos ressources à Internet

Comme je l'ai déjà dit, le point d'entrée du tunnel peut être ouvert non seulement du côté de l'auteur de la session ssh, mais également du côté distant, c'est-à-dire de celui vers lequel nous établissons une session ssh. Pour ce faire, utilisez l'option -R au lieu de l'option -L. A quoi ça sert ?

Par exemple, pour pouvoir publier service local pour un accès à distance.

L'ordinateur portable d'Alex exécute le serveur Web Apache, disponible sous la version 127.0.0.1, avec une copie de test du portail de l'entreprise. Alex doit donner accès au serveur Web à ses collègues pour tester l'interface. En général, à de telles fins, il serait bien qu'Alex implémente un bac à sable de test plus fiable. Mais comme notre Alex n'est qu'un personnage virtuel dans cet article, pour démontrer le fonctionnement du tunnel SSH, il établit une session entre son ordinateur portable et le routeur Linux. Et l'utilisation du paramètre -R ouvre le port 8080 sur interface interne routeur avec l'adresse 192.168.0.1, qui pointe vers le socket 127.0.0.1:80 de son serveur Web de test.

Comme vous pouvez le voir, sur le routeur, le processus sshd a ouvert le socket local 8080

alex@Routeur : ~$

sudo lsof -nPi | grep 8080

chut

17233 alex 9u IPv4

95930 0t0 TCP 192.168.0.1:8080 (ÉCOUTER)

Voyons ce qui se passe avec un paquet TCP envoyé depuis l'ordinateur 192.168.0.200 vers un portail de test publié sur 192.168.0.1:8080 :

1. Un paquet TCP avec une adresse source de 192.168.0.200 et une adresse de destination et un port de 192.168.0.1:8080 se retrouvera sur le socket 192.168.0.1:8080, ouvert par le processus sshd ;

2. Le processus sshd, après avoir reçu le paquet, conformément à la règle de traduction, réécrira l'adresse et le port de destination de 192.168.0.1:8080 à 127.0.0.1:80 et l'enverra au cours de la session SSH à la partie d'origine 2.2. 2.2 ;

3. Le processus ssh sur l'ordinateur portable d'Alex, après avoir reçu le paquet et consulté son adresse de destination, réécrira l'adresse de l'expéditeur de 192.168.0.200 à son adresse de bouclage et l'enverra au socket local 127.0.0.1:80, ouvert par Apache. processus.

Comme vous pouvez le constater, les règles de diffusion sont très simples. L'hôte qui ouvre le socket pour le tunnel traduit l'adresse et le port de destination conformément à la règle de traduction. L'hôte du côté opposé du tunnel modifie l'adresse source et le port en fonction de sa table de routage. La table de routage est nécessaire, d'une part, pour envoyer le paquet dans la bonne direction, et, d'autre part, pour remplacer l'adresse source par l'adresse de l'interface à partir de laquelle le paquet sera envoyé.

Une note importante que j'ai laissée à la fin de l'article.

Si, lors de l'ouverture d'un point d'entrée de tunnel, localhost est utilisé à la place de l'adresse de l'interface réelle, alors il peut être omis, raccourcissant ainsi la commande avec

alex@Alex-PC :~$ ssh -L 127.0.0.1:8080:192.0.0.1:80 [email protégé]

à

alex@Alex-PC:~ssh -L

8080:192.0.0.1:80 [email protégé]

Ce caractéristique importante la syntaxe nous sera utile dans l’exemple suivant.

Double tunnelage

Regardons un peu plus exemple complexe. Un utilisateur SQL-Tester situé derrière NAT doit accéder à la base de données sur serveur SQL, qui est également derrière NAT. SQL-Tester ne peut pas établir de connexion directement avec le serveur, car il n'existe aucune traduction correspondante dans le réseau du serveur NAT. Cependant, depuis les deux hôtes, vous pouvez établir une session SSH avec le serveur intermédiaire 3.3.3.3.

Depuis le serveur SQL, nous établissons une connexion SSH avec le serveur 3.3.3.3 et ouvrons le port 13306 sur l'interface de bouclage du serveur 3.3.3.3, qui fait référence au service SQL local exécuté sur le socket local 127.0.0.1:3306 du serveur SQL. :

dbuser@SQL-server :~$ ssh -R 13306:127.0.0.1:3306

[email protégé]

Maintenant, à partir de l'hôte client SQL-Tester, nous établissons une connexion avec 3.3.3.3 et ouvrons le port 3306 sur l'interface de bouclage du client, qui, à son tour, fait référence à 127.0.0.1:13306 sur le serveur 3.3.3.3, qui... fait référence à 127.0.0.1:3306 sur le serveur SQL. C'est simple.

testeur@SQL-Tester :~$ ssh -L

3306:127.0.0.1:13306 [email protégé]

Tunnel dynamique - SSH en tant que proxy Socks

Contrairement aux tunnels avec indication explicite des règles de traduction, un tunnel dynamique fonctionne selon un principe complètement différent. Au lieu de spécifier un mappage adresse:port un à un pour chaque adresse et port de destination, vous ouvrez un socket du côté local de la session SSH, qui transforme votre hôte en serveur proxy SOCKS4/SOCKS5. Jetons un coup d'oeil

Exemple:

Créez un socket tunnel dynamique 127.0.0.1:5555 sur l'hôte client dans une session SSH vers le serveur 2.2.2.2

utilisateur@client :~$ ssh -D 5555 [email protégé]

Vérifier que le port est ouvert

utilisateur@client :~$ sudo lsof -nPi | grep 5555

7284 utilisateur 7u

IPv4 0x74fcb9e03a5ef5b1 0t0 TCP 127.0.0.1:5555 (ÉCOUTER)

Et nous enregistrons le proxy dans les paramètres du navigateur ou de tout autre logiciel prenant en charge le proxy SOCKS.

Désormais, tout le trafic du navigateur passera par le proxy SOCKS au sein d'une connexion SSH cryptée entre les hôtes 1.1.1.1 et 2.2.2.2.

Comment utiliser SSH sur Microsoft Windows ?

Après avoir lu l'article, vous déciderez peut-être que tous les avantages des tunnels SSH ne sont disponibles que pour les utilisateurs de systèmes de type Unix. Cependant, ce n’est pas vrai. Presque tout Clients terminaux pour Windows exécuté via le protocole SSH prend en charge le tunneling.

Depuis quelque temps, il est possible d'utiliser Windows non seulement comme Client SSH. Il est possible d'installer un serveur SSH sous Windows.

Quand utiliser les tunnels SSH ?

Bien entendu, pour créer des tunnels permanents sur les serveurs de combat, vous devez utiliser un outil spécial logiciel. Mais pour solution rapide Pour les tâches de redirection de port, de dépannage, d'obtention d'un accès distant rapide et généralement de résolution d'un problème spécifique « ici et maintenant », l'utilisation des tunnels SSH est souvent d'une grande aide.

Avec leur aide, vous pouvez construire des réseaux entiers, des tunnels dans les tunnels et combiner des types de tunnels. Cela peut vous permettre d’accéder rapidement à des endroits qui semblent impossibles à atteindre.

N'importe qui administrateur du système vous devez constamment travailler à distance, mais il existe des situations où vous avez un besoin urgent de vous connecter aux nœuds réseau interne, dont l'accès est fermé de l'extérieur. C'est bien s'il y a accès à d'autres nœuds d'un réseau donné, mais il arrive que l'accès depuis réseau mondial non du tout, dans ces cas, ils utilisent généralement TeamViewer ou un logiciel similaire, mais s'il est possible de se connecter à un tel réseau via SSH ou d'établir une connexion avec un serveur SSH intermédiaire, alors vous pouvez organiser l'accès rapidement et facilement sans impliquer des tiers. logiciel de fête.

Très souvent, lorsqu'il s'agit d'accéder à distance à des réseaux à faible niveau de sécurité, la première chose qui vient à l'esprit est un VPN, cependant, pour des raisons de connexions administratives, il n'est pas toujours conseillé d'installer un VPN, surtout si nous parlons deà propos de l’externalisation ou de « l’administrateur entrant ». De plus, les conditions de communication ne permettent pas toujours une connexion VPN stable, surtout si vous devez utiliser les réseaux mobiles.

De plus, dans presque tous les réseaux, vous pouvez trouver un appareil ou un serveur accessible via SSH, ou il existe un tel serveur intermédiaire, par exemple un VPS sur le réseau mondial. Dans ce cas excellente solution Il y aura des tunnels SSH qui faciliteront l'organisation de canaux de communication sécurisés, y compris via des nœuds intermédiaires, ce qui éliminera le problème de disposer d'une adresse IP dédiée.

À proprement parler, les tunnels SSH ne sont pas des tunnels à part entière et ce nom doit être considéré comme un nom stable qui s'est développé dans le milieu professionnel. Le nom officiel de la technologie est Redirection de port SSH- c'est une fonctionnalité facultative Protocole SSH, qui permet de transmettre un paquet TCP d'un côté d'une connexion SSH à l'autre et pendant le processus de transmission, de diffuser l'en-tête IP selon une règle prédéterminée.

De plus, contrairement aux tunnels VPN, qui permettent de transmettre n'importe quel trafic dans n'importe quelle direction, le tunnel SSH possède un point d'entrée et ne peut fonctionner qu'avec des paquets TCP. En fait, cela ressemble beaucoup à la redirection de port (comme son nom officiel l’indique), uniquement via le protocole SSH.

Regardons plus en détail le fonctionnement du tunnel SSH. A titre d'exemple, prenons le cas classique de la fourniture d'un accès à un serveur distant via le protocole RDP.

Disons qu'il y a un serveur cible avec l'adresse 192.168.0.105 sur le réseau distant, mais qu'il n'y a pas d'accès depuis le réseau externe, le seul appareil auquel nous pouvons nous connecter est un routeur avec l'adresse 192.168.0.1 avec lequel nous pouvons établir une connexion SSH.

Attardons-nous sur très point important: définit tous les paramètres du tunnel SSH initiateur connexions, alias Client SSH, la deuxième extrémité du tunnel est toujours le serveur auquel on se connecte, alias Serveur SSH. Dans ce contexte, le client et le serveur doivent être compris uniquement comme des côtés de la connexion. Par exemple, un serveur VPS peut agir en tant que client SSH et l'ordinateur portable d'un administrateur peut agir en tant que serveur SSH.

Le point d'entrée peut être situé à n'importe quel côté connexion, un socket TCP y est ouvert avec paramètres spécifiés, qui acceptera les connexions entrantes. Le point de sortie ne peut pas accepter de connexions, mais achemine uniquement les paquets conformément aux règles de traduction.

Regardons le schéma ci-dessus. Nous avons établi un tunnel SSH avec machine localeÀ au routeur distant, en spécifiant local point d'entrée 127.0.0.1:3389 Et règle de traduction 192.168.0.105:3389. Encore une fois, nous attirons votre attention sur le fait que la règle de traduction n'indique pas le point de sortie, mais détermine le nœud vers lequel les paquets seront envoyés à la sortie du tunnel. Si vous spécifiez une adresse non valide ou si l'hôte n'accepte pas les connexions, le tunnel SSH sera établi, mais il n'y aura aucun accès à l'hôte cible.

Selon le point d'entrée spécifié, le service SSH créera un socket TCP local qui écoutera les connexions sur le port 3389. Par conséquent, dans la fenêtre de connexion RDP, nous spécifions comme destination hôte local ou 127.0.0.1 , Le client RDP ouvre un port dynamique et envoie un paquet avec l'adresse de destination 127.0.0.1:3389 et l'adresse source 127.0.0.1:61256 , il ne sait rien de la véritable destination du destinataire du paquet.

Depuis le point d'entrée ce paquet sera envoyé de l'autre côté du tunnel SSH, et l'adresse de destination selon les règles de traduction sera modifiée en 192.168.0.105:3389 , et le serveur SSH prendra une autre décision en fonction de sa propre table de routage, en remplaçant l'adresse source par la sienne, sinon le serveur cible tentera d'envoyer un paquet de réponse à l'adresse locale.

Ainsi, le client RDP fonctionne avec un socket local et les paquets RDP ne dépassent pas ce nœud ; à l'intérieur du tunnel, ils sont transmis via le protocole SSH sous forme cryptée, mais une connexion RDP régulière est établie entre le serveur SSH et le serveur RDP sur le réseau 192.168.0.0 , sous forme ouverte. Ceci doit être pris en compte lors de l'utilisation de protocoles non sécurisés, en gardant à l'esprit que si la règle de traduction pointe au-delà du nœud avec le point de sortie, alors une telle connexion (entre le point de sortie et le nœud de destination) ne pas se défendre via SSH.

Ayant compris aperçu général comment fonctionnent les tunnels SSH, passons à options pratiques leur utilisation, nous considérerons les systèmes Linux de la famille Debian/Ubuntu comme une plate-forme, mais tout ce qui est indiqué ci-dessous, avec des modifications mineures, sera valable pour tout système de type UNIX.

Tunnel SSH avec point d'entrée local

Tunnels avec point local les logins sont utilisés pour accéder aux nœuds d'un réseau distant s'il est possible d'établir une connexion SSH avec l'un de ses nœuds, ce qui suppose que le réseau distant dispose d'une adresse IP dédiée.

Nous considérerons la même option, une connexion RDP à un serveur distant, la ligne pointillée orange dans le schéma indique une connexion SSH sécurisée et les flèches bleues indiquent une connexion TCP standard.

Dans la version la plus simple, on établit simplement une connexion du PC client vers un routeur sur un réseau distant, en précisant le nœud cible dans la règle de traduction :

Ssh-L 127.0.0.1:3389:192.168.0.105:3389 [email protégé]

Clé -L indique que le point d'entrée est localisé localement, puis un deux-points indique l'adresse et le port du point d'entrée et l'adresse, le port de la règle de traduction. Le point de sortie est le nœud auquel on se connecte, c'est-à-dire rt.exemple.com.

Si votre réseau dispose également d'un routeur (ou autre serveur Linux), alors vous pouvez en faire un point d'entrée, qui permettra à n'importe quel client RDP de réseau local. En théorie, pour ce faire, il faudrait creuser un tunnel comme ceci :

Ssh-L 192.168.31.100:3389:192.168.0.105:3389 [email protégé]

Dans ce cas, le service SSH devrait ouvrir un socket TCP sur l'interface 192.168.31.100, mais en pratique cela n'arrivera pas. Cela est dû aux fonctionnalités d'implémentation d'OpenSSH, qui est le standard pour la grande majorité des systèmes de type UNIX.

Par défaut, OpenSSH ouvre un point d'entrée seulement sur interface locale . Il est facile de vérifier ceci :

Afin de donner accès à un socket TCP depuis des interfaces externes, vous devez utiliser la clé -g, ou ajouter à fichier de configuration /etc/ssh/sshd_config option:

Ports de passerelle oui

Cependant, après cela, le socket acceptera les connexions de n'importe lequel Interface réseau de l'initiateur :

Cela signifie que le port 3389 sera ouvert à tous interfaces réseau, donc si le point d'entrée est un périphérique Edge, vous devez alors restreindre l'accès au socket, par exemple en utilisant iptables. Par exemple, bloquons l’accès depuis le réseau externe (interface eth0) :

Iptables -A INPUT -i eth0 -p tcp --dport 3389 -j DROP

Ainsi, le tunnel de travail doit être surélevé avec la commande :

Ssh -L -g 3389:192.168.0.105:3389 [email protégé]

Veuillez noter encore une chose : si le point d'entrée correspond à l'interface locale, et pour OpenSSH c'est toujours le cas, alors il peut être omis en démarrant immédiatement la commande depuis le port du point d'entrée.

Nous vous recommandons également d'utiliser la clé si possible -g, plutôt que d'ajouter l'option au fichier de configuration, car dans ce dernier cas vous risquez, en oubliant ce paramètre, d'ouvrir l'accès aux services non protégés du réseau distant au monde extérieur.

Tunnel SSH avec point d'entrée distant

Un tunnel avec point d'entrée distant permet au contraire de publier n'importe quel service local sur un réseau distant ; une des utilisations les plus courantes est l'accès à un réseau sans adresse IP dédiée, cependant, cela nécessite une IP « blanche » de le réseau de l'administrateur.

Dans la première option, le serveur distant établit lui-même une connexion avec le routeur du réseau local. Cela peut être fait avec une simple commande :

Ssh-R 3389:127.0.0.1:3389 [email protégé]

La clé -R spécifie d'ouvrir le point d'accès depuis le côté distant du tunnel, puis nous spécifions le port pour le socket TCP et la traduction, puisque les paquets arrivant au point de sortie doivent être traités localement, nous spécifions également l'interface locale.

Le lecteur attentif remarquera que nous n'avons pas précisé la clé -g, oui, c'est vrai. Le fait est que pour les tunnels avec point d'entrée distant, cette clé n'est pas applicable et vous devez utiliser l'option

Ports de passerelle oui

du côté du serveur SSH.

Pour des raisons de sécurité, nous vous recommandons d'utiliser ce paramètre avec la politique par défaut DROP pour la chaîne INPUT, cela évitera une publication accidentelle sur interface externe services et ressources internes. Dans une configuration minimale, vous devez ajouter quatre règles au tout début de la chaîne INPUT :

Iptables -P BAISSE D'ENTRÉE
iptables -A ENTRÉE -i eth0 -m état --étatÉTABLI, RELATIF -j ACCEPTER
iptables -A INPUT -i eth1 -j ACCEPTER
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPTER

Le premier définit la politique de refus par défaut pour les paquets entrants, le second autorise les paquets entrants initiés par l'hôte lui-même (réponses aux paquets sortants) et le troisième autorise toutes les connexions du réseau local. Enfin, la quatrième règle ouvre le port 22 pour les connexions SSH entrantes ; de la même manière, vous pouvez ouvrir n'importe quel autre port pour les connexions externes ;

La deuxième option présentée dans le schéma prévoit que le tunnel SSH soit monté par les routeurs du réseau, dans ce cas la commande ressemblera à ceci :

Ssh-R 3389:192.168.0.105:3389 [email protégé]

Attirons encore une fois votre attention sur le fait que notre point d'entrée est situé de l'autre côté du tunnel, la diffusion est donc indiquée du côté de l'initiateur du tunnel, c'est-à-dire V dans ce cas Le client SSH établit deux connexions : une SSH avec rt.example.com et la seconde RDP avec 192.168.0.105, alors qu'avec un tunnel avec un point d'entrée local, l'initiateur établit une seule connexion avec le serveur SSH.

Double tunnel SSH

Très souvent, des situations surviennent lorsque vous devez connecter deux nœuds qui n'ont pas d'adresses IP dédiées. Dans ce cas, TeamViewer ou un logiciel tiers similaire est généralement utilisé, mais si vous avez serveur disponible avec une adresse IP dédiée, vous pourrez alors le faire plus facilement.

Faisons attention au schéma ci-dessus. SSH permet de construire des chaînes entières de tunnels, reliant le point d'entrée du suivant au point de sortie du précédent. Ainsi, afin d'obtenir un tunnel du PC administrateur vers le serveur RDP, avec les deux nœuds ayant des adresses IP grises, nous devons créer deux tunnels avec un nœud intermédiaire.

Tunnel avec un point d'entrée local sur le PC admin :

Ssh-L 3389:127.0.0.1:3390 [email protégé]

Et un tunnel avec un point d'entrée distant sur le serveur RDP :

Ssh-R 3390:127.0.0.1:3389 [email protégé]

Nous avons spécifiquement indiqué sur le serveur distant port non standard Pour plus de clarté, voyons maintenant comment tout cela fonctionne. Commençons par le serveur RDP ; il lève un tunnel avec un point d'entrée distant, ouvrant un socket TCP sur le serveur intermédiaire qui acceptera les connexions sur le port 3390 ; nous spécifierons le serveur RDP lui-même comme diffusion - 127.0.0.1:3389, c'est-à-dire tous les paquets arrivant à l'entrée de ce tunnel seront dirigés vers port local 3389.

Un tunnel avec un point d'entrée local sur le PC de l'administrateur ouvre un socket local sur le port 3389, où le client RDP se connectera en diffusion, nous précisons le point d'entrée du deuxième tunnel - 127.0.0.1:3390.

Comme nous l'avons déjà dit, il n'y a aucune restriction sur le nombre de tunnels dans la chaîne, mais dans la pratique, le besoin de tunnels avec plus d'un nœud intermédiaire se pose assez rarement. Il ne faut pas oublier qu'à chaque nouveau nœud intermédiaire, la fiabilité de l'ensemble du circuit diminuera et la vitesse finale sera limitée à la vitesse de la section la plus lente du chemin.

Tunnel SSH dynamique

Contrairement à ceux évoqués ci-dessus, un tunnel dynamique fonctionne différemment : il ouvre un socket TCP local sur l'hôte, qui peut être utilisé comme proxy SOCKS4/SOCKS5 pour accéder à Internet via un serveur SSH distant. Cela peut être utile pour contourner certaines restrictions, lorsqu'il n'est pas nécessaire d'installer un VPN à part entière dans une autre juridiction et que vous ne pouvez pas utiliser de proxys publics ou de VPN pour des raisons de sécurité.

Ce type de tunnel est particulièrement pratique si vous avez besoin d'un accès unique à Internet depuis un autre nœud. Un exemple simple : un bon ami à moi a apporté deux iPhones sous contrat avec un opérateur des États-Unis et a demandé à les déverrouiller. Problèmes cette opération Ce n'est pas un secret, si les termes du contrat n'ont pas été violés, il suffit de se rendre sur le site de l'opérateur et de remplir une demande de déverrouillage. Mais le problème s'est avéré être que l'opérateur T-Mobile n'avait accès à cette section du site que pour les résidents américains, et les connexions provenant de proxys publics et de VPN ont été rejetées comme dangereuses.

Un tunnel SSH dynamique a permis de résoudre rapidement ce problème grâce aux VPS aux States. Pour créer un tel tunnel, entrez la commande :

Ssh-D1080 [email protégé]

Où 1080 est le port sur lequel notre proxy SOCKS sera disponible. Il ne reste plus qu'à configurer le navigateur pour utiliser un serveur proxy local.

Un autre avantage de cette méthode est que le serveur proxy n'existe que localement sur votre hôte, pas de ports supplémentaires dans réseau externe il n'est pas nécessaire de l'ouvrir et il n'y a qu'une connexion SSH entre le client et le serveur.

Cela vous permet de cacher la nature de votre activité Internet à un observateur extérieur, ce qui peut être utile dans réseaux publics, lorsqu'il existe des motifs raisonnables de croire que le trafic peut être intercepté et analysé par des tiers. Dans ce cas, le tunnel SSH fournit cryptage fort données transmises sur un réseau non sécurisé, mais cela nécessite confiance totale au serveur par lequel vous accédez à Internet.

Quelques mots sur la sécurité

Bien que cela dépasse le cadre de l'article, nous ne pouvons mentionner une seule fonctionnalité qui puisse apporter beaucoup mauvaises surprises. En augmentant le tunnel SSH à l'aide d'une des commandes ci-dessus, vous obtiendrez également, en plus du tunnel, console ouverte sur le serveur auquel vous vous connectez. Examinez attentivement la ligne d'invitation dans la capture d'écran ci-dessous.

En haut, nous voyons l'invitation de l'hôte local, et en bas, après avoir monté le tunnel, nous voyons l'invitation du serveur distant. Ceci est pratique si vous devez vérifier le canal de communication ou effectuer certains réglages depuis le côté distant, mais dans la vie ordinaire, cela peut entraîner de graves problèmes si vous oubliez ou ne faites pas attention au serveur auquel la console est connectée et exécutez les commandes prévues. pour nœud local, surtout si vous vous connectez avec les droits de superutilisateur.

Par conséquent, après avoir vérifié la fonctionnalité du tunnel, vous devez le démarrer avec le commutateur -N, qui interdit l'exécution de commandes sur le serveur distant, par exemple :

Ssh -N -L -g 3389:192.168.0.105:3389 [email protégé]

Et, bien sûr, vous ne devez pas utiliser un compte superutilisateur pour vous connecter au serveur ; il est préférable de créer un compte régulier à ces fins.

Tunnels SSH sous Windows

Tout au long de l'article, nous avons examiné les tunnels SSH en utilisant l'exemple des systèmes Linux et Utilisateurs Windows on pourrait avoir l’impression que ces opportunités ne leur sont pas accessibles. Mais ce n'est pas vrai ; il existe de nombreux clients SSH pour Windows qui prennent en charge la création de tunnels. Nous considérerons le plus populaire d'entre eux - PuTTY. Vous pouvez également exécuter un serveur SSH sous Windows, mais cela nécessite certaines qualifications et n'est pas toujours possible à réaliser. fonctionnement stable, nous n’envisagerons donc pas cette option.

Ouvrons PuTTY et sur le côté gauche de l'arborescence, allez à Connexion - SSH - Tunnels:

La fenêtre suivante s'ouvrira devant nous, les principaux paramètres du tunnel sont concentrés en bas, et nous les avons mis en évidence avec un cadre rouge. Port source- est destiné à indiquer le port du point d'entrée, qui est toujours situé sur l'interface locale (127.0.0.1). Destination- diffusion, c'est-à-dire où les paquets seront envoyés depuis le point de sortie. Commutateurs radio Local - Distant - Dynamique définir le type de tunnel et sont similaires aux clés -L,-R Et -D.

Après avoir rempli tous les champs obligatoires, vous pouvez ajouter un tunnel en utilisant le bouton Ajouter. Pour autoriser les hôtes externes à accéder au socket du point d'entrée local, cochez la case Les ports locaux acceptent les connexions d'autres hôtes. Dans ce cas, vous devez également limiter l'accès à ports ouvertsà l'aide du pare-feu Windows ou d'un filtre réseau tiers.

Le serveur auquel nous nous connectons est spécifié dans une section différente - Session, familier à tous ceux qui ont déjà utilisé PuTTY, où vous pouvez enregistrer les paramètres de session pour une utilisation future.

Comme vous pouvez le constater, SSH offre à l'administrateur un outil flexible et puissant pour sécuriser accès à distance sans avoir besoin d'ouvrir des ports ou d'organiser des canaux VPN. Nous espérons que ce matériel vous sera utile et vous permettra de maîtriser de nouvelles capacités d'outils apparemment familiers.

• Balises :

Veuillez activer JavaScript pour afficher le

SSH-le tunneling peut être utile non seulement lorsqu'il est nécessaire de transmettre du trafic non crypté via une connexion cryptée, mais également lorsque vous n'avez pas accès à une ressource sur le réseau, mais que l'accès est nécessaire.

Examinons la création et la configuration de plusieurs options.

Et donc, nous avons un serveur, appelons-le hôte-1. Pour lui, nous avons accès complet seulement par SSH- mais nous devons ouvrir Matou, opérant sur le port 8082 - vers lequel ils ne peuvent pas nous laisser passer.

Nous considérerons l'option avec réglage Fenêtres Et Mastic.

Ouverture SSH- connexion à au serveur requis, connectons-nous.

Nous précisons les paramètres suivants :

Port source : tout port inutilisé sur votre système ;
Port de destination : 127.0.0.1:8082

Cliquez Ajouter, Alors Appliquer.

Accédez aux paramètres du navigateur et définissez les paramètres du proxy :

Il ne reste plus qu'à ouvrir la page http://localhost:3002 dans le navigateur - et on arrive à la page Matou sur le serveur hôte-1.

Si le tunnel ne fonctionne pas, vérifiez sur le serveur si le transfert de paquets est activé. Dans le fichier /etc/ssh/sshd_config, recherchez et décommentez la ligne :

AllowTcpForwarding oui

Et en redémarrant SSHd :

# service sshd restart Arrêt de sshd : [ OK ] Démarrage de sshd : [ OK ]

Un autre exemple - nous avons le même serveur externe, à partir duquel il existe un accès normal à toutes les ressources sur Internet. Mais depuis le lieu de travail auquel nous avons accès et qui est fermé.

Nous effectuons des actions similaires, mais avec de légères différences. Paramètres dans Mastic:

Port source - laissez le même, mais à la place Locale- choisir Dynamique. Cliquez Ajouter, Appliquer.

Passons aux paramètres du navigateur :

Veuillez noter que le type de proxy ici n'est pas HTTP, mais SOCKS.

Profitez de l'accès à vos sites préférés.

Et un cas plus intéressant.

Nous avons le même hôte-1. En plus, il y a un deuxième serveur, appelons-le hôte-2. De plus, nous disposons d'une machine avec Fenêtres, qui doit avoir accès à la ressource ÉquipeCité sur le serveur hôte-1 sur le port 8111. Dans ce cas, l'accès depuis Fenêtres-nous n'avons que des machines pour le serveur hôte-2, et uniquement sur le port 22.

Pour commencer, nous élevons le tunnel entre hôte-1 Et hôte-2. Nous effectuons sur hôte-1:

$ ssh -f -N -R hôte-2:8082:localhost:8111 nom d'utilisateur@hôte-2

Nous ouvrons donc un tunnel qui localement (sur hôte-1) regarde le port 8111, et de l'autre côté se trouve la machine hôte-2, sur lequel le port 8082 s'ouvre et attend les connexions entrantes. Lors de la réception de paquets sur le port 8082 (et uniquement via l'interface lo0 ! c'est important) - il les redirigera vers la machine hôte-1 port 8111.

Concernant l'interface lo0. Une fois installé SSH-tunnel, même en spécifiant l'adresse IP externe de la machine - la connexion est établie uniquement à partir de localhost, c'est-à-dire 127.0.0.1 .

Regardons hôte-2:

$ netstat -anp | grep 8082 tcp 0 0 127.0.0.1:8082 0.0.0.0:* ÉCOUTER -

Pour changer cela, vous devez éditer le fichier de configuration du démon sshd - /etc/ssh/sshd_config et modifier le paramètre :

#GatewayPorts non

Mais nous ne le ferons pas maintenant, ce n'est qu'une note.

Continuons. Passons à la configuration Mastic sur notre Fenêtres-voiture. Tout est simple ici - nous utilisons l'exemple 1 de cet article, remplacez simplement le port par celui souhaité (dans la capture d'écran, d'ailleurs, il est là). Connectons-nous Masticà l'hôte hôte-2, installation tunnel. Modifier les paramètres dans le navigateur procuration— et nous obtenons ce dont nous avons besoin, précisez l'adresse http://localhost:3002 :

SSH est assez sensible à la perte de paquets, les tunnels peuvent donc être abandonnés fréquemment.

Pour éviter cela, vous pouvez soit jouer avec les paramètres du fichier de paramètres sshd - /etc/ssh/sshd_config :

#TCPKeepAlive oui #ServerAliveInterval #ServerAliveCountMax

Ou utilisez l'utilitaire autossh.