web-dev-qa-db-fra.com

Accéder à plusieurs serveurs distants derrière NAT

J'ai une situation où nos serveurs Ubuntu ont été déployés sur plusieurs emplacements distants. Ces serveurs se trouvaient derrière un opérateur de classe NAT et également un NAT interne. Maintenant, depuis un emplacement central, je veux y accéder à tout moment, mais je suis aussi derrière un NAT similaire à ces serveurs.

enter image description here

Lorsque ces serveurs sont en ligne, je souhaite y accéder (via un tunnel SSH ou SSH). Je sais que je ne peux pas accéder aux serveurs dotés d'une adresse IP publique, mais je peux peut-être y accéder d'une manière ou d'une autre grâce au principe de fonctionnement de TeamViewer. Pour cette méthode, si j'ai besoin d'un autre serveur public, je peux le gérer dans Google Compute Engine.

networkingserversshremote-accessteamviewer
1
Sagar Khatiwada

Si nous avons accès à un serveur avec une adresse IP publique, nous pouvons l’utiliser comme passerelle. Nous pourrions y parvenir via des connexions de transfert de port SSH inversé. Disons que nous avons trois cas:

  • Public Server : nous avons ici un serveur SSH opérationnel et une adresse IP publique (et/ou un nom de domaine). Nous sommes en mesure de nous connecter à ce serveur avec une paire de clés publique/privée, qui n'est pas protégée par une phrase secrète ( référence ).

  • Serveur privé : nous avons ici un serveur SSH opérationnel. Il est derrière un pare-feu (NAT, ISP, etc.) et n'a pas d'adresse IP publique, mais nous sommes en mesure d'établir une connexion SSH à partir de celui-ci sur le serveur public. Nous avons donc également le client SSH.

  • Ordinateur client : Ici, nous (ne devons) avoir que le client SSH. Nous sommes en mesure d'établir une connexion SSH avec le serveur public. Nous souhaitons établir une connexion SSH à partir de cette instance vers le serveur privé.

Le niveau principal

Au niveau principal, nous pourrions appliquer au moins deux scénarios.

Scénario 1. Nous ne souhaitons pas ouvrir de ports supplémentaires dans le pare-feu du serveur public:

  1. Établissez une connexion SSH avec la redirection de port du serveur privé au serveur public.
  2. Établissez une connexion SSH avec la redirection de port de la machine cliente au serveur public.
  3. Connectez-vous au serveur privé à partir de la machine cliente via elle-même.

Scénario 2. Lorsque nous sommes enclins à ouvrir un port supplémentaire dans le pare-feu du serveur public:

  1. Établissez une connexion SSH avec la redirection de port du serveur privé au serveur public.
  2. Connectez-vous au serveur privé à partir de la machine cliente via le serveur public.

L’avantage principal du scénario 1 est que nous n’avons pas besoin de penser à la sécurité de notre serveur privé. L'avantage principal du scénario 2 est que nous n'effectuons qu'une étape, mais dans ce cas, nous devrions penser à la sécurité du serveur privé, car il devient accessible au public via le port transféré. En outre, ces scénarios pourraient être appliqués à différents ports et services, pas seulement à SSH, par exemple à HTTP.

Comment appliquer le scénario 1 dans Ubuntu

Établissez une connexion SSH avec la redirection de port du serveur privé au serveur public

Nous pourrions le faire par la commande:

ssh user-of-the-public-server@public-server -p 22 -R 2222:127.0.0.1:22 -i ~/.ssh/pass-less/id_rsa

  • -p 22 fournit le port SSH du serveur public (ce n'est pas obligatoire).

  • -i ~/.ssh/pass-less/id_rsa fournit le fichier de clé d'authentification.

  • -R 2222:127.0.0.1:22 signifie que le port 2222 sur le serveur public (distant) sera transféré sur le port SSH du serveur privé (local) qui, dans ce cas, est 22.

Nous pouvons pousser cette connexion en arrière-plan en ajoutant les options -fTN (du client OpenSSH - référence ). Nous pourrions également utiliser l'outil autossh pour nous assurer que la connexion restera active pendant une longue période ( référence ):

autossh user-of-the-public-server@public-server -p 22 -fTN -R 2222:127.0.0.1:22 -i ~/.ssh/pass-less/id_rsa

Nous pouvons simplifier la commande ci-dessus en implémentant les lignes suivantes dans notre fichier ~/.ssh/config:

Host public-server-reverse
    HostName 100.100.100.100  # this is the IP address or the domain name of the Public Server
    IdentityFile ~/.ssh/pass-less/id_rsa
    User user-of-the-public-server
    Port 22
    RemoteForward 2222 localhost:22

Dans ce cas, la commande ci-dessus deviendra:

autossh public-server-reverse -fTN

Nous pouvons facilement automatiser cette tâche lors du redémarrage du système par le prochain travail Cron (ou nous pourrions créer un service cela devrait être la meilleure approche):

@reboot sleep 45 && autossh public-server-reverse -fTN

Une fois cette connexion établie, vous pouvez vous connecter au serveur privé à partir du serveur public, via le tunnel inverse, à l'aide de la commande:

ssh user-of-the-private-server@localhost -p 2222    # provide an additional authentication data (for the Private Server) if it is needed…


Établissez une connexion SSH avec la redirection de port de la machine cliente au serveur public

Nous pourrions le faire par la commande:

ssh user-of-the-public-server@public-server -p 22 -fTN -L 1111:127.0.0.1:2222 -i ~/.ssh/pass-less/id_rsa

  • -L 1111:127.0.0.1:2222 signifie que le port 1111 de la machine cliente (locale) sera transféré au port du serveur public (distant) 2222 (qui est transféré au port SSH du serveur privé). Notez que nous pourrions utiliser -L 2222:127.0.0.1:2222.

  • -fTN ces options pousseront la connexion en arrière-plan comme décrit ci-dessus.

  • Nous pouvons également implémenter les fichiers autossh et ~/.ssh/config, avec la directive RemoteForward ou LocalForward.


Se connecter au serveur privé à partir de la machine cliente via lui-même

Une fois les deux étapes ci-dessus mises en œuvre, nous pouvons nous connecter de la machine cliente au serveur public à l'aide de la commande:

ssh user-of-the-private-server@localhost -p 1111    # provide an additional authentication data (for the Private Server) if it is needed…

Comment appliquer le scénario 2 dans Ubuntu

Établissez une connexion SSH avec la redirection de port du serveur privé au serveur public

Cette étape est identique à la première du scénario 1, mais peu de choses supplémentaires doivent être faites.

Ouvrez le port transféré 2222 sur le pare-feu du serveur public - cela n’entre pas dans le cadre de cette réponse.

Modifiez /etc/ssh/sshd_config du serveur public et ajoutez la directive suivante, qui permettra d'ouvrir notre tunnel SSH au public (n'oubliez pas de redémarrer le serveur: Sudo systemctl restart sshd.service):

GatewayPorts yes

Rendez notre tunnel SSH ouvert au public. Cette étape est bien décrite dans la question: ( Comment rendre le tunnel ssh ouvert au public? ). Selon les réponses, nous pourrions ajouter l’option -g aux commandes qui établissent une connexion entre les serveurs privé et public:

autossh public-server-reverse -gfTN

@reboot sleep 45 && autossh public-server-reverse -gfTN

Ou, alternativement, nous pourrions modifier le fichier ~/.ssh/config de cette façon:

Host public-server-reverse
    HostName 100.100.100.100  # this is the IP address or the domain name of the Public Server
    IdentityFile ~/.ssh/pass-less/id_rsa
    User user-of-the-public-server
    Port 22
    RemoteForward \*:2222 localhost:22

Enfin, nous devrions killall autossh et établir à nouveau la connexion.


Se connecter au serveur privé à partir de la machine cliente via le serveur public

Une fois que l'étape ci-dessus est effectuée, nous pouvons atteindre notre objectif grâce à la commande:

ssh user-of-the-private-server@public-server -p 2222    # provide an additional authentication data (for the Private Server) if it is needed… forward some ports, etc.
0
pa4080