Verhindern Sie den Verlust der SSH-Verbindung nach der Anmeldung bei VPN auf dem Server

Ich bin auf ein Problem gestoßen, mit dem ich mich nicht befassen kann. Wenn ich über SSH bei einem VPS angemeldet bin und versuche, die VPN-Verbindung auf diesem VPS herzustellen, geht die SSH-Verbindung zwischen VPS und meinem Computer verloren. Ich nehme an, das liegt daran, dass das Routing durch die VPN-Einstellungen geändert wurde. Wie kann man das verhindern?

Sie müssen der Konfigurationsdatei Ihres OpenVPN-Clients auf Ihrem VPS eine route-nopullOption hinzufügen (und entfernen, redirect-gatewayfalls vorhanden).

Auf diese Weise werden beim Herstellen einer Verbindung zu einem VPN-Server keine Routen auf Ihrem VPS geändert, sodass Sie die benötigten Routen selbst festlegen können.

Betrachten wir folgendes Szenario:

1. Ihr VPS verfügt über eine einzige Ethernet-Schnittstelle, die mit der IP-Adresse 4.3.2.1/24 konfiguriert ist.
2. Ihr VPS kann über ein Standard-Gateway 4.3.2.254 auf das Internet zugreifen
3. Ihr VPS hat nicht jede OpenVPN - Verbindung noch aktiviert; Daher ist keine Tun-Schnittstelle aktiv

In einem solchen Szenario können Sie von Ihrem Computer aus (nehmen wir an, Ihr Computer ist 9.8.7.6/24 mit def-gw 9.8.7.254) erfolgreich eine SSH-Verbindung zu 4.3.2.1 herstellen. Somit können sich beide Hosts 4.3.2.1 und 9.8.7.6 erfolgreich gegenseitig erreichen.

Nehmen wir nun an, mit einer solchen SSH-Verbindung:

4. Sie starten eine OpenVPN-Verbindung von Ihrem VPS 4.3.2.1 aus.
5. Als solches wird eine neue tun0-Schnittstelle dynamisch konfiguriert (nehmen wir an, dass ihr eine 10.10.10.2-IP mit einem 10.10.10.1-PTP zugewiesen wird).

In diesem Stadium:

• WENN keine Route vom Remote-OpenVPN-Server zu Ihrem lokalen VPS übertragen wird, ändert sich nichts in Bezug auf das Routing, und Ihre SSH-Verbindung überlebt ohne Probleme. In diesem Fall ist der einzige Datenverkehr, der das VPN durchläuft, der Datenverkehr, der an den Remote-OpenVPN-Server (10.10.10.1) gerichtet ist.

• WENN der Remote-OpenVPN-Server eine Route zurückschiebt und insbesondere wenn das VPS-Standardgateway durch 10.10.10.1 (Remote-OpenVPN-Endpunkt) ersetzt wird, DANN treten Probleme auf. In diesem Fall tunneln Sie den gesamten ausgehenden IP-Verkehr (mit Ausnahme von OpenVPN selbst) innerhalb des VPN.

In diesem zweiten Fall (Ersetzen von def-gw direkt nach dem Herstellen der VPN-Verbindung) "hängt" Ihre vorherige SSH-Verbindung aufgrund von asymmetrischem Routing:

• Der Datenverkehr von Ihrem Computer (9.8.7.6) zu VPS (4.3.2.1) fließt über den vorherigen, nie geänderten Pfad.
• Datenverkehr von VPS (4.3.2.1) zu Ihrem Computer (9.8.7.6):
  • ohne das VPN (also zunächst) wurde über das Gateway 4.3.2.254 geroutet;
  • nach dem aufbau der vpn-verbindung wird mit zugehörigem def-gw-ersatz über das vpn geroutet (10.10.10.1).

Mit anderen Worten: Sobald die VPN-Verbindung hergestellt ist, ändert sich Ihre Rückroute von VPS zu Ihrem Computer und ... dies ist keine gute Sache (mehrere Netzwerkgeräte auf dem Rückweg erkennen möglicherweise eine solche Asymmetrie Pfad und einfach Pakete fallen lassen).

Darüber hinaus ist die Wahrscheinlichkeit groß, dass Ihr Remote-OpenVPN-Server als NAT-Box fungiert: Der gesamte vom VPN kommende Datenverkehr wird mit der öffentlichen IP-Adresse des Remote-OpenVPN-Servers NAT-zertifiziert. Wenn dies wahr ist , als die Dinge sind nicht mehr ... „nicht gut“, aber auf jeden Fall „schlecht“, wie für Ihren SSH - Verbindung: Rückholverkehr, zusätzlich entlang einer anderen Route zurück zu bekommen, wird immer wieder auf Ihre Maschine mit eine andere Quell-IP (die der öffentlichen Schnittstelle des VPN-Servers).

Wie kann man dieses Problem lösen?

Ganz leicht.

Weisen Sie Ihren VPS-Server einfach an, den Datenverkehr nicht über das VPN an Ihren Computer weiterzuleiten, sondern sich auf die vorherige Route zu verlassen . Es sollte so einfach wie das Hinzufügen sein, bevor Sie OpenVPN starten:

     route add -host 9.8.7.6 gw 4.3.2.254

wo:

• 9.8.7.6 ist die öffentliche IP-Adresse Ihres Computers
• 4.3.2.254 ist das ursprüngliche Standard-Gateway Ihres VPS.

PS: Wenn Sie eine viel ausführlichere Frage gestellt hätten, hätten Sie eine viel schnellere Antwort erhalten :-)

Dies kann helfen:

setzen Sie TCPKeepAlive=yesin Ihre/etc/ssh/sshd_config

Von

man sshd_config | less +/'^ *TCPKeepAlive'

TCPKeepAlive

Gibt an, ob das System TCP-Keepalive-Nachrichten an die andere Seite senden soll. Wenn sie gesendet werden, wird der Verbindungsabbruch oder der Absturz einer der Maschinen ordnungsgemäß bemerkt. Dies bedeutet jedoch, dass Verbindungen unterbrochen werden, wenn die Route vorübergehend unterbrochen wird, und einige Leute finden, dass dies ärgerlich ist. Wenn andererseits keine TCP-Keepalives gesendet werden, können Sitzungen auf unbestimmte Zeit auf dem Server hängen bleiben, was "Geister" -Benutzer zurücklässt und Serverressourcen verbraucht.

Der Standardwert ist " 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 toNein".

Ich hatte dieses Problem und habe alle empfohlenen Lösungen ausprobiert, und trotzdem wurde mein Problem nicht gelöst!

Nach vielen Lösungsversuchen habe ich den screenBefehl verwendet. (Mein VPN-Client ist Cisco-Any-Connect).

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

Nachdem Sie Ihre Anmeldeinformationen eingegeben haben, drücken Sie sofort Strg + a + d und kehren Sie zu Ihrer Sitzung zurück.

Persönlich bevorzuge ich, dass alle Verbindungen zu SSH über VPN geleitet werden. Bei einer aktiven SSH-Verbindung vor dem VPN-Aufbau muss die Verbindung aufgrund der geänderten Route erneut hergestellt werden.

Ich empfehle, autossh unter Ihrer ssh-Client-Konfiguration einfach hinzuzufügen.ssh/config

Host *
   ServerAliveInterval 300
   ServerAliveCountMax 2
   BatchMode yes

• BatchMode steht für Auto-Reconnect
• ServerAlive steht für Keeping Alive

Einmal nach dem Herstellen einer VPN-Verbindung wird ssh getrennt, da der ssh-Verkehr vom Server über den VPN-Server erfolgt. Um dies zu vermeiden, führen Sie den folgenden Befehl aus, bevor Sie eine VPN-Verbindung herstellen.

route add -host dein-Rechner-public-ip gw Server-gatway-ip dev eth0

your-machine-public-ip: IP-Adresse Ihres Computers, von dem aus Sie SSH ausführen. Server-gatway-ip: Die IP des Gatways / Routers dieses Servers

Der obige Befehl leitet den Datenverkehr über das angegebene Gateway um, nicht über den VPN-Server.