Я размещаю некоторые сайты/сервисы, такие как Jenkins, на сервере, который у меня дома. Я хотел бы, чтобы они были доступны из Интернета, а также из интрасети через публичное доменное имя. Для этого я зарегистрировал доменное имя noip, указывающее на мой (динамический) публичный ipv4. На маршрутизаторе настроены переадресации портов для NAT-трансляции порта на мой сервер.
Все работало нормально, пока на прошлых выходных я не сменил провайдера, а вместе с ним и маршрутизатор.
Теперь я не могу подключиться к своим сайтам из интрасети, используя публичное доменное имя, которое преобразуется в мой публичный IP-адрес.
Что я протестировал:
- Пингование имени публичного домена из интрасети разрешает правильный публичный IP-адрес -> нет проблем с DNS
- Сайты доступны из Интернета при использовании публичного доменного имени (или IP) и правильного порта.
- Сайты НЕ доступны из интрасети при использовании публичного доменного имени (или IP) и правильного порта. В этом случае браузер показывает ошибку тайм-аута сетевого подключения (ERR_CONNECTION_TIMED_OUT)
- Сайты доступны из интрасети при использовании внутреннего IP-адреса и правильного порта (как указано в правиле переадресации портов для назначения)
Какую сетевую конфигурацию маршрутизатора необходимо изменить, чтобы он правильно маршрутизировал данные из интрасети?
Руководство по эксплуатации маршрутизатора:https://www.sunrise.ch/content/dam/sunrise/residential/hilfe/internet/Sunrise_Home_User_Manual_Sunrise_Internet_Box_new_firmware_e.pdf
Конфигурация маршрутизатора:
В настоящее время брандмауэр отключен, чтобы убедиться, что он не вызывает проблем:
Это дубликат моего поста здесь:https://networkengineering.stackexchange.com/posts/59290
решение1
Это в основном ответ на основе догадок, основанный на наиболее распространенной проблеме этого типа. Однако, чтобы быть полностью уверенным, вам нужно будет фактически исследовать то, что видит сервер (Wireshark/tcpdump — хорошие инструменты).
DNAT (переадресация портов) в пределах одной подсети весьма проблематична, поскольку обратный путь от сервера к клиенту обычно обходит маршрутизатор, и нет возможности отменить NAT для этого обратного трафика.
Чтобы обойти это, некоторые (но не все) маршрутизаторы имеют опцию "NAT loopback" или "NAT hairpin". Насколько я понимаю, эта опция дополнительно выполняет SNAT для всех подключений, перезаписываяклиентIP-адрес и заставить сервер думать, что все соединения исходят от самого маршрутизатора.
Без loopback/hairpin ваши клиенты могут подключаться к серверу, но не распознают ответы, пришедшие с сервера (поскольку IP-адрес больше не совпадает), поэтому соединение никогда не будет установлено.
Если на вашем маршрутизаторе нет этой опции, но есть ручная расширенная настройка NAT, вы можете создать аналогичное правило NAT самостоятельно — указать маршрутизатору «маскировать» все соединения, входящие из локальной сети и возвращающиеся в ту же локальную сеть.
(Разумеется, это по-прежнему имеет тот же недостаток, заключающийся в сокрытии IP-адресов клиентов от сервера.)
Однако, IMHO, лучший вариант (лично не проверенный, но у меня нет причин полагать, что он не сработает) — это разместить сервер надругая подсетьот остальных ваших устройств. Пока обратный трафик сервера к клиентам проходит через шлюз, проблемы следует избегать — даже если нет разделения VLAN и обе подсети находятся в одном и том же ethernet.
Вышеуказанное также можно реализовать путем изменения маски подсети или добавления пользовательских маршрутов на сервер.