Conexão SSH recusada dentro da minha LAN

Question

Estou no Fedora 19 e tenho um problema com ssh .

O Ssh está instalado e funcionando e posso me conectar quando entro no meu lan ip. Mas quando eu tento o nome do meu servidor ( blahblah.no-ip.org ) eu recebo uma conexão recusada. O No-ip já está sendo executado como um serviço e está funcionando corretamente (enviando o ip correto).

Já configurei o encaminhamento de porta no meu roteador, também alterei a porta de ssh no serviço e no encaminhamento da porta do roteador (caso meu amado ISP tenha decidido bloquear essas portas). Mas ainda recebo uma conexão recusada e quando eu nmap o nome do host eu vejo que a porta ssh está fechada.

Uma coisa: tenho dois PCs sob o mesmo ip externo (configurei o encaminhamento de porta para o ip interno correto). Quando eu nmap blahblah.no-ip.org recebo uma porta 23 e 80 aberta. 80 parece OK, mas eu nunca iniciei o serviço de telnet na minha máquina.

Alguma ideia do que mais tentar? O roteador é zte zxv10 e o encaminhamento de porta está configurado corretamente. Digo isso porque já configurei o encaminhamento de porta para o dilúvio e ele está funcionando corretamente.

    

Answer 1

Não é possível conectar-se a um endereço IP público encaminhado pela porta de dentro da mesma LAN. Para explicar isso, vou precisar de um exemplo.

Suponhamos que o IP privado do seu roteador seja 192.168.1.1 com o IP público 10.1.1.1. Seu servidor está na porta 2222 192.168.1.2. Você configura o encaminhamento de porta de 10.1.1.1:1111 para 192.168.1.2:2222.

Se alguém na Internet (10.3.3.3) quiser falar com você, ele gera um pacote:

Source: 10.3.3.3 port 33333
Dest:   10.1.1.1 port 1111

Seu roteador recebe o pacote no 10.1.1.1 e o reescreve:

Source: 10.3.3.3 port 33333
Dest:   192.168.1.2 port 2222

Seu servidor recebe esse pacote e envia uma resposta:

Source: 192.168.1.2 port 2222
Dest:   10.3.3.3 port 33333

Seu roteador recebe o pacote em 192.168.1.1 e o reescreve:

Source: 10.1.1.1 port 1111
Dest:   10.3.3.3 port 33333

E a conexão funciona e todos estão felizes.

Agora, suponha que você se conecte de dentro da sua LAN (192.168.1.3). Você gera um pacote:

Source: 192.168.1.3 port 33333
Dest:   10.1.1.1 port 1111

Seu roteador recebe o pacote no 10.1.1.1 e o reescreve:

Source: 192.168.1.3 port 33333
Dest:   192.168.1.2 port 2222

Seu servidor recebe esse pacote e envia uma resposta:

Source: 192.168.1.2 port 2222
Dest:   192.168.1.3 port 33333

Aqui é onde nós encontramos um problema. Como o IP de destino está em sua LAN, seu servidor não envia esse pacote ao roteador para reescrever. Em vez disso, ele envia diretamente para 192.168.1.3. Mas essa máquina não está esperando uma resposta da porta 2222 do 192.168.1.2. Ela está esperando uma da porta 1011.1.1.1. E então ela se recusa a ouvir esse pacote "falso", e as coisas não funcionam.

A maneira como eu consigo contornar isso é configurar meu roteador (que também fornece DNS para minha LAN) para retornar o endereço IP privado do meu servidor quando eu procurar meu nome de host DDNS. Dessa forma, quando estou em minha rede doméstica, conecto-me diretamente ao servidor e pulo o encaminhamento de porta. (Essa solução só funciona quando os encaminhamentos de porta não estão alterando o número da porta, apenas o endereço IP. E você só pode ter um servidor por nome de host público.)

    

Answer 2

Portas 23 e 80 open são porque para conexão ao seu roteador, porta 23 para telnet para seu roteador e porta 80 para ter sua WebUI do seu roteador. Uma vez que apenas estes dois são porta aberta, o encaminhamento não está na foto. Então, um roteador reinicia e sua reinicialização do servidor SSH ajudará.