Não é possível efetuar ping de IP estático da rede interna, somente de fora

Question

Estou executando o Ubuntu e tenho o Apache em execução, no entanto, não consigo executar o ping internamente para meu IP estático nem procurar http://207.40.XXX.XX do servidor da web usando meu IP estático. Só posso fazer ping / procurar localhost, 127.0.0.1, and 192.168.0.120 OU 207.40.XXX.XX apenas no mundo externo.

# 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?

    

Answer 1

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

Ping

1. Você envia uma solicitação de eco ICMP de 192.168.0.5 a 207.40.123.45
2. Esta rota é enviada pelo seu roteador.
3. O seu gateway NAT dentro do seu roteador reescreve o pedido para ser de 207.40.123.45 (é endereço IP estático)
4. Seu roteador responde à solicitação de eco ICMP
5. Como o seu roteador não suporta o estado do ICMP, ele nunca passa a resposta do ECHO de volta para você.

HTTP

1. Você envia uma solicitação de conexão TCP / 80 de 192.168.0.5 a 207.40.123.45
2. Esta rota é enviada pelo seu roteador
3. Seu gateway NAT reescreve o pacote como sendo de 207.40.123.45:41345 para 207.40.123.45:80
4. Seu gateway NAT observa que há uma porta de entrada no lugar, 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 o 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 coloca no chão.
8. Sua conexão definha e nunca se abre. '

Note que é possível que o motivo da falha do ping seja devido à mesma razão que o HTTP também está falhando. Isso é chamado 'NAT Hairpinning'.

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

    

Answer 2

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

Sem hairpinning, aqui está o que acontece durante uma tentativa de conexão HTTP de um cliente de rede 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, este 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 da Web.

3. O servidor da 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 da web entrega o pacote diretamente para 192.168.0.5.

4. O pacote SYN-ACK de 192.168.0.120 chega a 192.168.0.5, mas o host não esperava um SYN-ACK de 192.168.0.120 e, portanto, é descartado / rejeitado. O host em 192.168.0.5 continua a aguardar uma resposta SYN-ACK de 207.40.123.45, mas é claro, esse pacote nunca chegará. A tentativa de conexão acabará com o tempo limite, talvez depois de algumas poucas tentativas e, em última análise, o cliente e o servidor da Web falharão ao estabelecer uma conexão.

Este problema pode ser resolvido pelo roteador na etapa 2, aplicando um "hairpin NAT". Em resumo, a solução é enganar o cliente e o servidor da Web para enviar seu tráfego mútuo através do roteador. Isso é habilmente realizado aplicando uma segunda fase do NAT na etapa 2, além da fase normalmente aplicada para o encaminhamento de porta. Aqui está a sequência novamente, desta vez com o NAT adicionado em hairpinning:

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, conforme sua regra de encaminhamento de porta configurada, ele reescreve o endereço de destino para 192.168.0.120. Desta vez, no entanto, o roteador percebe que está prestes a "puxar" o pacote de volta para a mesma rede da qual foi recebido, por isso também reescreve o endereço de origem do pacote para a própria LAN do roteador. endereço (diga: 192.168.0.1). O roteador entrega o pacote ao servidor da web em 192.168.0.120.

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

4. O roteador recebe o SYN-ACK do servidor da Web e reconhece que é uma resposta a um pacote que recentemente recebeu NAT (duas vezes). Portanto, o roteador reverte os dois 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. Assim, a resposta é entregue para 192.168.0.5, o handshake da conexão TCP continua, e o cliente e o servidor da Web podem se comunicar com êxito.

Assim, com suporte ao hairpinning no roteador, o host em 192.168.0.5 acha que está falando com um servidor web em 207.40.123.45, enquanto o servidor web em 192.168.0.120 acha que está falando com um cliente no próprio roteador (192.168.0.1 ). Quando hairpinning, todo o tráfego entre os dois hosts passa pelo roteador, mesmo que ambos os hosts estejam na mesma rede. Este é obviamente um uso sub-ótimo de recursos de rede, e é a principal razão pela qual a configuração de um DNS dividido geralmente é preferível a confiar em hairpinning.

    

Answer 3

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