Мой первоначальный вопрос был здесь: Пользователи PAT не могут получить доступ к веб-сайту, а пользователи NAT могут?
Теперь я получил статический IP-адрес и просто предположил, что он работает, потому что я не получил ответа после его включения, но вчера мне сказали, что клиент все еще не обращается к веб-сайту. Клиент не может изменить свои сетевые настройки из-за корпоративной политики, поэтому мне интересно, могу ли я что-нибудь сделать со своей стороны.
Теперь по NAT все подключается нормально. Их ИТ-специалист сказал мне, что он дважды подключается к нашему статическому IP-адресу, а затем наш веб-сайт пытается подключиться обратно через случайный порт. Затем он подключается к двум другим IP-адресам, принадлежащим Google (для веб-рейтинга), и затем сайт загружается.
При использовании PAT они дважды подключаются к нашему статическому IP-адресу, но ничего не происходит. Когда наш веб-сайт снова подключается, их брандмауэр отключает его.
Я понятия не имею, нормально ли иметь сайт, пытающийся подключиться обратно. На самом деле, я даже не знаю, что происходит. Я не любитель нетворкинга. Я отвечаю только за сайт.
На вашем месте, после согласования идеи с обеими сторонами, я бы организовал конференц-связь с участием вас, ИТ-специалиста клиента и сотрудников службы технической поддержки вашего хостинг-провайдера. Я бы посоветовал двум другим обсудить детали и ожидать, что они совместно придут к решению или определят конкретные шаги для определения причины.
Хорошо, если вы не можете заставить клиента поговорить со службой хостинга, вам необходимо получить четкое представление о технических деталях проблемы.
NAT - это преобразование сетевых адресов, это очень распространенный способ решения проблемы нехватки адресов IPV4. До появления NAT каждый компьютер в каждой организации, подключенной к Интернету, должен был иметь глобально уникальный IP-адрес. NAT выполняется в маршрутизаторе, чтобы скрыть ваши внутренние адреса за другими общедоступными адресами. Таким образом, бизнесу с 10 000 компьютеров может потребоваться только один публичный IP-адрес вместо 10 000. Обычно в настоящее время внутренние адреса выбираются из группы адресов IPV4, зарезервированных для частного использования.
Итак, мой компьютер может иметь внутренний адрес 192.168.1.1, а ваш веб-сервер также может иметь внутренний адрес 192.168.1.1. NAT позволяет этим компьютерам общаться друг с другом. Ваш публичный DNS для www.example.com не дает своего внутреннего адреса 192.168.1.1, он дает публичный IP-адрес вашего маршрутизатора, скажем, 1.2.3.4.
Итак, когда я печатаю http://www.example.com в веб-браузер он отправляет TCP-пакет, который выглядит примерно так
From=192.168.1.1:5432 To=1.2.3.4:80 Payload="GET / HTTP/1.0"
Где 5432 - это порт, выбранный моим компьютером наугад. Мой роутер меняет это на
From=99.88.77.66:6789 To=1.2.3.4:80 Payload="GET / HTTP/1.0"
Где 99.88.77.66 - публичный IPV4-адрес моего маршрутизатора. Это трансляция сетевых адресов (NAT). 6789 - это номер порта, который он выделяет (возможно, он уже использует 5432 для подключения какого-то другого парня), это преобразование адреса порта (PAT). Маршрутизатор записывает этот перевод в память для последующего использования.
Маршрутизатор вашей службы хостинга на 1.2.3.4 получает пакет и смотрит на порт номер 80, чтобы решить, на какой внутренний компьютер передать пакет. Это перенаправление портов. Таким образом, в локальной сети хостинга пакет меняется на
From=99.88.77.66:6789 To=192.168.1.1:80 Payload="GET / HTTP/1.0"
Веб-сервер получает это. Он отвечает на 99.88.77.66:6789. Когда этот ответ попадает на мой маршрутизатор, он использует номер порта в целевом адресе 99.88.77.66:6789 для поиска источника исходного соединения - моего 192.168.1.1:5432. Мой маршрутизатор соответствующим образом изменяет адрес назначения и пересылает пакет в мою локальную сеть.
Я не понимаю, как это может пойти не так. Но вы можете видеть, что номера портов жизненно важны для того, чтобы все это работало.