☰

No se puede hacer ping a una IP estática desde la red interna, solo desde afuera

tag-icon • tag-icon networking ping localhost
No se puede hacer ping a una IP estática desde la red interna, solo desde afuera

Estoy ejecutando ubuntu y apache ejecutándose, sin embargo, no puedo hacer ping internamente a mi IP estática ni navegar por http://207.40.XXX.XXel servidor web usando mi IP estática. Sólo puedo hacer ping/navegarlocalhost, 127.0.0.1, and 192.168.0.120 O 207.40.XXX.XXsólo del 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

¿Alguna idea de por qué esto no funciona?

Respuesta1

Su puerta de enlace NAT no se comporta de tal manera que lo permita. Probablemente así es como está funcionando:

Silbido

  1. Envía una solicitud de eco ICMP desde 192.168.0.5 a 207.40.123.45
  2. Esto se enruta a través de su enrutador.
  3. Su puerta de enlace NAT dentro de su enrutador reescribe la solicitud para que sea de 207.40.123.45 (es una dirección IP estática)
  4. Su enrutador responde a la solicitud ICMP Echo
  5. Dado que su enrutador no admite el estado ICMP, nunca le devuelve la respuesta ECHO.

HTTP

  1. Envía una solicitud de conexión TCP/80 desde 192.168.0.5 a 207.40.123.45
  2. Esto se enruta a través de su enrutador.
  3. Su puerta de enlace NAT reescribe el paquete como entrantede207.40.123.45:41345 a 207.40.123.45:80
  4. Su puerta de enlace NAT detecta que hay un puerto de reenvío, por lo que reenvía el paquete a 192.168.0.120:80
  5. El servidor en 192.168.0.120 responde al intento de conexión desde 207.40.123.45:41345
  6. Su puerta de enlace NAT ve la respuesta y reescribe la dirección Para: en la respuesta a 192.168.0.5:36311, pero deja el De: intacto (192.168.0.120:80)
  7. Su computadora en 192.168.0.5 recibe un paquete de 192.168.0.120 que nunca solicitó y lo tira al suelo.
  8. Tu conexión languidece y nunca se abre.

Tenga en cuenta que es posible que la razón por la que el ping falla sea por la misma razón por la que HTTP también falla. Esto se llama 'NAT Hairpinning'.

Lo que necesita es una puerta de enlace NAT lo suficientemente inteligente como para que en el paso 6 también reescriba elfuenteDIRECCIÓN.

Respuesta2

Aunque la respuesta de 1138 es correcta, solo quería brindar una explicación detallada sobre qué es la "NAT de horquilla", cómo funciona y por qué es necesaria en esta circunstancia. Si no le importan los detalles esenciales de IP, NAT y enrutamiento, no dude en ignorar el resto de mi (bastante larga) respuesta.

Sin complicaciones, esto es lo que sucede durante un intento de conexión HTTP desde un cliente LAN local (192.168.0.5) al servidor web a través de la dirección IP externa (207.40.123.45):

  1. 192.168.0.5 envía su paquete SYN a 207.40.123.45, puerto 80. Dado que 207.40.123.45 no está en la red local, este paquete se envía a la puerta de enlace predeterminada (es decir, el enrutador).

  2. El enrutador, que está configurado para reenviar 207.40.123.45:80 a 192.168.0.120:80, reescribe la dirección de destino del paquete a 192.168.0.120 y luego entrega el paquete al servidor web.

  3. El servidor web recibe el paquete SYN y envía un paquete SYN-ACK de respuesta a la dirección del remitente, que es192.168.0.5. Dado que 192.168.0.5 está en la misma red, el servidor web entrega el paquete directamente a 192.168.0.5.

  4. El paquete SYN-ACK de192.168.0.120llega a 192.168.0.5, pero el host allí no esperaba un SYN-ACK de 192.168.0.120, por lo que se descarta/rechaza. El host en 192.168.0.5 continúa esperando una respuesta SYN-ACK de 207.40.123.45, pero, por supuesto, ese paquete nunca llegará. El intento de conexión eventualmente expirará, tal vez después de algunos reintentos y, en última instancia, el cliente y el servidor web no logran establecer una conexión.

Este problema puede ser resuelto por el enrutador en el paso 2, aplicando una "NAT de horquilla". En resumen, la solución es engañar al cliente y al servidor web para que envíen su tráfico mutuo a través del enrutador. Esto se logra hábilmente aplicandouna segunda fase de NATen el paso 2, además de la fase que normalmente se aplica para el reenvío de puertos. Aquí está la secuencia nuevamente, esta vez con la NAT de horquilla agregada:

  1. Como antes, 192.168.0.5 envía su paquete SYN destinado a 207.40.123.45, puerto 80, al enrutador.

  2. Como antes, el enrutador recibe el paquete SYN y, según su regla de reenvío de puertos configurada, reescribe la dirección de destino en 192.168.0.120. Esta vez, sin embargo, el enrutador nota que está a punto de "encadenar" el paquete nuevamente a la misma red desde la cual fue recibido, por lo que también reescribe el paquete.Dirección de la fuentea la dirección LAN del enrutador (por ejemplo: 192.168.0.1). Luego, el enrutador entrega el paquete al servidor web en 192.168.0.120.

  3. El servidor web recibe el paquete SYN y envía su paquete SYN-ACK de respuesta a la dirección del remitente, que, esta vez, es192.168.0.1. Así, la respuesta vuelve al enrutador.

  4. El enrutador recibe el SYN-ACK del servidor web y reconoce que es una respuesta a un paquete al que recientemente realizó NAT (dos veces). Entonces, el enrutador invierte diligentemente ambas NAT y el paquete de respuesta ahora tiene la dirección de origen 207.40.123.45 y la dirección de destino 192.168.0.5. Por lo tanto, la respuesta se entrega a 192.168.0.5, el protocolo de enlace de la conexión TCP continúa y el cliente y el servidor web pueden comunicarse exitosamente.

Por lo tanto, con soporte de horquilla en el enrutador, el host en 192.168.0.5 cree que está hablando con un servidor web en 207.40.123.45, mientras que el servidor web en 192.168.0.120 cree que está hablando con un cliente en el enrutador mismo (192.168.0.1). Cuando se realiza una horquilla, todo el tráfico entre los dos hosts pasa a través del enrutador, aunque ambos hosts estén en realidad en la misma red. Obviamente, se trata de un uso subóptimo de los recursos de la red y es la razón principal por la que suele ser preferible configurar un DNS dividido que depender de la horquilla.

Respuesta3

¿Qué tipo de firewall estás usando? Parece que la horquilla NAT no está activada.

información relacionada