Чому вашому 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 на публічну.