Impedisci la perdita della connessione SSH dopo l'accesso alla VPN sul server

Ho riscontrato un problema che non posso affrontare. Quando accedo a un VPS su SSH e provo a stabilire una connessione VPN su quel VPS, la connessione SSH tra VPS e la mia macchina si perde. Suppongo sia perché il routing è stato modificato dalle impostazioni VPN. Come prevenirlo?

Devi aggiungere l' route-nopullopzione (e rimuoverla redirect-gatewayse esiste) al file di configurazione del tuo client OpenVPN sul tuo VPS.

In questo modo la connessione a un server VPN non modificherà alcun percorso sul tuo VPS, quindi sarai in grado di impostare quelli di cui hai bisogno da solo.

Consideriamo il seguente scenario:

1. il tuo VPS ha un'unica interfaccia ethernet, configurata con l'indirizzo IP 4.3.2.1/24;
2. il tuo VPS può accedere a Internet tramite un gateway predefinito 4.3.2.254
3. il tuo VPS non ha ancora attivato alcuna connessione OpenVPN; quindi non ci sono nessun tun interfaccia attiva

In un tale scenario, dalla tua macchina (supponiamo che la tua macchina sia 9.8.7.6/24 con def-gw 9.8.7.254) puoi stabilire con successo una connessione SSH a 4.3.2.1. Quindi entrambi gli host 4.3.2.1 e 9.8.7.6 possono raggiungersi con successo.

Ora, con tale connessione SSH stabilita, supponiamo:

4. si avvia una connessione OpenVPN dal VPS 4.3.2.1;
5. come tale, una nuova interfaccia tun0 verrà configurata dinamicamente (supponiamo che gli verrà assegnato un IP 10.10.10.2, con un PTP 10.10.10.1).

In questa fase:

• Se nessuna route verrà trasferita dal server OpenVPN remoto al VPS locale, non cambierà nulla in termini di routing e la connessione SSH sopravviverà senza problemi. In questo caso, l'unico traffico che attraversa la VPN è quello diretto verso il server OpenVPN remoto (10.10.10.1);

• Se il server OpenVPN remoto rimanderà indietro, in particolare se il gateway predefinito VPS verrà sostituito con 10.10.10.1 (endpoint OpenVPN remoto), POI stai riscontrando problemi. In questo caso stai effettuando il tunneling di TUTTO il traffico IP in uscita (ad eccezione di OpenVPN stesso) all'interno della VPN.

In questo secondo caso (sostituendo def-gw subito dopo aver stabilito la connessione VPN), la precedente connessione SSH si "bloccherà" a causa del routing asimmetrico:

• Il traffico dalla tua macchina (9.8.7.6) a VPS (4.3.2.1) scorrerà attraverso il percorso precedente, mai modificato;
• Traffico da VPS (4.3.2.1) alla tua macchina (9.8.7.6):
  • senza VPN (quindi, inizialmente) è stato instradato attraverso il gateway 4.3.2.254;
  • dopo la creazione del collegamento VPN, con relativa sostituzione def-gw, viene instradato attraverso la VPN (10.10.10.1).

In altre parole: non appena viene stabilito il collegamento VPN, la rotta di ritorno da VPS alla macchina cambierà e ... questo non è un aspetto positivo (diversi dispositivi di rete, lungo il percorso di ritorno, potrebbero riconoscere tale asimmetria percorso e semplicemente rilasciare i pacchetti).

Inoltre, è molto probabile che il tuo server OpenVPN remoto agisca come un NAT-box: tutto il traffico proveniente dalla VPN sarà NATted con l'indirizzo IP pubblico del server OpenVPN remoto. Se questo è vero, allora le cose non vanno più ... "non buono", ma sicuramente "cattivo", come per la tua connessione SSH: il traffico di ritorno, oltre a tornare lungo un percorso diverso, sta tornando alla tua macchina con un IP di origine diverso (quello dell'interfaccia pubblica del server VPN).

Come risolvere questo problema?

Abbastanza facilmente, anzi.

Indica semplicemente al tuo server VPS di non indirizzare il traffico verso la tua macchina lungo la VPN, ma, invece, affidandoti alla rotta precedente . Dovrebbe essere facile come aggiungere, prima di avviare OpenVPN:

     route add -host 9.8.7.6 gw 4.3.2.254

dove:

• 9.8.7.6 è l'indirizzo IP pubblico della macchina
• 4.3.2.254 è il gateway predefinito originale del VPS.

PS: fornendo una domanda molto più dettagliata, avresti ottenuto una risposta molto più rapida :-)

Questo può aiutare:

inserisci il TCPKeepAlive=yestuo/etc/ssh/sshd_config

A partire dal

man sshd_config | less +/'^ *TCPKeepAlive'

TCPKeepAlive

Specifica se il sistema deve inviare messaggi keepalive TCP all'altro lato. Se vengono inviati, verrà notata correttamente la morte della connessione o l'arresto anomalo di una delle macchine. Tuttavia, ciò significa che le connessioni moriranno se il percorso è temporaneamente inattivo e alcune persone lo trovano fastidioso. D'altra parte, se i keepalive TCP non vengono inviati, le sessioni potrebbero bloccarsi indefinitamente sul server, lasciando utenti `` fantasma '' e consumando risorse del server.

L'impostazione predefinita è 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 tono ''.

Ho avuto questo problema e ho provato tutte le soluzioni consigliate, eppure il mio problema non è stato risolto!

Dopo molte tentate soluzioni, ho usato il screencomando. (il mio client VPN è cisco-any-connect).

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

Dopo aver fornito le tue credenziali, premi ctrl + a + d immediatamente e torna alla sessione.

Personalmente preferisco che tutte le connessioni a SSH siano instradate tramite VPN. In caso di connessione ssh attiva prima che venga stabilita la VPN, è necessario riconnettersi a causa del percorso modificato.

Raccomando di usare autossh Sotto la configurazione del tuo client SSH basta aggiungere.ssh/config

Host *
   ServerAliveInterval 300
   ServerAliveCountMax 2
   BatchMode yes

• BatchMode sta per riconnessione automatica
• ServerAlive è l' acronimo di Keeping Alive

Una volta dopo aver collegato la VPN, ssh viene disconnesso perché, il traffico ssh dal server passa attraverso il server VPN. Quindi, per evitare ciò, eseguire il comando seguente prima di connettere VPN.

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

your-machine-public-ip: IP del tuo computer da dove stai eseguendo SSH. Server-gatway-ip: IP di Gatway / router di quel server

Il comando precedente reindirizzerà il traffico tramite il gateway specificato non tramite il server VPN.