Empêcher la connexion SSH perdue après la connexion au VPN sur la machine serveur

14

J'ai rencontré un problème que je ne peux pas résoudre. Lorsque je suis connecté à un VPS sur SSH et que j'essaie d'établir une connexion VPN sur ce VPS, la connexion SSH entre VPS et ma machine est perdue. Je suppose que c'est parce que le routage a été modifié par les paramètres VPN. Comment éviter ça?

mic22
la source
Qu'en est-il de la connexion à SSH après l'établissement de VP? : p Vous avez raison, cela est dû au fait que le VPN écrase les chemins de routage. Ce que vous pouvez faire est de garder vos chemins d'origine intacts et d'ajouter simplement le chemin VPN supplémentaire (sauf si vous voulez utiliser votre VPS comme proxy. C'est une autre histoire). Quel client utilisez-vous?
Nikolaidis Fotis
Que voulez-vous dire par «essayer d'établir une connexion VPN sur ce VPS»? Vous vous connectez de votre machine à un serveur Openvpn sur le VPS? Votre VPS se connecte à un serveur Openvpn fonctionnant sur un troisième hôte? Dans ce dernier cas, une telle connexion VPN repousse certaines routes? Veuillez également confirmer qu'il n'y a pas de traduction NAT pour atteindre votre VPS (l'adresse IP configurée sur son interface est la même que celle que vous spécifiez dans la connexion SSH?
Damiano Verzulli
@NikolaidisFotis Je ne peux pas me connecter car le VPN est en cours d'exécution. J'utilise le client openvpn. Il y a une --route-noexecoption pour ignorer les routes poussées par le serveur mais, comme vous l'avez mentionné, cela n'aide pas quand je veux utiliser VPN comme proxy ...
mic22
@DamianoVerzulli la deuxième option, oui les routes sont poussées (mais je pense que cela doit être fait car j'ai besoin de ce VPN pour agir comme proxy pour masquer l'adresse IP d'origine de la machine), et non il n'y a pas de NAT
mic22

Réponses:

6

Vous devez ajouter une route-nopulloption (et la supprimer redirect-gatewaysi elle existe) au fichier de configuration de votre client OpenVPN sur votre VPS.

De cette façon, la connexion à un serveur VPN ne modifiera aucun itinéraire sur votre VPS, vous pourrez donc définir vous-même ceux dont vous avez besoin.

Anubioz
la source
Hé, merci pour ce conseil, mais maintenant je ne peux pas accéder à Internet via tun0. Je suppose que je manque une passerelle. Des idées pour ajouter une passerelle pour tun0? Partie pertinente d'ifconfig:inet addr:10.56.10.6 P-t-P:10.56.10.5 Mask:255.255.255.255
Housemd
Vous devez ajouter manuellement un itinéraire vers le serveur VPN lui-même via votre passerelle ISP par défaut, puis ajouter la passerelle par défaut via 10.56.10.5 pour tout autre trafic
Anubioz
Je suis désolé, quoi? Je n'ai aucune idée de ce que tu viens de dire. Pouvez-vous donner un exemple ?
Housemd
Permettez-moi de clarifier - je ne veux pas que la route par défaut soit via tun0, mais j'ai besoin de tun0 pour avoir accès à Internet.
Housemd
@Housemd hm vous avez besoin d'avoir un accès Internet via tun0 vous-même ou vous avez besoin de clients connectés via tun0 depuis d'autres endroits pour avoir accès à Internet?
Anubioz
4

Prenons le scénario suivant:

  1. votre VPS possède une interface Ethernet unique, configurée avec l'adresse IP 4.3.2.1/24;
  2. votre VPS peut accéder à Internet via une passerelle par défaut 4.3.2.254
  3. votre VPS n'a pas encore activé de connexion OpenVPN; il n'y a donc pas d' interface tun active

Dans un tel scénario, à partir de votre machine (supposons que votre machine soit 9.8.7.6/24 avec def-gw 9.8.7.254), vous pouvez réussir à établir une connexion SSH vers 4.3.2.1. Par conséquent, les deux hôtes 4.3.2.1 et 9.8.7.6 peuvent réussir à se rejoindre.

Maintenant, avec une telle connexion SSH établie, supposons:

  1. vous lancez une connexion OpenVPN depuis votre VPS 4.3.2.1;
  2. en tant que telle, une nouvelle interface tun0 sera configurée de façon dynamique (supposons qu'elle se verra attribuer une IP 10.10.10.2, avec un PTP 10.10.10.1).

À ce stade:

  • SI aucun itinéraire ne sera poussé du serveur OpenVPN distant vers votre VPS local, alors rien ne changera en termes de routage, et votre connexion SSH survivra sans aucun problème. Dans ce cas, le seul trafic traversant le VPN est celui dirigé vers le serveur OpenVPN distant (10.10.10.1);

  • SI le serveur OpenVPN distant repoussera une route, et surtout si la passerelle par défaut VPS sera remplacée par 10.10.10.1 (point de terminaison OpenVPN distant), ALORS vous rencontrez des problèmes. Dans ce cas, vous tunnelisez TOUT le trafic IP sortant (à l'exception d'OpenVPN lui-même) dans le VPN.

Dans ce deuxième cas (en remplaçant def-gw juste après avoir établi la connexion VPN), votre précédente connexion SSH "se bloquera", en raison du routage asymétrique:

  • Le trafic de votre machine (9.8.7.6) vers VPS (4.3.2.1) passera par le chemin précédent, jamais modifié;
  • Trafic de VPS (4.3.2.1) vers votre machine (9.8.7.6):
    • sans VPN (donc, initialement) a été acheminé via la passerelle 4.3.2.254;
    • après l'établissement de la liaison VPN, avec le remplacement def-gw associé, est acheminé via le VPN (10.10.10.1).

En d'autres termes: dès que la liaison VPN est établie, votre itinéraire de retour de VPS à votre machine va changer et ... ce n'est pas une bonne chose (plusieurs périphériques réseau, le long du chemin de retour, pourraient reconnaître une telle asymétrie chemin et simplement déposer des paquets).

En outre, il est fort probable que votre serveur OpenVPN distant agisse comme une boîte NAT: tout le trafic provenant du VPN sera NATté avec l'adresse IP publique du serveur OpenVPN distant. Si cela est vrai, les choses ne sont plus ... "pas bonnes", mais certainement "mauvaises", comme pour votre connexion SSH: le trafic de retour, en plus de reprendre un itinéraire différent, revient sur votre machine avec une IP source différente (celle de l'interface publique du serveur VPN).

Comment résoudre ce problème?

Assez facilement, en effet.

Demander simplement à votre serveur VPS de ne pas acheminer le trafic vers votre machine via le VPN, mais plutôt de s'appuyer sur l'itinéraire précédent . Cela devrait être aussi simple que d'ajouter, avant de démarrer OpenVPN:

     route add -host 9.8.7.6 gw 4.3.2.254

où:

  • 9.8.7.6 est l'adresse IP publique de votre machine
  • 4.3.2.254 est la passerelle par défaut d'origine de votre VPS.

PS: en fournissant une question beaucoup plus détaillée, vous auriez obtenu une réponse beaucoup plus rapide :-)

Damiano Verzulli
la source
Merci pour votre réponse @DamianoVerzulli! La passerelle par défaut n'est pas spécifiée. route addcommande avec de tels retours 0.0.0.0 gwSIOCADDRT: Invalid argument
mic22
C'est ce que j'obtiens juste après la connexion à openvpn[server] Peer Connection Initiated with [AF_INET]64.251.27.139:443; TUN/TAP device tun0 opened; do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0; /sbin/ip link set dev tun0 up mtu 1500; /sbin/ip addr add dev tun0 10.200.1.251/22 broadcast 10.200.3.255; ERROR: Linux route add command failed: external program exited with error status: 2
mic22
@ mic22: Je me demande comment def-gw de votre VPS peut être non spécifié car dans ce cas, un tel VPS ne peut rien atteindre en dehors du sous-réseau local (et cela signifie que votre machine - étant capable de se connecter via SSH-- et le serveur OpenVpn - pouvoir établir un VPN - devrait être "local" et, en tant que tel, assez inutile!). BTW: lorsque vous êtes connecté via SSH, vous pouvez facilement obtenir def-gw avec un "netstat -rn" (ligne commençant par 0.0.0.0, deuxième colonne)
Damiano Verzulli
netstat -rnrésultat 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 venet0VPS J'utilise est une option de base OVH avec Ubuntu 14.04 serveur à bord
mic22
ifconfiget netstat -rnsortie: goo.gl/TEZ61q
mic22
0

Cela peut aider:

mettre TCPKeepAlive=yesdans votre/etc/ssh/sshd_config

De

man sshd_config | less +/'^ *TCPKeepAlive'

TCPKeepAlive

Spécifie si le système doit envoyer des messages TCP keepalive de l'autre côté. S'ils sont envoyés, la mort de la connexion ou le crash de l'une des machines sera correctement constaté. Cependant, cela signifie que les connexions seront interrompues si l'itinéraire est temporairement interrompu, et certaines personnes le trouvent ennuyeux. D'un autre côté, si les keepalives TCP ne sont pas envoyés, les sessions peuvent se bloquer indéfiniment sur le serveur, laissant des utilisateurs `` fantômes '' et consommant des ressources de serveur.

La valeur par défaut est yes'' (to send TCP keepalive messages), and the server will notice if the network goes down or the client host crashes. This avoids infinitely hanging sessions. To disable TCP keepalive messages, the value should be set tonon ''.

Gilles Quenot
la source
J'ai déjà TCPKeepAlivedéfini une option pour yesque ce ne soit pas une bonne solution
mic22
0

J'ai eu ce problème et j'ai essayé toutes les solutions recommandées, et pourtant, mon problème n'a pas été résolu!

Après de nombreuses tentatives de solutions, j'ai utilisé la screencommande. (mon client VPN est cisco-any-connect).

$ screen -R VPN
$ openconnect -b "your server"

Après avoir fourni vos informations d'identification, appuyez immédiatement sur ctrl + a + d et revenez à votre session.

Nima Ghoroubi
la source
0

Personnellement, je préfère que toutes les connexions à SSH soient acheminées via VPN. En cas de connexion ssh active avant l'établissement du VPN, il doit se reconnecter en raison de la modification de l'itinéraire.

Je recommande d'utiliser autossh Sous votre configuration client ssh il suffit d'ajouter.ssh/config

Host *
   ServerAliveInterval 300
   ServerAliveCountMax 2
   BatchMode yes
  • BatchMode signifie reconnexion automatique
  • ServerAlive signifie Keeping Alive
Lukáš Viktora
la source
-1

Une fois après la connexion VPN, ssh se déconnecte car, le trafic ssh du serveur passe par le serveur VPN. Donc, pour éviter cela, exécutez la commande suivante avant de connecter VPN.

route add -host your-machine-public-ip gw Server-gatway-ip dev eth0

your-machine-public-ip: IP de votre machine d'où vous faites SSH. Server-gatway-ip: IP Gatway / routeur de ce serveur

La commande ci-dessus redirigera le trafic via la passerelle donnée et non via le serveur VPN.

Mohamed Sabil
la source
C'est déroutant, et la langue semble l'avoir à l'envers. Souhaitez-vous pas ajouter une route avec l'adresse IP de la cible SSH et la passerelle par défaut du poste de travail local?
rmalayter