Чаму вашаму URL патрэбны ўваход на порце 80 або 443, а не 45000
Браўзер выбірае 80 або 443 з схемы, а не высокі порт вашага правайдэра. Прайдзіце шлях уваходу і паходжанне, якое пакідае кожны варыянт публікацыі.
Увядзіце імя хоста ў браўзер, і схема вызначыць порт прызначэння: 80 для http, 443 для https. Нішто ў адказе DNS гэтага не адмяняе, і ніякае правіла перанакіравання на вашай машыне не можа стварыць слухача на ўскрайку правайдэра. Калі правайдэр VPN дае вам высокі публічны порт, напрыклад 45000, URL з пазначаным портам працуе, а чысты не. Разрыў знаходзіцца ў пункце ўваходу, а не ўсярэдзіне праграмы.
Прайдзіце шлях ад браўзера да працэсу адзін раз, і тры варыянты публікацыі перастануць выглядаць загадкава.
Паглядзіце, куды насамрэч ідзе запыт
Браўзер развязае імя ў адрас, затым злучаецца з гэтым адрасам на порце схемы па змаўчанні, калі URL не паказвае іншы. Ускраек правайдэра вырашае, што адбудзецца з прыбылым злучэннем. Калі яго табліца перанакіравання супастаўляе толькі 45000 з вашым унутраным адрасам, злучэнню на 80 няма куды ісці, і яно адхіляецца або скідваецца яшчэ да ўдзелу вашай машыны.
Гэтая адмова адбываецца на ўскрайку, таму журналы вашай праграмы не паказваюць нічога. Адсутнасць журналаў — гэта доказ таго, дзе спыніўся пакет, а не доказ таго, што праграма зламаная.
Чаму лакальнае правіла не можа выправіць ускраек
Правіла перанакіравання або DNAT на хасце праграмы ўздзейнічае на пакеты, якія ўжо прыйшлі. Пакеты, адпраўленыя на порт 80 у правайдэра, ніколі не прыбываюць, таму правіла ніколі не ацэньваецца. Гэта самая частая страчаная гадзіна ў гэтай праблеме.
DNS таксама не можа несці порт. Спецыфікацыя HTTP вызначае значэнні схемы па змаўчанні, а запіс A або AAAA вяртае адрас, у той час як CNAME вяртае іншае імя. Браўзер па-ранейшаму далучае порт схемы, таму прызначэнне змяняе толькі яўны порт у URL.
Варыянт першы: пакінуць яўны порт
Часта правільны адказ — няўзнёслы. Апублікуйце поўны URL з портам, завяршыце TLS на ўваходзе, які гэта падтрымлівае, і пераканайцеся, што кожная згенераваная спасылка захоўвае тое ж паходжанне. Для невялікай кантраляванай аўдыторыі гэта поўна, і гэта не каштуе нічога, акрамя бачнага нумара порта.
Праверце перанакіраванні і абсяг кукі, пакуль вы там, бо бэкэнд, які запісвае сваё імя хоста ў загаловак Location, адмяняе гэтую дамоўленасць.
Варыянт другі: атрымаць сапраўдны ўваход на порце па змаўчанні
Некаторыя правайдэры і хастынгавыя рашэнні перанакіроўваюць 80 і 443 на агульным або выдзеленым адрасе як дакументаваную паслугу. Спытайцеся, што насамрэч уключана, замест таго каб меркаваць, што публічны адрас выхаду прадугледжвае адвольныя ўваходныя парты. Выдзелены адрас выхаду нічога не кажа пра ўваходнае перанакіраванне.
Пацвердзіце ўласнасць і даступнасць у пісьмовай форме, уключаючы тое, што адбудзецца з уваходам, калі тунель перападключыцца з іншым адрасам. Уваход, які рухаецца разам з тунелем, стварае перапынкі, якія выглядаюць як збоі DNS.
Варыянт трэці: паставіць фронтэнд наперадзе
Зваротны проксі на дасяжным адрасе можа слухаць на 443 і завяршаць TLS і адкрыць асобнае злучэнне з бэкэндам праз VPN. Наведвальнікі бачаць імя і порт фронтэнда па змаўчанні, а фронтэнд размаўляе з высокім портам бэкэнда ад вашага імя. Гэта працуе, бо змяняе архітэктуру, а не змагаецца з пунктам уваходу. Бэкэнду тады ўвогуле не патрэбны ўваходны порт у публічным інтэрнэце.
Гэта таксама змяняе тое, чым вы кіруеце. Фронтэнд валодае публічным TLS, палітыкай доступу, журналамі і даступнасцю, і ён павінен абмяжоўваць выбар бэкэнда патрэбнай паслугай. Калі пераход ад фронтэнда да бэкэнда выкарыстоўвае HTTPS, пакіньце праверку сертыфіката на гэтым пераходзе.
Захавайце адно паходжанне
Публічнае імя хоста фронтэнда, схема і порт утвараюць паходжанне, якое выкарыстоўваюць наведвальнікі, таму наладзьце знешні URL праграмы, перанакіраванні і кукі для гэтага паходжання. Дасылайце арыгінальны хост і перасланую схему, калі праграма будуе абсалютныя спасылкі. Адказ, які вяртае карыстальнікаў на прыватнае імя або высокі порт, адмяняе чысты ўваход, які вы толькі што пабудавалі.
Затым вырашайце з улікам аўдыторыі. Кароткі URL можа апраўдаць кіраваны фронтэнд, і не варта выпадкова ператвараць прыватную службу толькі для VPN у публічную.