Resumo rápido: A porta encaminhada funciona a partir do mundo exterior, mas a partir da rede interna utilizando o IP externo, a ligação é recusada.
Esta é uma situação simplificada para facilitar a explicação:
Eu tenho um computador que está executando um serviço na porta 12345. Este computador tem um IP interno 192.168.1.100 e está conectado diretamente a um modem / roteador que tenha IP interno 192.168.1.1 e externo (público, estático) IP 1.2.3.4. (O roteador é TP-LINK TD-w8960N) Configurei o encaminhamento de porta (servidor virtual) na porta 12345 para ir para a porta 12345 em 192.168.1.100.
Se eu executar o telnet 192.168.1.100 12345 do mesmo computador, tudo funciona. Mas executando telnet 1.2.3.4 12345 diz conexão recusada. Se eu fizer isso em outro computador (na mesma rede interna, conectado ao roteador), a mesma coisa acontece. Isso parece que o encaminhamento de porta não está funcionando. No entanto ...
Se eu executar um serviço de verificação de porta on-line no meu IP externo e na porta de serviço, ele diz que a porta está aberta e posso ver o servidor remoto conectando-se e fechando imediatamente a conexão. E usando outro computador que está conectado à Internet usando uma conexão móvel, eu também posso usar o telnet 1.2.3.4 12345 e obter uma conexão ativa.
Portanto, o encaminhamento de porta parece estar funcionando, mas o uso de IP externo da rede interna não funciona. Eu não tenho idéia do que pode estar causando isso, já que outra configuração muito parecida com isso (roteador diferente) funciona para mim. Eu posso acessar um serviço em execução em um servidor de dentro da rede através do IP interno e externo.
Observação: sei que posso usar o IP interno dentro da rede para acessar esse serviço. Mas se eu tenho um laptop que deve ser capaz de fazer isso tanto de dentro quanto de fora, seria chato alternar constantemente entre 1.2.3.4 e 192.168.1.100 na configuração do software.
Saída do roteador:
> iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 224.0.0.0/3
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 to:192.168.1.101
DNAT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:25 to:192.168.1.101
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:110 to:192.168.1.101
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12345 to:192.168.1.102
DNAT udp -- 0.0.0.0/0 192.168.1.1 udp dpt:53 to:217.118.96.203
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.1.0/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Até onde eu sei, você não pode fazer isso.
Tente rastrear a conexão, qualquer host na rede interna escolha 192.168.1.1 como próximo salto para 1.2.3.4, então o roteador deve lidar com essa conexão, mas eu acho que ela não pode redirecionar a conexão de dentro para dentro.
Você tem que ver qual nível de controle você tem no roteador, se ele era um servidor linux que você poderia jogar com o iptables, mas um dispositivo como esse não oferece aquele nível de controle na configuração da rede.
Deve haver algum controle de IP configurado em algum lugar bloqueando seu acesso. Você escreveu que funciona para você em uma configuração semelhante, e eu posso confirmar que isso também funciona para mim em uma configuração muito semelhante.
Você tentou executar o tcpdump na interface de rede em 192.168.1.100 para ver se os pacotes estão chegando lá na porta 12345?
tcpdump -i eth0 port 12345
Com qual endereço IP os pacotes estão chegando? Seu aplicativo talvez esteja bloqueando esse intervalo de IPs?
Você verificou suas configurações de /etc/hosts.deny e /etc/hosts.allow?
A conexão recusada parece ser de interesse aqui. Se fosse um problema de roteamento, o telnet expiraria ou não diria rota para o host. Eu começaria com um rastreamento de pacote na caixa que está hospedando o serviço e tentaria se conectar novamente através do IP público. Isso pelo menos ajudará você a ver se a conexão está passando pelo roteador. Se passar, então você deve cavar mais no host. Se não passar, provavelmente há um firewall ou algum outro parâmetro de configuração no roteador que está causando problemas. Você pode querer tentar um roteador diferente.
Eu encontrei o seguinte para trabalhar - tirado de link
Exemplo: (ip externo 1.1.1.1, rede interna 192.168.1.0/24, servidor web 192.168.1.10, roteador 192.168.1.1)
Conecte-se via SSH e digite:
iptables -t nat -A PREROUTING -d 1.1.1.1 -m tcp -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10
Repita para cada porta que você encaminhou.
Em seguida, insira a seguinte regra ONE SNAT:
iptables -t nat -A POSTROUTING -d 192.168.1.10 -s 192.168.1.0/24 -j SNAT --to-source 192.168.1.1
Parece funcionar muito bem, mas não consigo descobrir como salvá-lo para sobreviver a uma reinicialização do roteador.
Claro que não funcionaria! Quando você envia pacotes do host conectado à rede local para a versão 1.2.3.4: 12345, os pacotes passam pela rota padrão para o roteador, o que altera o endereço de destino para 192.168.1.100. Está tudo bem. Mas quando o servidor tenta responder, ele vê que o endereço de origem (ele permanece original, 192.168.1.xx) está na mesma LAN e envia pacotes diretamente, não via roteador. Então, o host não entende essas respostas, já que o endereço de origem (192.168.1.100) não é o mesmo endereço de destino dos pacotes originais (1.2.3.4)!
As melhores soluções são:
iptables no servidor para o endereço local SNAT para 1.2.3.4