Não foi possível acessar o serviço externo a partir da LAN

Eu tenho um problema estranho de encaminhamento de porta. Tentei abrir minha porta 22 para a rede externa. Consegui acessá-lo desde que não estivesse dentro da LAN. Eu posso acessá-lo no meu escritório, por exemplo. Mas de dentro da LAN, posso acessar a porta usando o IP local, mas não consigo acessar a porta usando o IP externo. É como se o roteador estivesse bloqueando o loopback. Verifiquei todas as configurações do meu roteador, desliguei qualquer coisa relacionada a firewall / filtragem. Alguma ideia?

Supondo que o Spiff esteja correto, e seu roteador não possa lidar com o encaminhamento de porta para o ip externo de dentro da rede, há um pequeno trabalho ao redor (e parece que é esse o caso);

Você pode editar o arquivo hosts, que pode ser encontrado em / etc / hosts na maioria dos sistemas unix e em C: \ Windows \ system32 \ drivers \ etc \ no Windows.

se você adicionar

192.168.0.15  example.com

nesse arquivo, seu computador acessará o ip especificado sempre que você tentar acessar example.com. Obviamente, você precisará fazer isso em todos os computadores que desejar usar na rede.

Você pode verificar o artigo da wikipedia para obter mais detalhes sobre onde encontrá-lo: https://en.wikipedia.org/wiki/Hosts_file

Como você mencionou o encaminhamento de porta, presumo que seu gateway doméstico esteja agindo como um gateway NAT - ou mais especificamente NAPT -. O que você está tentando fazer é chamado de "hairpin NAT" ou "NAT hairpinning", em referência à maneira como um alfinete de cabelo literal se dobra novamente (a mesma alusão é usada pelo termo "hairpin turn" para uma curva acentuada onde uma estrada se dobra novamente).

Alguns gateways NAT são uma porcaria e não suportam hairpinning. Talvez seja hora de explorar suas opções de atualização.

Há uma resposta muito simples a esta. O NAT está atrapalhando.

1. O seu computador abre uma conexão com [ExternalIP]
2. Seu roteador encaminha essa conexão para o [SSHInternalIP]. O servidor SSH vê uma conexão do [YourInternalIP].
3. Seu servidor SSH envia seus pacotes para [YourInternalIP].
4. Seu computador vê um pacote estranho vindo de um IP com o qual nunca falou e o descarta.
5. Sua conexão com o TCP / 22 falha porque o handshake de 3 vias do TCP nunca é concluído.

Você está tentando falar com um IP público, mas as respostas são provenientes de um IP interno. Seu computador não pode fazer com que os dois funcionem juntos. A solução é usar o IP interno sempre que você estiver atrás do roteador. Eu trabalho com esse problema nos meus laptops usando diferentes cadeias de conexão ssh, dependendo de onde estou.

Pelo que entendi ao rodar um roteador OpenBSD com NAT, Spiff está correto em sua resposta: o problema que você está enfrentando é causado pelo gateway NAT que não suporta o que você está tentando fazer.

Sua estação de trabalho está enviando pacotes com um IP de origem de um endereço interno (por exemplo, 10.0.0.2), mas o endereço de destino é o seu IP externo. Quando os pacotes chegam ao seu servidor (SSH?) Na porta 22, o servidor responde diretamente à sua estação de trabalho e não há NAT acontecendo; agora, quando sua estação de trabalho recebe uma resposta da 10.0.0.3 quando esperava uma resposta do seu endereço externo, ela descarta os pacotes.

Parece um problema trivial em questão, mas pode ser resolvido atualizando o arquivo HOSTS da estação de trabalho, adicionando um servidor DNS interno (ou editando as entradas do servidor DNS) ou criando uma regra NAT para lidar com o interno-> externo-> interno tráfego.