Неге URL-ге 45000 емес, 80 немесе 443 портынан кіру керек

Браузерге хост атауын теріңіз, схема межелі портты анықтайды: http үшін 80, https үшін 443. DNS жауабындағы ештеңе мұны жоққа шығармайды және машинаңыздағы ешбір қайта бағыттау ережесі провайдердің шетінде тыңдаушы ойлап таба алмайды. VPN провайдері сізге 45000 сияқты жоғары жария порт бергенде, айқын URL жұмыс істейді, тазасы істемейді. Алшақтық кіру нүктесінде, қолданбаның ішінде емес.

Браузерден процеске дейінгі жолды бір рет қарап шығыңыз, сонда үш жариялау нұсқасы жұмбақ болып көрінбейді.

Сұрау шын мәнінде қайда баратынын қараңыз

Браузер атауды мекенжайға шешеді, содан кейін URL басқа портты атамаса, схеманың әдепкі портымен сол мекенжайға қосылады. Келе жатқан қосылымға не болатынын провайдеріңіздің шеті шешеді. Егер оның қайта бағыттау кестесі тек 45000-ді сіздің ішкі мекенжайыңызға сәйкестендірсе, 80-ге қосылымның барар жері жоқ және машинаңыз қатыспай тұрып қабылданбайды немесе тасталады.

Бұл бас тарту шетте болады, сондықтан қолданба журналдары ештеңе көрсетпейді. Журналдардың болмауы пакеттің қайда тоқтағанының дәлелі, қолданбаның бұзылғанының дәлелі емес.

Неге жергілікті ереже шетті түзете алмайды

Қолданба хостындағы қайта бағыттау немесе DNAT ережесі әлдеқашан келген пакеттерге әсер етеді. Провайдерде 80 портына жіберілген пакеттер ешқашан келмейді, сондықтан ереже ешқашан бағаланбайды. Бұл бүкіл мәселедегі ең жиі жоғалтылатын сағат.

DNS те портты тасымалдай алмайды. HTTP ерекшелігі схеманың әдепкі мәндерін анықтайды, ал A немесе AAAA жазбасы мекенжай қайтарады, CNAME басқа атау қайтарады. Браузер әлі де схема портын қосады, сондықтан межені URL-дегі айқын порт қана өзгертеді.

Бірінші нұсқа: айқын портты сақтау

Көбіне дұрыс жауап көзге түспейтін нұсқа. Портпен толық URL жариялаңыз, TLS-ті оны қолдайтын кіруде аяқтаңыз және әр жасалған сілтеме бірдей шығу тегін сақтайтынына көз жеткізіңіз. Шағын, бақыланатын аудитория үшін бұл толық және көрінетін порт нөмірінен басқа ештеңе тұрмайды.

Сонда жүргенде қайта бағыттаулар мен cookie ауқымын тексеріңіз, өйткені өз хост атауын Location тақырыбына жазатын backend бұл реттеуді жояды.

Екінші нұсқа: әдепкі портта нақты кіру алу

Кейбір провайдерлер мен хостинг шешімдері 80 мен 443-ті құжатталған қызмет ретінде ортақ немесе арнайы мекенжайға бағыттайды. Жария шығу мекенжайы кез келген кіріс порттарын білдіреді деп болжаудың орнына, шын мәнінде не кіретінін сұраңыз. Арнайы шығу мекенжайы кіріс бағыттау туралы ештеңе айтпайды.

Иелік пен қолжетімділікті жазбаша растаңыз, соның ішінде туннель басқа мекенжаймен қайта қосылғанда кіруге не болатынын. Туннельмен бірге жылжитын кіру DNS ақауларына ұқсайтын үзілістер тудырады.

Үшінші нұсқа: алдына frontend қою

Қолжетімді мекенжайдағы кері прокси 443-те тыңдау және TLS-ті аяқтау және VPN арқылы backend-ке бөлек қосылым аша алады. Келушілер frontend атауы мен әдепкі портын көреді, ал frontend сіздің атыңыздан backend-тің жоғары портымен сөйлеседі. Бұл сәулетті өзгертетіндіктен жұмыс істейді, кіру нүктесімен алыспайды. Сонда backend-ке жария интернетте кіріс порты мүлде қажет емес.

Бұл сіз басқаратын нәрсені де өзгертеді. frontend-ке жария TLS, кіру саясаты, журналдар мен қолжетімділік тиесілі және ол backend таңдауын көзделген қызметпен шектеуі керек. frontend-тен backend-ке секіру HTTPS қолданса, сол секіруде сертификат тексеруін сақтаңыз.

Бір шығу тегін сақтаңыз

frontend-тің жария хост атауы, схемасы мен порты келушілер қолданатын шығу тегін құрайды, сондықтан қолданбаның сыртқы URL-ін, қайта бағыттауларын және cookie-лерін сол шығу тегіне конфигурациялаңыз. Қолданба абсолютті сілтемелер құрса, бастапқы хостты және жіберілген схеманы жіберіңіз. Пайдаланушыларды жеке атауға немесе жоғары портқа қайтаратын жауап жаңа ғана салған таза кіруіңізді жояды.

Содан кейін аудиторияны ойлап шешім қабылдаңыз. Қысқа URL басқарылатын frontend-ті ақтауы мүмкін және тек VPN үшін жасалған жеке қызметті абайсызда жария қызметке айналдыруға тұрмайды.