PAT не может получить доступ к веб-сайту, но NAT может
Мой оригинальный вопрос был здесь: пользователи PAT не могут получить доступ к веб-сайту, но пользователи NAT могут?
Я получил статический IP-адрес и предположил, что он работает, потому что я не получил ответа после его включения, но вчера мне сказали, что клиент все еще не обращается к веб-сайту. Клиент не может изменить свои настройки сети из-за корпоративной политики, поэтому мне интересно, могу ли я что-то сделать на моей стороне.
Теперь с помощью NAT все подключается нормально. Их айтишник сказал мне, что он дважды подключается к нашему статическому IP-адресу, а затем наш веб-сайт пытается подключиться через случайный порт. Затем он подключается к двум другим IP-адресам, принадлежащим Google (для веб-рейтинга), и затем веб-сайт загружается.
При использовании PAT они дважды подключаются к нашему статическому IP-адресу, но ничего не происходит. Когда наш сайт подключается обратно, их брандмауэр удаляет его.
Я понятия не имею, нормально ли иметь сайт, пытающийся подключиться обратно или нет. На самом деле, я даже не знаю, что происходит вообще. Я не сетевой парень. Я просто отвечаю за сайт.
1 ответ
На вашей позиции, после согласования этой идеи с обеими сторонами, я бы назначил телефонную конференцию с участием вас, ИТ-специалиста клиента и персонала технической поддержки вашего хостинг-провайдера. Я бы посоветовал двум другим обсудить детали и ожидать, что они совместно примут решение или определят конкретные шаги для выявления причины.
Хорошо, если вы не можете заставить клиента общаться с хостингом, вам необходимо получить четкое представление о технических деталях проблемы.
NAT - это преобразование сетевых адресов, это очень распространенный способ справиться с нехваткой адресов IPV4. До NAT каждый компьютер в каждой организации, подключенной к Интернету, должен был иметь глобально уникальный IP-адрес. NAT выполняется в маршрутизаторе, чтобы скрыть ваши внутренние адреса за другими публичными адресами. Таким образом, бизнесу с 10000 компьютеров может понадобиться только один публичный IP-адрес вместо 10000. Обычно в настоящее время внутренние адреса выбираются из группы адресов 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. Мой маршрутизатор соответственно изменяет адрес назначения и пересылает пакет в мою локальную сеть.
Я не могу понять, как это может пойти не так. Но вы можете видеть, что номера портов жизненно важны для того, чтобы все это работало.