Выделенный IP-адрес VPN не публикует ваш сайт
Выделенный адрес выхода ничего не говорит о входящей доставке. Проверьте договор переадресации, завершите сторону источника и лишь затем публикуйте высокий порт.
Покупка выделенного IP у провайдера VPN похожа на покупку входной двери. Адрес стабилен, туннель поднят, а сайт всё равно не открывается никому снаружи. То, что вы купили, — это назначение адреса, а не правило входящей переадресации. И то и другое продаётся в одном магазине и настраивается в совершенно разных местах.
Адрес — это назначение, а не правило переадресации
Запишите входящий публичный адрес или имя хоста, разрешённый транспорт, назначенный внешний порт и клиентское место назначения, куда доставляет провайдер. Затем убедитесь, что выбранные вами сервер, протокол и функция учётной записи действительно поддерживают переадресацию и что провайдер разрешает на нём хостинг.
Слово «выделенный» описывает назначение адреса. Оно не означает, что незапрошенный входящий трафик разрешён, и разные дополнения одного оператора могут иметь разные возможности. Выделенный адрес и продукт «выделенный сервер» — две чаще всего путаемых метки, и страницы поддержки обычно уточняют, какая из них переадресует.
| What you have | What it gives you | What it does not |
|---|---|---|
| Dedicated exit address | A stable source address for outbound traffic | Any inbound delivery at all |
| Port-forwarding add-on | A provider-side mapping to your session | Permanence across reconnects |
| Local DNAT rule | Handling for packets that arrive | Making packets arrive |
Пример договора выглядит так: провайдер доставляет TCP 203.0.113.60:45000 на HTTPS-службу вашего подключённого устройства через порт 8443. Это описание сопоставления, настроенного кем-то другим, а не правило, которое вы можете создать на их краю, вписав его в собственный межсетевой экран.
Завершите сторону источника
Если веб-приложение работает на самом клиенте VPN, ему нужен слушатель на доставленном порту и ограниченное разрешение на локальный ввод для этого порта. Если клиент переадресует сопоставленное соединение на другой хост, ему нужны трансляция адресата, политика переадресации и путь ответа, который выдерживает дорогу туда и обратно.
Стройте правила доступа вокруг адреса источника, который путь провайдера действительно предъявляет. Это не всегда исходный посетитель и не всегда сервер VPN, что важно, когда вы пишете правило, которому соответствовал бы только один из этих адресов.
Трансляция портов тоже не превращает HTTP в HTTPS. Публичный порт и локальный порт приложения могут свободно различаться, но схема, идентичность сертификата и перенаправления по-прежнему должны соответствовать службе, до которой люди реально дотягиваются. Если сертификат называет публичный хост, сохраняйте это имя на каждом шаге. Несоответствие здесь проявляется как предупреждение браузера, а не как сбой маршрутизации, что на час отправляет людей к неверным журналам.
Публикуйте высокий порт честно
Если посетители подключаются напрямую и провайдер назначил высокий порт, дайте им полный URL. Обычная запись адреса DNS не может добавить порт к запросу HTTPS, который по умолчанию использует 443, и никакая правка TTL этого не изменит.
Веб-фронтенд может решить это, принимая посетителей на обычном порту и устанавливая собственное соединение с переадресованным портом источника. Однако прокси-порты Cloudflare по умолчанию — это определённый список, и произвольно назначенный порт не становится поддерживаемым портом на периферии только потому, что вы добавили проксированную запись DNS.
Изменение порта назначения источника — это другая операция, чем изменение порта посетителя. Origin Rules Cloudflare документируют переопределение порта назначения для соединения с бэкендом, ограниченное поддерживаемым правилом, схемой и именем хоста. Переопределение порта не является универсальным ретранслятором для произвольного UDP или других протоколов.
Когда фронтенд завершает TLS, проверяйте оба шага: сертификат от браузера к фронтенду и соединение от фронтенда к источнику. Шаг VPN не заменяет ни одной из двух проверок, а утечка внутреннего адреса в перенаправления или файлы cookie — обычный признак того, что только один из двух настраивался с оглядкой на публичное имя.
Поддерживайте сопоставление живым
Некоторые провайдеры выделяют другой порт после переподключения, а арендованное сопоставление может требовать продления действием на стороне провайдера. Следите за механизмом, который документирует ваш провайдер, и обновляйте слушатель, локальные правила, DNS или правило фронтенда только там, где этого требует текущий договор.
Статический публичный адрес не делает аренду порта статической. Адрес и порт, всё ещё показанные на панели, не доказывают, что живая сессия владеет сопоставлением, поэтому проверкой служит свежий запрос снаружи, а не снимок экрана.
Затем повторите случаи, которых ждёте: обычное переподключение и потеря VPN. Если потеря должна сделать источник недоступным, не позволяйте программе обновления тихо опубликовать заново прямой путь ISP в фоне. И если договор переадресации не может выполнить требования сайта к стабильности, выберите другую схему публикации, вместо того чтобы покупать ещё одну метку адреса и надеяться, что она поведёт себя как сервер.