Não é possível conectar-se ao servidor SSH usando o endereço IP da WAN [duplicado]

Question

Eu tenho um servidor SSH atrás de um roteador NAT. As máquinas na mesma rede (NAT) do servidor SSH só podem se conectar ao servidor SSH usando o IP da LAN, não o IP da WAN. Por quê?

Minha rede é assim:

(the Internet, via Comcast)
      |
      | (cable line)
  comcast modem. ← External IP of a.b.c.d,
      |            internal IP of 10.1.10.1 on 10.1.10.0/24
      |
      |
   box running sshd  (10.1.10.201)

Eu executo um serviço SSH atrás de um roteador Comcast que executa NAT. Usando o endereço IP obtido acima, posso executar ssh me@«that IP» de qualquer lugar na Internet e recebo meu serviço SSH. Se eu executar o mesmo comando dentro da rede 10.1.10.0/24 dentro do roteador, a conexão expirará.

O roteador Comcast é configurado para fazer o encaminhamento de porta para a máquina SSH na porta padrão.

• O roteador da comcast responde a pings, tanto nos IPs internos quanto externos.
• A caixa que está executando sshd responde a pings

O dispositivo é um pedaço de de lixo SMC Networks SMCD3G.

Realizando um wireshark na máquina sshd , enquanto a tentativa de ssh 10.1.10.201 gera tráfego de aparência normal. A tentativa de um ssh a.b.c.d fornece o seguinte:

Source       Destination  Info
10.1.10.11   10.1.10.201  39946 > ssh [SYN] Seq=0 Win=14600 Len=0 MSS=1460
10.1.10.201  10.1.10.11   ssh > 39946 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0
10.1.10.11   10.1.10.201  39946 > ssh [RST] Seq=1 Win=0 Len=0

10.1.10.11     10.1.10.201  39946 > ssh [SYN] Seq=0 Win=14600 Len=0 MSS=1460
10.1.10.201  10.1.10.11   [TCP Previous segment lost] ssh > 39946 [SYN, ACK] Seq=46941561
10.1.10.11   10.1.10.201  39946 > ssh [RST] Seq=1 Win=0 Len=0

(the last three lines repeat)

Os pacotes parecem estar chegando lá, mas a máquina de conexão está enviando um RST. Por quê?

Do lado do cliente (a máquina que executa o SSH), uma tentativa posterior parecia:

Source       Destination  Info
10.1.10.11   a.b.c.d      40212 > ssh [SYN] Seq=0 Win=14600 Len=0 MSS=1460
10.1.10.201  10.1.10.11   ssh > 40212 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460
10.1.10.11   10.1.10.201  40212 > ssh [RST] Seq=1 Win=0 Len=0

10.1.10.11   a.b.c.d      [TCP Retransmission] 40212 > ssh [SYN] Seq=0 Win=14600 Len=0 MSS=1460
10.1.10.201  10.1.10.11   [TCP Previous segment not captured] ssh > 40212 [SYN, ACK] Seq=15635206
10.1.10.11   10.1.10.201  40212 > ssh [RST] Seq=1 Win=0 Len = 0

(the last three lines repeat)

A única coisa que se destaca é que eu estou continuamente obtendo "Segmento anterior não capturado" (não foi? Parece estar bem ali), e que os números de sequência do cliente são realmente determinísticos. (Eles não deveriam começar em um ponto aleatório, e incrementar a partir daí?)

    

Answer 1

Como eu disse no meu comentário. Para poder usar seu ip público dentro de sua LAN, você precisará de algo chamado NAT Loopback , também conhecido como NAT hairpinning ou NAT reflection .

Você pode ler sobre isso aqui

Tanto quanto eu posso encontrar na internet o seu pedaço de ... uuuh ... "SMC Networks SMCD3G" não suporta "NAT Loopback".

Você tem duas opções:

1. Você pode adicionar uma linha 10.1.10.201 fake_or_real_hostname no seu arquivo de hosts.
   Você pode se conectar como ssh me@fake_or_real_hostname .

2. Você pode executar seu próprio servidor DNS local. Aqui é alguma explicação.

I solved the same problem you are having by running my own local DNS server that recurses to OpenDNS for non-local domains, and creating zones with local DNS A and PTR records that resolve my external hostname to the LAN IP of that host.

Em ambos os casos, é melhor usar um nome de host em vez de um ip. Você poderia usar um serviço de nome de host dinâmico para obter um nome de host (como myname.dyndns.org) se seu ip público muda muito. Também é mais fácil de lembrar. E no caso de você ir para a opção 1, você pode adicionar esse nome em seu arquivo de hosts.

Algumas delas são:
DynDNS
FreeDNS
ZoneEdit No-Ip

Meu modem tem a opção de registrar automaticamente alterações de IP com esses serviços. Também existem utilitários de desktop que podem atualizá-lo quando você muda o ip público.

    

Answer 2

O que você quer às vezes é chamado de corte de cabelo no roteador

Se o seu roteador suporta isso, como é chamado e como está configurado, depende da marca e modelo do roteador (quais informações não estão atualmente na sua pergunta)

Outra solução para o mesmo problema é usar o DNS de horizonte dividido e fazer referência ao servidor pelo nome. No entanto, isso não é fácil de configurar se você está atualmente contando com um roteador SOHO típico para fazer todo o seu DHCP + DNS.

    

Answer 3

Para adicionar a resposta de Rik: o meu particular está em falta aqui: está apenas parcialmente fazendo a coisa certa, e no final, está bagunçando o NAT.

10.1.10.11   a.b.c.d      40212 > ssh [SYN] Seq=0 Win=14600 Len=0 MSS=1460
10.1.10.201  10.1.10.11   ssh > 40212 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460
10.1.10.11   10.1.10.201  40212 > ssh [RST] Seq=1 Win=0 Len=0

Note cuidadosamente as conexões aqui. Primeiro, vemos um SYN (esperado) de 10.1.10.11 (o cliente ssh, isso é normal) para a.b.c.d (também normal). O servidor, no entanto, recebe isso como 10.1.10.11 → 10.1.10.201 . O IP de destino foi substituído pelo roteador, NAT fashion, correto. O IP de origem, no entanto, não foi substituído. Aqui, devemos ter a conexão ( 10.1.10.201 & a.b.c.d ), mas em vez disso, temos ( 10.1.10.201 & 10.1.10.11 ). O roteador fez apenas metade do trabalho necessário.

A conexão, para o servidor, é ( 10.1.10.201 & 10.1.10.11 ). Para o cliente, é ( 10.1.10.201 & a.b.c.d ) ¹. Quando o cliente obtém o SYN / ACK para o ( 10.1.10.201 & 10.1.10.11 ), o sistema operacional (com razão) envia um RST - ele não tem conhecimento de essa conexão.

¹Note que os números de porta são importantes para determinar as conexões, mas, para simplificar, deixei de fora.