☰

Невозможно пропинговать статический IP из внутренней сети, только извне

tag-icon • tag-icon networking ping localhost
Невозможно пропинговать статический IP из внутренней сети, только извне

Я использую Ubuntu и Apache, однако я не могу выполнить внутренний ping на свой статический IP-адрес и просматривать http://207.40.XXX.XXвеб-сервер, используя свой статический IP-адрес. Я могу только выполнить ping/browselocalhost, 127.0.0.1, and 192.168.0.120 ИЛИ 207.40.XXX.XXтолько из внешнего мира.

# 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

Есть идеи, почему это не работает?

решение1

Ваш NAT-шлюз не ведет себя так, чтобы это разрешалось. Вот как это, вероятно, работает:

пинг

  1. Вы отправляете ICMP Echo-запрос с 192.168.0.5 на 207.40.123.45
  2. Маршрутизация осуществляется через ваш маршрутизатор.
  3. Ваш шлюз NAT внутри маршрутизатора перезаписывает запрос так, чтобы он был от 207.40.123.45 (это статический IP-адрес)
  4. Ваш маршрутизатор отвечает на запрос ICMP Echo
  5. Поскольку ваш маршрутизатор не поддерживает состояние ICMP, он никогда не передает вам ответ ECHO.

HTTP

  1. Вы отправляете запрос на соединение TCP/80 с 192.168.0.5 на 207.40.123.45
  2. Это маршрутизируется через ваш маршрутизатор
  3. Ваш шлюз NAT перезаписывает пакет как приходящийот207.40.123.45:41345 по 207.40.123.45:80
  4. Ваш шлюз NAT обнаруживает наличие переадресации порта, поэтому пересылает пакет на 192.168.0.120:80
  5. Сервер 192.168.0.120 отвечает на попытку подключения с 207.40.123.45:41345
  6. Ваш шлюз NAT видит ответ и перезаписывает адрес «Кому» в ответе на 192.168.0.5:36311, но оставляет адрес «От» нетронутым (192.168.0.120:80).
  7. Ваш компьютер по адресу 192.168.0.5 получает пакет с адреса 192.168.0.120, который он никогда не запрашивал, и сбрасывает его.
  8. «Ваша связь ослабевает и больше не открывается».

Обратите внимание, что возможно, что причина сбоя ping та же, что и у HTTP. Это называется «NAT Hairpinning».

Вам нужен шлюз NAT, достаточно умный, чтобы на шаге 6 он также перезаписывалисточникадрес.

решение2

Хотя ответ 1138 правильный, я просто хотел вставить подробное объяснение того, что такое "шпилька NAT", как она работает и почему она необходима в этих обстоятельствах. Если вас не интересуют мельчайшие подробности IP, NAT и маршрутизации, пожалуйста, проигнорируйте остальную часть моего (довольно длинного) ответа.

Вот что происходит без привязки при попытке HTTP-подключения от локального клиента LAN (192.168.0.5) к веб-серверу через внешний IP-адрес (207.40.123.45):

  1. 192.168.0.5 отправляет свой SYN-пакет на 207.40.123.45, порт 80. Поскольку 207.40.123.45 не находится в локальной сети, этот пакет отправляется на шлюз по умолчанию (т. е. маршрутизатор).

  2. Маршрутизатор, настроенный на пересылку 207.40.123.45:80 на 192.168.0.120:80, перезаписывает адрес назначения пакета на 192.168.0.120, а затем доставляет пакет на веб-сервер.

  3. Веб-сервер получает пакет SYN и отправляет ответный пакет SYN-ACK обратно на адрес отправителя, который192.168.0.5Поскольку 192.168.0.5 находится в той же сети, веб-сервер доставляет пакет напрямую на 192.168.0.5.

  4. Пакет SYN-ACK от192.168.0.120приходит на 192.168.0.5, но хост там не ожидал SYN-ACK от 192.168.0.120, и поэтому он отбрасывается/отклоняется. Хост на 192.168.0.5 продолжает ждать ответного SYN-ACK от 207.40.123.45, но, конечно, этот пакет никогда не придет. Попытка подключения в конечном итоге истечет, возможно, после нескольких повторных попыток, и в конечном итоге клиент и веб-сервер не смогут установить соединение.

Эту проблему можно решить с помощью маршрутизатора на шаге 2, применив "шпильку NAT". Короче говоря, решение заключается в том, чтобы обмануть клиента и веб-сервер, чтобы они отправляли свой взаимный трафик через маршрутизатор. Это ловко достигается применениемвторая фаза NATна шаге 2, в дополнение к одной фазе, обычно применяемой для переадресации портов. Вот последовательность снова, на этот раз с добавленным hairpinning NAT:

  1. Как и прежде, 192.168.0.5 отправляет свой SYN-пакет, предназначенный для 207.40.123.45, порт 80, на маршрутизатор.

  2. Как и прежде, маршрутизатор получает пакет SYN и, согласно настроенному правилу переадресации портов, переписывает адрес назначения на 192.168.0.120. Однако на этот раз маршрутизатор замечает, что он собирается «прикрепить» пакет обратно в ту же сеть, из которой он был получен, поэтому он также переписывает адрес пакетаадрес источникана собственный адрес локальной сети маршрутизатора (например: 192.168.0.1). Затем маршрутизатор доставляет пакет на веб-сервер по адресу 192.168.0.120.

  3. Веб-сервер получает пакет SYN и отправляет ответный пакет SYN-ACK обратно на адрес отправителя, который на этот раз является192.168.0.1. Таким образом, ответ возвращается маршрутизатору.

  4. Маршрутизатор получает SYN-ACK от веб-сервера и распознает, что это ответ на пакет, который он недавно NAT-ed (дважды). Поэтому маршрутизатор добросовестно меняет оба NAT, и ответный пакет теперь имеет исходный адрес 207.40.123.45 и адрес назначения 192.168.0.5. Следовательно, ответ доставляется на 192.168.0.5, рукопожатие TCP-соединения продолжается, и клиент и веб-сервер могут успешно общаться.

Таким образом, при поддержке hairpinning в маршрутизаторе хост 192.168.0.5 думает, что общается с веб-сервером 207.40.123.45, в то время как веб-сервер 192.168.0.120 думает, что общается с клиентом на самом маршрутизаторе (192.168.0.1). При hairpinning весь трафик между двумя хостами проходит через маршрутизатор, хотя оба хоста фактически находятся в одной сети. Очевидно, что это неоптимальное использование сетевых ресурсов, и это главная причина, по которой настройка разделенного DNS обычно предпочтительнее, чем полагаться на hairpinning.

решение3

Какой тип брандмауэра вы используете? Похоже, что NAT hairpinning не включен.

Связанный контент