Zapobiegaj utracie połączenia SSH po zalogowaniu się do VPN na serwerze

Napotkałem problem, z którym nie mogę sobie poradzić. Kiedy loguję się do VPS przez SSH i próbuję ustanowić połączenie VPN na tym VPS, połączenie SSH między VPS a moją maszyną zostaje utracone. Zakładam, że dzieje się tak, ponieważ routing został zmieniony przez ustawienia VPN. Jak temu zapobiec?

Musisz dodać route-nopullopcję (i usunąć, redirect-gatewayjeśli istnieje) do pliku konfiguracyjnego klienta OpenVPN na VPS.

W ten sposób połączenie z serwerem VPN nie zmodyfikuje żadnych tras na twoim VPS, więc będziesz mógł ustawić te, których potrzebujesz.

Rozważmy następujący scenariusz:

1. twój VPS ma pojedynczy interfejs Ethernet, skonfigurowany z adresem IP 4.3.2.1/24;
2. Twój VPS może uzyskać dostęp do Internetu za pośrednictwem bramy domyślnej 4.3.2.254
3. twój VPS nie aktywował jeszcze żadnego połączenia OpenVPN; stąd nie ma aktywnego interfejsu tun

W takim scenariuszu z poziomu komputera (załóżmy, że twój komputer to 9.8.7.6/24 z def-gw 9.8.7.254) możesz pomyślnie ustanowić połączenie SSH z 4.3.2.1. Dlatego oba hosty 4.3.2.1 i 9.8.7.6 mogą z powodzeniem się ze sobą skontaktować.

Teraz, po ustanowieniu takiego połączenia SSH, załóżmy:

4. uruchamiasz połączenie OpenVPN z VPS 4.3.2.1;
5. w związku z tym nowy interfejs tun0 zostanie skonfigurowany dynamicznie (załóżmy, że zostanie mu przypisany adres IP 10.10.10.2 z PTP 10.10.10.1).

Na tym etapie:

• JEŚLI żadna trasa nie zostanie przekazana ze zdalnego serwera OpenVPN do lokalnego VPS, nic nie zmieni się pod względem routingu, a twoje połączenie SSH przetrwa bez żadnych problemów. W takim przypadku jedynym ruchem przechodzącym przez VPN jest ten skierowany w stronę zdalnego serwera OpenVPN (10.10.10.1);

• JEŻELI zdalny serwer OpenVPN odepchnie pewną trasę, a zwłaszcza jeśli domyślna brama VPS zostanie zastąpiona 10.10.10.1 (zdalny punkt końcowy OpenVPN), NASTĘPNIE masz problemy. W tym przypadku tunelujesz CAŁY wychodzący ruch IP (z wyjątkiem samego OpenVPN) w sieci VPN.

W tym drugim przypadku (zastąpienie def-gw zaraz po ustanowieniu połączenia VPN) poprzednie połączenie SSH „zawiesi się” z powodu asymetrycznego routingu:

• Ruch z twojej maszyny (9.8.7.6) do VPS (4.3.2.1) przepłynie przez poprzednią, nigdy nie zmienioną ścieżkę;
• Ruch z VPS (4.3.2.1) do twojej maszyny (9.8.7.6):
  • bez sieci VPN (stąd początkowo) był kierowany przez bramę 4.3.2.254;
  • po ustanowieniu łącza VPN, z powiązaną wymianą def-gw, jest kierowany przez VPN (10.10.10.1).

Innymi słowy: jak tylko połączenie VPN zostanie ustanowione, twoja trasa powrotna z VPS do twojego komputera zmieni się i ... to nie jest dobra rzecz (kilka urządzeń sieciowych wzdłuż ścieżki powrotnej może rozpoznać taką asymetrię ścieżka i po prostu upuść pakiety).

Co więcej, istnieje duże prawdopodobieństwo, że twój zdalny serwer OpenVPN działa jak NAT-box: cały ruch przychodzący z VPN będzie NATted z publicznym adresem IP zdalnego serwera OpenVPN. Jeśli to prawda, to już nie ma rzeczy ... „nie jest dobrze”, ale zdecydowanie „źle”, jak w przypadku połączenia SSH: ruch powrotny, oprócz powrotu inną drogą, wraca na komputer z inny źródłowy adres IP (jeden z publicznego interfejsu serwera VPN).

Jak rozwiązać ten problem?

Rzeczywiście dość łatwo.

Wystarczy poinstruować serwer VPS, aby nie kierował ruchu do maszyny wzdłuż sieci VPN, ale zamiast tego polegał na poprzedniej trasie . Przed uruchomieniem OpenVPN powinno to być tak proste, jak dodanie:

     route add -host 9.8.7.6 gw 4.3.2.254

gdzie:

• 9.8.7.6 to publiczny adres IP komputera
• 4.3.2.254 jest oryginalną bramą domyślną twojego VPS.

PS: udzielając bardziej szczegółowego pytania, uzyskałbyś znacznie szybszą odpowiedź :-)

To może pomóc:

włóż TCPKeepAlive=yesswoje/etc/ssh/sshd_config

Od

man sshd_config | less +/'^ *TCPKeepAlive'

TCPKeepAlive

Określa, czy system powinien wysyłać komunikaty podtrzymujące TCP na drugą stronę. Jeśli zostaną wysłane, śmierć połączenia lub awaria jednego z urządzeń zostanie odpowiednio zauważona. Oznacza to jednak, że połączenia zostaną przerwane, jeśli trasa będzie chwilowo nieczynna, a niektórzy uważają ją za irytującą. Z drugiej strony, jeśli Keepalives TCP nie zostaną wysłane, sesje mogą zawieszać się na serwerze w nieskończoność, pozostawiając użytkowników-duchów i zużywających zasoby serwera.

Wartość domyślna 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„nie”.

Miałem ten problem i wypróbowałem wszystkie zalecane rozwiązania, a mimo to mój problem nie został rozwiązany!

Po wielu próbach rozwiązania użyłem screenpolecenia. (moim klientem VPN jest cisco-any-connect).

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

Po podaniu poświadczeń naciśnij natychmiast ctrl + a + d i wróć do sesji.

Osobiście wolę, aby wszystkie połączenia z SSH były kierowane przez VPN. W przypadku aktywnego połączenia ssh przed ustanowieniem VPN, musi on ponownie się połączyć z powodu zmiany trasy.

Polecam użyć autossh W konfiguracji klienta ssh wystarczy dodać.ssh/config

Host *
   ServerAliveInterval 300
   ServerAliveCountMax 2
   BatchMode yes

• BatchMode oznacza automatyczne ponowne połączenie
• ServerAlive oznacza Keeping Alive

Raz po podłączeniu VPN, ssh zostaje odłączony, ponieważ ruch ssh z serwera przechodzi przez serwer VPN. Aby tego uniknąć, uruchom następujące polecenie przed podłączeniem VPN.

route add -host twoja-maszyna-publiczna-ip gw Serwer-gatway-ip dev eth0

your-machine-public-ip: IP twojego komputera, z którego robisz SSH. Server-gatway-ip: Adres IP Gatway / routera tego serwera

Powyższe polecenie przekieruje ruch przez daną bramę, a nie przez serwer VPN.