☰

A conexão SSH congela no hotspot 4G, mas não em qualquer Wifi

tag-icon • tag-icon ssh openssh
A conexão SSH congela no hotspot 4G, mas não em qualquer Wifi

Pequena descrição

Há anos que tenho visto um comportamento estranho na minha conexão SSH, mas nunca pensei em levantar uma questão até hoje. Tentei pesquisar muito sobre isso, mas não consegui encontrar nenhum motivo.

Ambiente

  1. Basicamente, tenho várias instâncias do AWS EC2 em execução em diferentes regiões (como Irlanda, Mumbai etc.).
  2. Eu tenho um Mac.
  3. E estou localizado na Índia (caso isso atinja alguém por algum motivo).

Declaração do problema 1

Quando meu Mac está conectado a um ponto de acesso pessoal (de um dispositivo Samsung ou de um iPhone) pela rede 4G, minha conexão SSH congela após alguns minutos (não mais que 3) se eu não trabalhar na sessão SSH (basicamente, o A conexão SSH funcionou perfeitamente). Então eu tenho que continuar pressionando a tecla de seta apenas para mantê-lo vivo.

Declaração do problema 2 (que não é um problema)

Mas quando meu Mac está conectado a uma conexão de banda larga Wifi, esse problema nunca ocorre. Minha conexão SSH permanece conectada por horas mesmo depois que eu desperto meu Mac do modo de espera (abra a tampa).

Com base na minha pesquisa novamente no Google hoje, encontrei vários artigos que fornecem soluções para usar opções como TCPKeepAliveou ServerAliveInterval:

  1. Quais opções `ServerAliveInterval` e `ClientAliveInterval` em sshd_config fazem exatamente?
  2. Como funciona o tcp-keepalive no ssh?
  3. https://raspberrypi.stackexchange.com/questions/8311/ssh-connection-timeout-when-connecting
  4. https://patrickmn.com/aside/how-to-keep-alive-ssh-sessions/

Mas não consegui encontrar nenhum post que ditasse esse problema. Alguém de vocês tem alguma ideia sobre esse comportamento? Ficarei feliz em fornecer quaisquer detalhes possíveis sobre minha conexão de ponto de acesso 4G.

Responder1

Eu suponho que um sistema que rastreia (e esquece) conexões com estado está causando isso. Quando o NAT está em uso (e muitas vezes é o caso quando não está no IPv6), geralmente o sistema que executa o NAT precisa de memória para lembrar para onde enviar as respostas. Para sua banda larga Wifi, o sistema que faz NAT pode ter uma memória mais longa para lembrar conexões ativas (por exemplo, Linuxfiltro de rededeconexãopor padrão lembra conexões TCP por 5 dias, enquanto lembra fluxos UDP por 2 ou 3 minutos). O sistema equivalente que faz NAT no seu caminho 4G provavelmente tem uma memória mais curta, um pouco menos de 3 minutos.

Para contornar isso, conforme encontrado e vinculado em sua pergunta, você pode definir o parâmetro ssh específicoServerAliveInterval que enviará dados vazios (como protocolo SSH) periodicamente quando não houver atividade de forma semelhante aTCP KeepAlive. Isso fará com que a conexão seja sempre vista como ativa para o sistema que faz NAT, e ele não esquecerá disso. Então, no seu ~/.ssh/configarquivo você pode adicionar:

ServerAliveInterval 115

com 115 um valor escolhido para ser um pouco menor que 2mn para permanecer conservador: um valor inferior à duração estimada de rastreamento de conexões ativas no dispositivo NAT invisível no caminho, mas também não muito baixo (veja mais adiante). Na pior das hipóteses, quando o estado de rastreamento está prestes a ser excluído, ele volta à suposta vida útil de 120 anos.

A desvantagem é que (pelo menos no seu acesso de banda larga Wifi) se você perder a conectividade por algum tempo e depois recuperá-la, isso pode ter feito o cliente pensar que o servidor remoto estava inoperante e a conexão teria sido encerrada. Você também pode ajustarServerAliveCountMaxpara isso, mas de qualquer forma, se o valor padrão for 3, isso exigiria algo como 3*115=345s de perda de conectividade, mais de 5 minutos, antes de ter a chance de ter esse problema.

O lado do servidor tem um equivalenteClientAliveIntervalque você pode definir lá em seu sshd_configarquivo, para o mesmo propósito. Isso teria o benefício adicional de não manter conexões de clientes ssh fantasmas vistas como ainda conectadas por algum período de tempo quando o lado do cliente perdesse a conectividade de qualquer maneira.

informação relacionada