Tempo limite de conexão para o servidor ssh

Question

Estou tentando configurar o openssh-server, mas estou tendo alguns problemas de conexão. Eu mudei a porta para algo não-padrão (57757) e, em seguida, defina meu roteador para encaminhar para essa porta. Na minha LAN, eu consigo fazer ssh na minha máquina usando a porta 57757, mas não consigo fazer isso na WAN.

Se eu estiver fora da LAN e tentar acessar minha máquina por uma porta incorreta, recebo imediatamente uma mensagem "conexão recusada". No entanto, com a porta correta, apenas trava e, em seguida, os tempos limite.

O que posso tentar para depurar o problema? Eu tentei um traceroute, mas não me disse nada útil.

EDIT: Eu percebi que o meu problema era que meu roteador não suportava acessá-lo pelo IP da WAN internamente. Eu ssh'd para um servidor diferente e de volta e funcionou bem.

    

Answer 1

Geralmente, isso significa que você redirecionou a porta para o endereço IP errado na LAN.

Seu roteador NAT recebe tráfego de entrada na porta 57757 e o envia para um determinado endereço IP e porta na LAN .

Por padrão, o Ubuntu não filtra as tentativas de conexão de entrada com um firewall. Portanto, a menos que você tenha alterado as configurações de firewall no Ubuntu, uma tentativa de abrir uma conexão com qualquer porta TCP, de 1 a 65535, irá:

• aceite a conexão, se a porta estiver aberta
• rejeitar a tentativa de conexão, se a porta estiver fechada

Se as portas fossem filtradas por um firewall, você obteria o que está vendo - sem resposta a uma tentativa de conexão. Mas:

• a menos que você tenha alterado as configurações do firewall (por exemplo, ufw , iptables ), nenhuma porta será filtrada, e
• em qualquer caso, você pode se conectar à porta 22 na LAN, por isso é aberto.

Quando você encaminha uma porta para uma máquina inexistente com um roteador NAT, ela envia o tráfego de entrada naquela porta para a máquina inexistente, o que significa que ela é enviada para um preto buraco ; é efetivamente eliminado.

Isso causa exatamente a situação que você descreveu. Portanto, você pode corrigir isso certificando-se de que a porta está sendo encaminhada para o endereço IP correto na rede local.

Se isso não for o problema ...

... então você terá que resolver o problema.

1. A porta especificada para o lado da LAN está correta? Ou seja, supondo que você não tenha alterado a configuração do servidor SSH, a porta 57757 no lado da WAN está definida para encaminhar para a porta 22 no servidor OpenSSH? (Você pode querer verificar isso novamente.)

2. Talvez haja algum problema com a porta específica que você escolheu (57757). Tente um diferente e veja se isso funciona melhor.

   (Se isso não acontecer, e você continue com estas instruções, altere-o de volta ou substitua "57757" abaixo pelo novo número.)

3. Tente reiniciar o servidor OpenSSH. Isso pode ajudar se houver um problema de rede. Se isso não ajudar, tente reiniciar o roteador e o modem a cabo / DSL / ISDN também.

   Se por algum motivo você não puder reiniciar todos os três dispositivos, recomendo que você reinicie o que puder. Se você não pode reiniciar o serviço OpenSSH, pelo menos você pode reiniciar o serviço e (mais provável para corrigir isso) derrubar a interface e trazê-lo novamente.

   Para reiniciar o servidor OpenSSH:

   sudo restart ssh
   

   Para diminuir a interface de rede, primeiro descobrir em que interface está:

   ifconfig
   

   Normalmente, para uma máquina com uma única placa Ethernet e / ou uma única placa sem fio, a Ethernet é eth0 e a rede sem fio é wlan0 .

   Se a conexão Ethernet com fio for o que você deseja desativar e reiniciar, execute:

   sudo ifdown eth0
   

   Em seguida, execute:

   sudo ifup eth0
   

   Como alternativa, você pode executar:

   sudo ifconfig eth0 down
   

   Seguido por:

   sudo ifconfig eth0 up
   

   Se a máquina estiver usando o NetworkManager para gerenciar a interface na qual o servidor OpenSSH está sendo executado, eu ainda recomendo tentar as formas acima, mas você também pode tentar desconectar e reconectar no NetworkManager.

   Para uma conexão Ethernet, tente também desconectar o cabo e conectá-lo novamente. Para uma conexão sem fio, tente desligá-lo com o interruptor de hardware (se houver) e ligue-o novamente.

   Algo estranho está acontecendo aqui e nada disso leva muito tempo - vale a pena ser cuidadoso antes de realizar etapas de solução de problemas mais meticulosas.

4. Como você está tentando acessá-lo do lado da WAN? Se você estiver usando uma máquina na LAN para fazer isso (apenas conectando da LAN ao IP da WAN do seu roteador), isso é suportado apenas para alguns roteadores. Afinal, o trabalho de um roteador é rotear o tráfego entre os lados da WAN e da LAN, não para rotear o tráfego de um lado para o outro. O suporte para conectar-se a portas encaminhadas no IP da WAN de dentro da LAN é, na verdade, a exceção e não a regra, embora muitos roteadores de home / office tenham esse recurso.

   Portanto, se você não estiver testando a porta para frente de um host no lado da WAN, deverá fazê-lo. Suas opções para isso são:

   • Conecte-se do lado da WAN. Funciona se você tiver acesso a uma máquina, por exemplo, acesso SSH a uma máquina remota na escola, no trabalho, na casa de um amigo ou semelhante.

   • Conecte a máquina de teste entre o roteador e o que estiver fornecendo sua conexão à Internet. Se você tiver um modem a cabo / DSL / ISDN com um Porta Ethernet e seu roteador conectados a ele, você pode conectar um switch ao modem e conectar o roteador ao switch. Conecte um computador ao switch. Primeiro veja se essa máquina só recebe acesso à Internet - atualmente, muitos provedores fornecem dois ou mais endereços IP separados. Se não o fizer , aceda à página de configuração do seu router e verifique o seu IP da WAN e a máscara de sub-rede da WAN , em seguida, atribua estaticamente um endereço IP à máquina conectada ao switch que esteja dentro da mesma sub-rede.

     Este método tem algumas desvantagens. É uma dor! Além disso, é teoricamente possível que um ISP configure sua rede incorretamente para que a máquina de teste conectada ao switch possa acessar a Internet. (A menos que seja sua intenção de ISP deixar você se conectar com mais de um IP WAN e você tenha escolhido um IP WAN para a máquina de teste que seu ISP lhe atribuiu, tráfego entre ele e um verdadeiro O host da WAN deve ser bloqueado / interrompido pelo ISP, mas alguns ISP's têm práticas estranhas, então quem sabe?) Se isso acontecer, provavelmente não causará problemas sérios a ninguém (e mesmo que isso aconteça, você só estará conectado por alguns minutos). No entanto, ele pode ser visto como uma tentativa de obter acesso adicional além dos limites da sua assinatura e, mais importante, se outro usuário tiver esse mesmo IP, ele poderá interferir na conexão. Portanto, se você quiser tentar este método , não tente acessar a Internet a partir da máquina de teste, pare imediatamente se você achar que a máquina de teste pode acessar a Internet, e não tente isso em tudo se for proibido ou desaconselhado pelo seu ISP. (E não use isso se o lado da WAN do seu roteador for uma LAN do escritório, sem antes consultar o administrador da rede. Isso não é um ISP e não há suposição de que os recursos sejam provisionados para impedir o acesso indesejado.)

     Existe uma variação nessa técnica que às vezes é mais apropriada. Seu roteador provavelmente obtém suas informações de conexão - endereço IP, máscara de sub-rede, o endereço IP do gateway (roteador) na WAN que ele usa quando não sabe para onde enviar algo e informações sobre servidores DNS - do seu provedor, via DHCP, através do modem a cabo / DSL / ISDN. É por isso que você precisa ter o roteador conectado ao modem para fornecer a configuração necessária para que os resultados do teste da WAN sejam significativos. Mas o roteador normalmente lembrará essas informações, desde que elas estejam realmente conectadas a uma rede no lado da WAN. Assim, você pode conectar o roteador, o modem e a máquina de teste, mas rapidamente antes de fazer qualquer coisa com a máquina de teste, além de certificar-se de que o switch a veja como conectada , desconecte o modem.

   • Use um serviço gratuito na Internet para testar suas portas. Desde inserir uma máquina de teste entre a interface WAN do seu roteador e a Internet (acima) é altamente envolvida - e uma vez que mostrará uma porta como acessível, mesmo que seja inacessível devido a ser bloqueado pelo seu ISP (que também é válido para se conectar ao IP da WAN do roteador do lado da LAN) - geralmente é melhor usar um serviço de varredura de portas baseado na web.

     Existem muitos serviços de varredura de portas. (Alguns usam a frase "verifique seu firewall" com a ideia de que a maioria das pessoas está tentando bloquear em vez de facilitar o acesso.) Este é um. Se você escolher usar esse, clique em Continuar , digite 57757 na caixa de texto e clique em < em> Use Specified Custom Port Probe . Para que um servidor seja executado, você deseja que ele seja "aberto". "Fechada" significa que a porta está acessível, mas o servidor não está em execução (e, portanto, a tentativa de conexão foi rejeitada). "Furtividade" significa que a porta estava inacessível - é como se nenhuma máquina estivesse localizada lá (ou como se a porta fosse encaminhada onde não há máquina).

5. OK, você determinou que realmente não é acessível pela Internet. Potencialmente você pode digitalizá-lo (idealmente do lado da WAN) para obter detalhes, embora muitas vezes isso não forneça informações úteis.

   Se você quiser fazer isso, então, no lado da WAN, você pode executar:

   sudo nmap -sS -sV -p57757 -vv WAN-IP

   Se a porta for mostrada como filtrada, isso confirma que os pacotes enviados provavelmente não estão indo a lugar nenhum (ou são bloqueados / descartados ao longo do caminho).

6. Vale a pena verificar se o problema está surgindo da porta exposta à WAN sendo diferente da porta na qual o servidor está realmente escutando. Encaminhar a porta 55757 na WAN para a porta 22 na máquina LAN deve fazer as coisas funcionarem bem, mas talvez em algum lugar (o servidor, o cliente) algo esteja assumindo que o número da porta é o mesmo do servidor e da perspectiva do cliente.

   Presumivelmente, você não pode encaminhar a porta 22 pelo roteador. Talvez o seu ISP bloqueie essa porta. Mas se você puder fazer isso, faça isso!

   Caso contrário, você pode fazer o servidor OpenSSH realmente escutar na porta 57757.

   Para fazer isso, faça backup do arquivo de configuração do servidor:

   cd /etc/ssh
   sudo cp sshd_config sshd_config.old
   

   Em seguida, edite-o:

   gksu gedit sshd_config
   

   Ou use um editor de texto do console se a máquina não tiver uma GUI:

   sudo nano -w sshd_config
   

   Perto da parte superior do arquivo, este bloco de texto é exibido:

   # What ports, IPs and protocols we listen for
   Port 22
   # Use these options to restrict which interfaces/protocols sshd will bind to
   #ListenAddress ::
   #ListenAddress 0.0.0.0
   Protocol 2
   # HostKeys for protocol version 2
   HostKey /etc/ssh/ssh_host_rsa_key
   HostKey /etc/ssh/ssh_host_dsa_key
   HostKey /etc/ssh/ssh_host_ecdsa_key
   #Privilege Separation is turned on for security
   UsePrivilegeSeparation yes
   

   Basta alterar a linha Port 22 na parte superior, para dizer Port 57757 .

   • Você poderia adicionar uma porta em vez de alterá-la. Eu recomendo testar com a configuração efetiva mais simples, no entanto.

     Veja man sshd_config para mais detalhes sobre a configuração do servidor OpenSSH.

   Salve o arquivo, feche o editor de texto e reinicie o servidor SSH com:

   sudo restart ssh
   

   Agora altere a porta para a frente no roteador para que a porta 57757 envie para a porta 57757 (não 22) no servidor OpenSSH e veja se ela está acessível a partir da Internet.

7. Se ainda não estiver funcionando, veja se talvez o firewall do Ubuntu esteja bloqueando o tráfego originado de fora da LAN.

   (Isso é improvável se você não configurou isso sozinho, mas se todas as suas configurações estiverem corretas e nenhuma das etapas acima revelou algo sobre o problema, vale a pena verificar.)

   Executar:

   sudo iptables -L
   

   Por padrão, no Ubuntu, a saída se parece com:

   Chain INPUT (policy ACCEPT)
   target     prot opt source               destination         
   
   Chain FORWARD (policy ACCEPT)
   target     prot opt source               destination         
   
   Chain OUTPUT (policy ACCEPT)
   target     prot opt source               destination
   

   Esta é uma política permissiva simples, essencialmente equivalente a não executar um firewall. (Na verdade, se o módulo de firewall netfilter não fosse compilado em seu kernel, seu sistema se comportaria da mesma forma que as configurações acima, embora o comando iptables , que consulta as configurações de netfilter , não funcionasse claro.)

   Se a sua configuração não for assim, leia man iptables para descobrir o que eles estão fazendo e / ou editar sua pergunta (ou, se você for uma pessoa diferente com um problema semelhante lendo isso, postar uma nova pergunta) para incluí-los. Tenha em atenção que, potencialmente, as regras de iptables podem divulgar informações confidenciais sobre a sua configuração. Praticamente falando, isso geralmente não é o caso - com a possível exceção de regras sobre hosts específicos que são bloqueados, ou se sua configuração é muito ruim / insegura - normalmente a utilidade dessas informações para um invasor, especialmente para uma máquina em uma LAN doméstica / comercial atrás de um roteador NAT é mínima.

Answer 2

Como funciona dentro de sua LAN, sua configuração do servidor parece estar correta. Você deve informar ao seu roteador para encaminhar a partir da porta que deseja usar no fora para a porta 57757 em sua máquina . Um traceroute será inútil neste caso.