Зашто вашем 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 на улазу који то подржава и побрините се да свака генерисана веза задржи исто порекло. За малу, контролисану публику то је потпуно и не кошта ништа осим видљивог броја порте.

Проверите преусмеравања и обухват колачића док сте тамо, јер backend који уписује своје име хоста у Location заглавље поништава договор.

Опција друга: добијте прави улаз на подразумеваној порти

Неки провајдери и хостинг решења прослеђују 80 и 443 на дељеној или наменској адреси као документовану услугу. Питајте шта је заправо укључено уместо да претпостављате да јавна излазна адреса подразумева произвољне улазне порте. Наменска излазна адреса не говори ништа о улазном прослеђивању.

Потврдите власништво и доступност у писаној форми, укључујући шта се дешава са улазом када се тунел поново повеже са другом адресом. Улаз који се креће са тунелом ствара прекиде који изгледају као DNS кварови.

Опција трећа: ставите frontend испред

Обрнути прокси на доступној адреси може да слуша на 443 и завршава TLS и отвори засебну везу са backend-ом преко VPN-а. Посетиоци виде име и подразумевану порту frontend-а, док frontend разговара са високом портом backend-а у ваше име. То функционише јер мења архитектуру уместо да се бори са улазном тачком. Backend тада уопште не треба улазну порту на јавном интернету.

То мења и оно чиме управљате. Frontend поседује јавни TLS, политику приступа, записе и доступност и мора да ограничи избор backend-а на предвиђену услугу. Ако скок од frontend-а до backend-а користи HTTPS, задржите проверу сертификата на том скоку.

Задржите једно порекло

Јавно име хоста, шема и порта frontend-а чине порекло које посетиоци користе, зато конфигуришите спољни URL апликације, преусмеравања и колачиће за то порекло. Пошаљите оригинални хост и прослеђену шему ако апликација гради апсолутне везе. Одговор који враћа кориснике на приватно име или високу порту поништава чист улаз који сте управо направили.

Затим одлучите имајућу публику на уму. Кратак URL може да оправда управљани frontend и није вредно случајно претворити приватну услугу само за VPN у јавну.