Я запускаю ubuntu, и у меня запущен apache, однако я не могу пинговать свой статический IP-адрес или просматривать http://207.40.XXX.XX веб-сервер, использующий мой статический IP. Я могу только пинговать / просматривать localhost, 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
Есть идеи, почему это не работает?
Ваш NAT-шлюз не позволяет это делать. Вот как это, вероятно, работает:
пинг
HTTP
Обратите внимание: возможно, причина сбоя ping связана с той же причиной сбоя HTTP. Это называется «NAT Hairpinning».
Вам нужен шлюз NAT, достаточно умный, чтобы на шаге 6 он также перезаписывал источник адрес.
Хотя ответ 1138 правильный, я просто хотел подробно рассказать о том, что такое «шпилька NAT», как она работает и почему она необходима в данном случае. Если вас не интересуют мельчайшие подробности IP, NAT и маршрутизации, не стесняйтесь игнорировать остальную часть моего (довольно длинного) ответа.
Вот что происходит во время попытки HTTP-подключения от клиента локальной сети (192.168.0.5) к веб-серверу через внешний IP-адрес (207.40.123.45), без зацикливания:
192.168.0.5 отправляет свой SYN-пакет на 207.40.123.45, порт 80. Поскольку 207.40.123.45 не находится в локальной сети, этот пакет отправляется на шлюз по умолчанию (т. Е. На маршрутизатор).
Маршрутизатор, настроенный для пересылки 207.40.123.45:80 на 192.168.0.120:80, перезаписывает адрес назначения пакета на 192.168.0.120, а затем доставляет пакет на веб-сервер.
Веб-сервер получает SYN-пакет и отправляет ответный SYN-ACK-пакет обратно на адрес отправителя, который 192.168.0.5. Поскольку 192.168.0.5 находится в той же сети, веб-сервер доставляет пакет напрямую на 192.168.0.5.
Пакет 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 в дополнение к одной фазе, обычно применяемой для перенаправления портов. Вот снова последовательность, на этот раз с добавленным NAT с закреплением волос:
Как и раньше, 192.168.0.5 отправляет свой SYN-пакет, предназначенный для 207.40.123.45, порт 80, на маршрутизатор.
Как и раньше, маршрутизатор получает SYN-пакет и в соответствии с настроенным правилом переадресации портов перезаписывает адрес назначения на 192.168.0.120. На этот раз, однако, маршрутизатор замечает, что он собирается «закрепить» пакет обратно в той же сети, из которой он был получен, поэтому он также перезаписывает пакет. адрес источника на собственный LAN-адрес маршрутизатора (скажем: 192.168.0.1). Затем маршрутизатор доставляет пакет на веб-сервер по адресу 192.168.0.120.
Веб-сервер получает SYN-пакет и отправляет свой ответный SYN-ACK-пакет обратно на адрес отправителя, который на этот раз является 192.168.0.1. Таким образом, ответ возвращается маршрутизатору.
Маршрутизатор получает SYN-ACK от веб-сервера и распознает, что это ответ на пакет, который он недавно обработал NAT (дважды). Таким образом, маршрутизатор послушно меняет оба NAT, и ответный пакет теперь имеет адрес источника 207.40.123.45 и адрес назначения 192.168.0.5. Следовательно, ответ доставляется на адрес 192.168.0.5, подтверждение соединения TCP продолжается, и клиент и веб-сервер могут успешно взаимодействовать.
Таким образом, с поддержкой закрепления в маршрутизаторе хост 192.168.0.5 думает, что он обращается к веб-серверу по адресу 207.40.123.45, а веб-сервер по адресу 192.168.0.120 думает, что он разговаривает с клиентом на самом маршрутизаторе (192.168.0.1). При закреплении весь трафик между двумя хостами проходит через маршрутизатор, даже если оба хоста фактически находятся в одной сети. Очевидно, что это неоптимальное использование сетевых ресурсов, и это основная причина, по которой установка разделенного DNS обычно предпочтительнее, чем полагаться на закрепление.
Какой брандмауэр вы используете? Похоже, что NAT не включен.