☰

Não é possível executar ping no IP estático da rede interna, apenas de fora

tag-icon • tag-icon networking ping localhost
Não é possível executar ping no IP estático da rede interna, apenas de fora

Estou executando o Ubuntu e tenho o Apache em execução, no entanto, não consigo executar ping internamente no meu IP estático nem navegar http://207.40.XXX.XXno servidor web usando meu IP estático. Só consigo fazer ping/navegarlocalhost, 127.0.0.1, and 192.168.0.120 OU 207.40.XXX.XXapenas do mundo exterior.

# cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       my-server.myhost.com my-server

# hostname
my-server

# netstat -tapn
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -                  
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:29754         0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN

Alguma idéia de por que isso não está funcionando?

Responder1

Seu gateway NAT não está se comportando de maneira que permita isso. É assim que provavelmente está funcionando:

Pingar

  1. Você envia uma solicitação de eco ICMP de 192.168.0.5 a 207.40.123.45
  2. Isso é roteado através do seu roteador.
  3. Seu gateway NAT dentro do seu roteador reescreve a solicitação para 207.40.123.45 (é o endereço IP estático)
  4. Seu roteador responde à solicitação de eco ICMP
  5. Como o seu roteador não suporta o estado ICMP, ele nunca devolve a resposta do ECHO para você.

HTTP

  1. Você envia uma solicitação de conexão TCP/80 de 192.168.0.5 para 207.40.123.45
  2. Isso roteia através do seu roteador
  3. Seu gateway NAT reescreve o pacote como chegandode207.40.123.45:41345 a 207.40.123.45:80
  4. Seu gateway NAT observa que há uma porta de encaminhamento em vigor, então encaminha o pacote para 192.168.0.120:80
  5. O servidor em 192.168.0.120 responde à tentativa de conexão de 207.40.123.45:41345
  6. Seu gateway NAT vê a resposta e reescreve o endereço Para: na resposta para 192.168.0.5:36311, mas deixa De: intocado (192.168.0.120:80)
  7. Seu computador em 192.168.0.5 recebe um pacote de 192.168.0.120 que nunca solicitou e o joga no chão.
  8. Sua conexão definha e nunca abre.

Observe que é possível que o motivo da falha do ping seja o mesmo motivo pelo qual o HTTP também está falhando. Isso é chamado de 'NAT Hairpinning'.

O que você precisa é de um gateway NAT inteligente o suficiente para que na etapa 6 ele também reescreva ofonteendereço.

Responder2

Embora a resposta de 1138 esteja correta, eu só queria dar uma explicação detalhada sobre o que é "NAT hairpin", como funciona e por que é necessário nesta circunstância. Se você não se importa com os detalhes essenciais de IP, NAT e roteamento, sinta-se à vontade para ignorar o resto da minha resposta (bastante longa).

Sem complicações, aqui está o que acontece durante uma tentativa de conexão HTTP de um cliente LAN local (192.168.0.5) para o servidor web através do endereço IP externo (207.40.123.45):

  1. 192.168.0.5 envia seu pacote SYN para 207.40.123.45, porta 80. Como 207.40.123.45 não está na rede local, esse pacote é enviado para o gateway padrão (ou seja, o roteador).

  2. O roteador, que está configurado para encaminhar 207.40.123.45:80 para 192.168.0.120:80, reescreve o endereço de destino do pacote para 192.168.0.120 e, em seguida, entrega o pacote ao servidor web.

  3. O servidor web recebe o pacote SYN e envia um pacote SYN-ACK de resposta de volta ao endereço do remetente, que é192.168.0.5. Como 192.168.0.5 está na mesma rede, o servidor web entrega o pacote diretamente para 192.168.0.5.

  4. O pacote SYN-ACK de192.168.0.120chega em 192.168.0.5, mas o host não esperava um SYN-ACK de 192.168.0.120 e, portanto, foi descartado/rejeitado. O host em 192.168.0.5 continua aguardando uma resposta SYN-ACK de 207.40.123.45, mas é claro que esse pacote nunca chegará. A tentativa de conexão eventualmente atingirá o tempo limite, talvez após algumas tentativas e, por fim, o cliente e o servidor da web não conseguirão estabelecer uma conexão.

Este problema pode ser resolvido pelo roteador na etapa 2, aplicando um "hairpin NAT". Resumindo, a solução é enganar o cliente e o servidor web para que enviem seu tráfego mútuo através do roteador. Isto é conseguido de forma inteligente aplicandouma segunda fase do NATna etapa 2, além da fase normalmente aplicada para encaminhamento de porta. Aqui está a sequência novamente, desta vez com o NAT adicionado:

  1. Como antes, 192.168.0.5 envia seu pacote SYN destinado a 207.40.123.45, porta 80, para o roteador.

  2. Como antes, o roteador recebe o pacote SYN e, de acordo com a regra de encaminhamento de porta configurada, reescreve o endereço de destino para 192.168.0.120. Desta vez, porém, o roteador percebe que está prestes a "encaixar" o pacote de volta na mesma rede da qual foi recebido, então ele também reescreve o pacote do pacote.Endereço de Origempara o próprio endereço LAN do roteador (digamos: 192.168.0.1). O roteador então entrega o pacote ao servidor web em 192.168.0.120.

  3. O servidor web recebe o pacote SYN e envia seu pacote SYN-ACK de resposta de volta para o endereço do remetente, que, desta vez, é192.168.0.1. Assim, a resposta volta para o roteador.

  4. O roteador recebe o SYN-ACK do servidor web e reconhece que é uma resposta a um pacote que foi recentemente enviado por NAT (duas vezes). Assim, o roteador reverte ambos os NATs, e o pacote de resposta agora tem o endereço de origem 207.40.123.45 e o endereço de destino 192.168.0.5. Conseqüentemente, a resposta é entregue para 192.168.0.5, o handshake da conexão TCP continua e o cliente e o servidor web conseguem se comunicar com sucesso.

Assim, com suporte a hairpinning no roteador, o host em 192.168.0.5 pensa que está se comunicando com um servidor web em 207.40.123.45, enquanto o servidor web em 192.168.0.120 pensa que está se comunicando com um cliente no próprio roteador (192.168.0.1). Durante o hairpinning, todo o tráfego entre os dois hosts passa pelo roteador, mesmo que ambos os hosts estejam na mesma rede. Obviamente, esse é um uso abaixo do ideal dos recursos de rede e é a principal razão pela qual a configuração de um DNS dividido é geralmente preferível a depender de hairpinning.

Responder3

Que tipo de firewall você está usando? Parece que o hairpinning NAT não está ativado.

informação relacionada