Защо вашият 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 на вход, който го поддържа, и се уверете, че всяка генерирана връзка запазва същия произход. За малка, контролирана аудитория това е пълно и не струва нищо извън видим номер на порт.

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

Опция втора: получете истински вход на порт по подразбиране

Някои доставчици и хостинг решения препращат 80 и 443 на споделен или отделен адрес като документирана услуга. Попитайте какво всъщност е включено, вместо да приемате, че публичен адрес за изход предполага произволни входящи портове. Отделен адрес за изход не казва нищо за входящото препращане.

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

Опция трета: поставете фронтенд отпред

Обратен прокси на достъпен адрес може да слуша на 443 и прекратява TLS и да отвори отделна връзка към бекенда през VPN. Посетителите виждат името и порта по подразбиране на фронтенда, докато фронтендът говори с високия порт на бекенда от ваше име. Това работи, защото променя архитектурата, вместо да се бори с входа. Тогава бекендът не се нуждае от входящ порт в публичния интернет.

Променя се и какво управлявате. Фронтендът притежава публичния TLS, политиката за достъп, журналите и наличността и трябва да ограничава избора на бекенд до предвидената услуга. Ако преходът фронтенд-към-бекенд използва HTTPS, запазете проверката на сертификата на този преход.

Запазете един произход

Публичното име на хост, схемата и портът на фронтенда образуват произхода, който посетителите използват, затова конфигурирайте външния URL на приложението, пренасочванията и бисквитките за този произход. Изпращайте оригиналния хост и препратената схема, ако приложението изгражда абсолютни връзки. Отговор, който връща потребителите към частно име или висок порт, отменя чистия вход, който току-що изградихте.

След това решете с оглед на аудиторията. Краткият URL може да оправдае управляван фронтенд и не си струва случайно да превърнете частна услуга само за VPN в публична.