☰

Não é possível fazer ssh em um servidor Linux após a alteração do ISP

tag-icon • tag-icon linux ssh linux-mint sshd
Não é possível fazer ssh em um servidor Linux após a alteração do ISP

A organização da rede da qual este servidor faz parte está mudando seu ISP. Quando mudo este servidor para novos valores de IP, gateway, etc., não consigo mais me conectar a ele via ssh. Fui a uma das ferramentas de verificação de porta e quando verifiquei a porta 22 ela retornou "Não consegui ver seu serviço em _new_IP_value_ na porta 22".

O novo IP é estático. Não há roteador no servidor em questão, nem encaminhamento de porta – o cabo de rede vai direto para o servidor.

Naturalmente, pensei que a rede da organização ou o novo ISP estava bloqueando a porta 22, então liguei para o administrador da rede e pedi para abri-la ou pedi ao ISP para abri-la. Ele disse que sim. Mas nada mudou. Liguei para ele um dia depois com a mesma pergunta, mas dava para perceber que ele estava ocupado - disse que fez o que eu pedi e basicamente desligou na minha cara.

Então, agora estou pensando que talvez haja algo errado com as configurações do servidor, afinal. Mas todas as ferramentas do Linux, como lsof, netstat, nmap, etc., informam que o sshd está funcionando e ouvindo na porta 22, a porta 22 está aberta, etc. rede do antigo ISP - tudo que eu troco é IP, gateway, DNS, nada mais.

Poderia haver algo neste servidor que esteja bloqueando as conexões ssh quando o servidor estiver na rede do novo ISP, mas não na rede antiga? O sistema operacional é Linux Mint.

Responder1

Execute uma captura de pacotes no cliente e uma captura de pacotes no servidor. As ferramentas mais comuns são Wireshark e tcpdump:

tcpdump -n -i eth0 "(tcp port 22 or 3389) or icmp or icmp6"

  • Se você vir os pacotes TCP SYN saindo do cliente, mas não chegando ao servidor, o problema geralmente está na rede - provavelmente no ISP do servidor, porque as ferramentas on-line de verificação de porta descartaram a possibilidade de o ISP do lado do cliente ser o diferente.

    (Talvez o administrador não tenha aberto as portas ou não as tenha aberto para o endereço correto. Não é incomum que a porta 3389 também seja fechada no nível do ISP.)

    Acho tcptracerouteque pode ajudar a descobrir até onde os pacotes vão antes de desaparecer.

  • Se você vir pacotes TCP SYN chegando ao servidor, mas não sendo respondidosde forma alguma, o problema está no servidor. Pode ser o firewall interno do servidor (tcpdump recebe pacotesanteseles atingiram o firewall), então verifique se você tem alguma regra de iptablesequaisquer regras NFT.

    Certifique-se também de que o servidor tenha umrota de voltapara o cliente e que ele realmente vá para o gateway correto através da interface correta:

    ip -4 route get <client_ip>
ip -4 route show match <client_ip>

    Execute também systemctl cat sshdpara verificar se há alguma lista de permissões de endereços IP no nível do cgroup. Execute também ip xfrm policypara verificar se há alguma política IPsec.

  • Se você vir pacotes TCP SYN chegando, mas eles gerarem respostas TCP RST – ainda pode ser o firewall ou pode ser que o daemon SSH esteja configurado paraouvirno endereço errado. (Você não mencionou o queEndereço localé mostrado por lsof/netstat próximo à "porta 22". Se mostrar 0.0.0.0:22 ou [::]:22 isso é bom, mas se mostrar o endereço antigo, ele deve ser alterado em sshd_config.)

  • Se você vir pacotes TCP SYN chegando, respostas SYN/ACK saindo do servidor, mas o cliente nunca recebe essas respostas – também um problema de rede e, novamente, provavelmente no lado do ISP do servidor.

informação relacionada