Evitar a conexão SSH perdida após o login na VPN na máquina do servidor

Encontrei um problema que não consigo resolver. Quando estou conectado a um VPS sobre SSH e tento estabelecer uma conexão VPN nesse VPS, a conexão SSH entre o VPS e minha máquina é perdida. Suponho que é porque o roteamento foi alterado pelas configurações da VPN. Como evitar isso?

Você precisa adicionar a route-nopullopção (e remover, redirect-gatewayse existir) ao arquivo de configuração do seu cliente OpenVPN no seu VPS.

Dessa forma, a conexão com um servidor VPN não modifica nenhuma rota no seu VPS; portanto, você poderá definir as que precisa.

Vamos considerar o seguinte cenário:

1. seu VPS possui uma única interface Ethernet, configurada com o endereço IP 4.3.2.1/24;
2. seu VPS pode acessar a Internet através de um gateway padrão 4.3.2.254
3. seu VPS ainda não ativou nenhuma conexão OpenVPN; portanto, não há interface tun ativa

Nesse cenário, em sua máquina (suponha que sua máquina seja 9.8.7.6/24 com def-gw 9.8.7.254), você pode estabelecer com êxito uma conexão SSH para 4.3.2.1. Portanto, os dois hosts 4.3.2.1 e 9.8.7.6 podem alcançar um ao outro com êxito.

Agora, com uma conexão SSH estabelecida, vamos supor:

4. você inicia uma conexão OpenVPN a partir do seu VPS 4.3.2.1;
5. como tal, uma nova interface tun0 será dinamicamente configurada (suponha que seja atribuído um IP 10.10.10.2, com um PTP 10.10.10.1).

Nesta fase:

• Se nenhuma rota for enviada do servidor OpenVPN remoto para o seu VPS local, nada mudará no prazo de roteamento, e sua conexão SSH sobreviverá sem problemas. Nesse caso, o único tráfego que atravessa a VPN é o direcionado ao servidor OpenVPN remoto (10.10.10.1);

• Se o servidor OpenVPN remoto atrasar alguma rota e, especialmente, se o gateway padrão do VPS for substituído pelo 10.10.10.1 (ponto de extremidade OpenVPN remoto), ENTÃO você está tendo problemas. Nesse caso, você está encapsulando TODO o tráfego IP de saída (com exceção do próprio OpenVPN) na VPN.

Nesse segundo caso (substituindo def-gw logo após o estabelecimento da conexão VPN), sua conexão SSH anterior "travará", devido ao roteamento assimétrico:

• O tráfego da sua máquina (9.8.7.6) para o VPS (4.3.2.1) fluirá através do caminho anterior, nunca alterado;
• Tráfego do VPS (4.3.2.1) para sua máquina (9.8.7.6):
  • sem a VPN (portanto, inicialmente) foi roteada através do gateway 4.3.2.254;
  • após o estabelecimento do link VPN, com a substituição def-gw relacionada, ser roteado através da VPN (10.10.10.1).

Em outras palavras: assim que o link VPN for estabelecido, sua rota de retorno do VPS para sua máquina mudará e ... isso não é uma coisa boa (vários dispositivos de rede, ao longo do caminho de retorno, podem reconhecer tais assimetrias caminho e simplesmente solte pacotes).

Além disso, são grandes as chances de seu servidor OpenVPN remoto estar atuando como uma caixa NAT: todo o tráfego proveniente da VPN será NATted com o endereço IP público do servidor OpenVPN remoto. Se isso for verdade, as coisas não serão mais ... "não boas", mas definitivamente "ruins", quanto à sua conexão SSH: o tráfego de retorno, além de voltar por uma rota diferente, está voltando à sua máquina com um IP de origem diferente (o da interface pública do servidor VPN).

Como resolver este problema?

Muito facilmente, de fato.

Simplesmente instruindo o servidor VPS a não rotear o tráfego para sua máquina ao longo da VPN, mas, em vez disso, contando com a rota anterior . Deve ser tão fácil quanto adicionar antes de iniciar o OpenVPN:

     route add -host 9.8.7.6 gw 4.3.2.254

Onde:

• 9.8.7.6 é o endereço IP público da sua máquina
• 4.3.2.254 é o gateway padrão original do seu VPS.

PS: ao fornecer uma pergunta muito mais detalhada, você teria uma resposta muito mais rápida :-)

Isso pode ajudar:

coloque TCPKeepAlive=yesno seu/etc/ssh/sshd_config

A partir de

man sshd_config | less +/'^ *TCPKeepAlive'

TCPKeepAlive

Especifica se o sistema deve enviar mensagens de manutenção de atividade do TCP para o outro lado. Se forem enviados, a morte da conexão ou falha de uma das máquinas será notada corretamente. No entanto, isso significa que as conexões morrerão se a rota for interrompida temporariamente e algumas pessoas acham isso irritante. Por outro lado, se as keepalives TCP não forem enviadas, as sessões poderão travar indefinidamente no servidor, deixando usuários `` fantasmas '' e consumindo recursos do servidor.

O padrão é 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 tonão ''.

Eu tive esse problema e tentei todas as soluções recomendadas e, mesmo assim, meu problema não foi resolvido!

Depois de muitas tentativas de soluções, usei o screencomando (meu cliente VPN é cisco-any-connect).

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

Depois de fornecer sua credencial, pressione ctrl + a + d imediatamente e retorne à sua sessão.

Pessoalmente, prefiro que todas as conexões com o SSH sejam roteadas através da VPN. No caso de uma conexão ssh ativa antes de a VPN ser estabelecida, ela deve se reconectar devido à alteração da rota.

Eu recomendo usar autossh Sob a configuração do seu cliente ssh basta adicionar.ssh/config

Host *
   ServerAliveInterval 300
   ServerAliveCountMax 2
   BatchMode yes

• BatchMode significa reconexão automática
• ServerAlive significa Manter Vivo

Depois de conectar a VPN, o ssh é desconectado porque, o tráfego ssh do servidor passa pelo servidor VPN. Portanto, para evitar isso, execute o seguinte comando antes de conectar a VPN.

rota add -host sua-máquina-pública-ip gw Servidor-gatway-ip dev eth0

your-machine-public-ip: IP da sua máquina de onde você está executando o SSH. Server-gatway-ip: IP do Gatway / roteador desse servidor

O comando acima redirecionará o tráfego através do gateway fornecido, não através do servidor VPN.