Почему вашему URL нужен вход на порту 80 или 443, а не 45000

Введите имя хоста в браузере, и схема определяет порт назначения: 80 для http, 443 для https. Ничто в ответе DNS это не отменяет, и ни одно правило перенаправления на вашей машине не может придумать слушателя на границе провайдера. Когда провайдер VPN выдаёт вам высокий публичный порт, например 45000, явный URL работает, а чистый нет. Разрыв находится в точке входа, а не внутри приложения.

Пройдите путь от браузера до процесса один раз, и три варианта публикации перестанут казаться загадочными.

Посмотрите, куда на самом деле уходит запрос

Браузер разрешает имя в адрес, затем подключается к этому адресу на порту схемы по умолчанию, если URL не указывает другой. Граница вашего провайдера решает, что произойдёт с приходящим соединением. Если её таблица перенаправления сопоставляет только 45000 с вашим внутренним адресом, соединению на 80 некуда идти, и оно отклоняется или сбрасывается ещё до того, как ваша машина вообще участвует.

Этот отказ происходит на границе, поэтому журналы вашего приложения не показывают ничего. Отсутствие журналов — доказательство того, где остановился пакет, а не того, что приложение сломано.

Почему локальное правило не может исправить границу

Перенаправление или правило DNAT на хосте приложения действует на пакеты, которые уже пришли. Пакеты, отправленные на порт 80 у провайдера, никогда не приходят, поэтому правило никогда не вычисляется. Это самый часто теряемый час во всей проблеме.

DNS тоже не может нести порт. спецификация HTTP определяет значения схемы по умолчанию, а запись A или AAAA возвращает адрес, тогда как CNAME возвращает другое имя. Браузер всё равно присоединяет порт схемы, поэтому только явный порт в URL меняет назначение.

Вариант первый: сохранить явный порт

Часто правильный ответ — неброский. Опубликуйте полный URL с портом, завершите TLS на входе, который это поддерживает, и убедитесь, что каждая созданная ссылка сохраняет то же происхождение. Для небольшой контролируемой аудитории этого достаточно, и это не стоит ничего, кроме видимого номера порта.

Проверьте перенаправления и область действия cookie, пока вы там, потому что backend, который записывает собственное имя хоста в заголовок Location, сводит всю схему на нет.

Вариант второй: получить настоящий вход на порту по умолчанию

Некоторые провайдеры и хостинговые решения пересылают 80 и 443 на общем или выделенном адресе как документированную услугу. Спросите, что на самом деле включено, вместо того чтобы предполагать, что публичный адрес выхода означает произвольные входящие порты. Выделенный адрес выхода ничего не говорит о входящей пересылке.

Подтвердите владение и доступность письменно, включая то, что происходит со входом, когда туннель переподключается с другим адресом. Вход, который перемещается вместе с туннелем, порождает сбои, похожие на отказы DNS.

Вариант третий: поставить спереди frontend

Обратный прокси на достижимом адресе может слушать на 443 и завершать TLS и открыть отдельное соединение с backend через VPN. Посетители видят имя и порт по умолчанию у frontend, а frontend говорит с высоким портом backend от вашего имени. Это работает потому, что меняет архитектуру, а не борется с точкой входа. Тогда backend вообще не нужен входящий порт в публичном интернете.

Меняется и то, чем вы управляете. Frontend владеет публичным TLS, политикой доступа, журналами и доступностью, и он должен ограничивать выбор backend предполагаемой услугой. Если переход от frontend к backend использует HTTPS, сохраняйте проверку сертификата на этом переходе.

Сохраняйте одно происхождение

Публичное имя хоста, схема и порт frontend образуют происхождение, которым пользуются посетители, поэтому настройте внешний URL приложения, перенаправления и cookie для этого происхождения. Передавайте исходный хост и пересланную схему, если приложение строит абсолютные ссылки. Ответ, который возвращает пользователей к приватному имени или высокому порту, сводит на нет чистый вход, который вы только что построили.

Затем решайте, имея в виду аудиторию. Короткий URL может оправдать управляемый frontend, и не стоит случайно превращать приватный сервис только для VPN в публичный.