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

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 changé par les paramètres VPN. Comment éviter cela?

Vous devez ajouter l'option route-nopull (et supprimer la redirect-gateway si elle existe) dans le fichier de configuration de votre OpenVPN sur votre VPS.

De cette façon, la connexion à un serveur VPN ne modifiera pas les itinéraires sur votre VPS, afin que vous puissiez configurer ceux dont vous avez besoin.

Considérons le scénario suivant:

  1. Votre VPS dispose d'une seule interface ethernet, 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; Par conséquent, il n'y a 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 établir avec succès une connexion SSH à 4.3.2.1. Par conséquent, les deux hôtes 4.3.2.1 et 9.8.7.6 peuvent se rencontrer avec succès.

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

  1. Vous lancez une connexion OpenVPN à partir de votre VPS 4.3.2.1;
  2. En tant que tel, une nouvelle interface tun0 sera configurée dynamiquement (supposons qu'on lui attribuera une 10.10.10.2 IP, avec un PTP 10.10.10.1).

À ce stade:

  • Si aucune route n'est transmise du serveur OpenVPN distant à votre VPS local, rien ne changera en terme 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 repousse un certain itinéraire, et en particulier si la passerelle par défaut de VPS sera remplacée par 10.10.10.1 (point d'extrémité distant OpenVPN), ENTENDU, vous rencontrez des problèmes. Dans ce cas, vous effectuez un tunneling TOUT le trafic IP sortant (à l'exception de OpenVPN lui-même) dans le VPN.

Dans ce deuxième cas (en remplacement de def-gw juste après l'établissement de la connexion VPN), votre connexion SSH précédente "accroche", en raison du routage asymétrique:

  • Le trafic de votre machine (9.8.7.6) vers VPS (4.3.2.1) circulera à travers le chemin précédent, jamais modifié;
  • Trafic de VPS (4.3.2.1) vers votre machine (9.8.7.6):
    • Sans le VPN (donc, initialement) a été acheminé via la passerelle 4.3.2.254;
    • Après la création du lien VPN, avec le remplacement def-gw associé, est acheminé via le VPN (10.10.10.1).

En d'autres termes: dès que le lien VPN est établi, 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, peuvent reconnaître une telle asymétrie Chemin d'accès et déposez simplement des paquets).

En outre, les chances sont élevées que votre serveur OpenVPN distant joue le rôle de NAT-box: tout le trafic provenant du VPN sera doté de l'adresse IP publique du serveur OpenVPN distant. Si cela est vrai, les choses ne sont plus … "pas bon", mais définitivement "mauvais", comme pour votre connexion SSH: le trafic de retour, en plus de revenir sur une autre voie, revient à votre machine avec Une source IP différente (celle de l'interface publique du serveur VPN).

Comment résoudre ce problème?

Très facilement, en effet.

Demander simplement à votre serveur VPS de ne pas acheminer le trafic vers votre machine le long du VPN, mais plutôt de compter sur l'itinéraire précédent . Il 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 originale de votre VPS.

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

Cela peut aider:

Mettez TCPKeepAlive=yes dans votre /etc/ssh/sshd_config

De

 man sshd_config | less +/'^ *TCPKeepAlive' 

TCPKeepAlive

Spécifie si le système doit envoyer TCP keepalive messages de l'autre côté. S'ils sont envoyés, le décès de la connexion ou de l'accident d'une des machines sera correctement noté. Cependant, cela signifie que les connexions vont mourir si l'itinéraire est temporairement déchargé, et certaines personnes le troublent. D'autre part, si TCP keepalives ne sont pas envoyés, les sessions peuvent se bloquer indéfiniment sur le serveur, laissant les utilisateurs “ Ghost '' et les ressources du consommateur.

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 to 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 to 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 to non ''.

Une fois après avoir connecté VPN, ssh est déconnecté car le trafic ssh du serveur passe via le serveur VPN. Donc, pour éviter cela, exécutez la commande suivante avant de connecter VPN.

Route add -host your-machine-public-ip gw Serveur-gatway-ip dev eth0

Your-machine-public-ip: IP de votre machine d'où vous effectuez SSH. Server-gatway-ip: l'adresse IP de Gatway / routeur de ce serveur

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