ඔබේ URL ට 45000 නොව, 80 හෝ 443 වරායේ පිවිසුමක් අවශ්‍ය වන්නේ ඇයි

බ්‍රව්සරයක hostname එකක් ටයිප් කරන්න, යෝජනා ක්‍රමය ගමනාන්ත වරාය තීරණය කරයි: http සඳහා 80, https සඳහා 443. DNS පිළිතුරේ කිසිවක් එය අවලංගු නොකරයි, සහ ඔබේ යන්ත්‍රයේ කිසිදු යොමු කිරීමේ නියමයකට සැපයුම්කරුගේ දාරයේ ශ්‍රවණයකරුවෙකු නිර්මාණය කළ නොහැක. VPN සැපයුම්කරුවෙකු ඔබට 45000 වැනි ඉහළ පොදු වරායක් දෙන විට, පැහැදිලි URL එකක් ක්‍රියා කරයි, පිරිසිදු එකක් නොකරයි. පරතරය පිවිසුම් ලක්ෂ්‍යයේ ඇත, යෙදුම තුළ නොවේ.

බ්‍රව්සරයේ සිට ක්‍රියාවලිය දක්වා මාර්ගය එක් වරක් බලන්න, ප්‍රකාශන විකල්ප තුන අද්භූත ලෙස නොපෙනෙනු ඇත.

ඉල්ලීම සැබවින්ම යන්නේ කොහේද බලන්න

බ්‍රව්සරය නම ලිපිනයකට විසඳා, URL වෙනත් වරායක් නම් නොකරන්නේ නම් යෝජනා ක්‍රමයේ පෙරනිමි වරායෙන් එම ලිපිනයට සම්බන්ධ වේ. පැමිණෙන සම්බන්ධතාවයට කුමක් සිදුවේද යන්න ඔබේ සැපයුම්කරුගේ දාරය තීරණය කරයි. එහි යොමු කිරීමේ වගුව 45000 පමණක් ඔබේ අභ්‍යන්තර ලිපිනයට සිතියම් කරන්නේ නම්, 80 ට සම්බන්ධතාවයට යාමට තැනක් නැති අතර ඔබේ යන්ත්‍රය සම්බන්ධ වීමට පෙර එය ප්‍රතික්ෂේප හෝ ඉවත දමනු ලැබේ.

එම ප්‍රතික්ෂේපය දාරයේ සිදු වේ, එබැවින් ඔබේ යෙදුමේ ලොග කිසිවක් නොපෙන්වයි. ලොග නොතිබීම පැකට්ටුව නැවතුනේ කොහේද යන්නට සාක්ෂියක් මිස යෙදුම කැඩී ඇති බවට සාක්ෂියක් නොවේ.

දේශීය නියමයකට දාරය අලුත්වැඩියා කළ නොහැක්කේ ඇයි

යෙදුම් සත්කාරකයේ යොමු කිරීමක් හෝ DNAT නියමයක් දැනටමත් පැමිණි පැකට්ටු මත ක්‍රියා කරයි. සැපයුම්කරු ළඟ 80 වරායට යවන පැකට්ටු කිසිවිටෙක පැමිණෙන්නේ නැත, එබැවින් නියමය කිසිවිටෙක ඇගයෙන්නේ නැත. මෙය මුළු ගැටලුවේම වඩාත් පොදු අහිමි වන පැයයි.

DNS ට ද වරාය ගෙන යා නොහැක. HTTP පිරිවිතරය යෝජනා ක්‍රමයේ පෙරනිමි අගයන් නිර්වචනය කරයි, A හෝ AAAA වාර්තාවක් ලිපිනයක් ලබා දෙන අතර CNAME වෙනත් නමක් ලබා දෙයි. බ්‍රව්සරය තවමත් යෝජනා ක්‍රමයේ වරාය එකතු කරයි, එබැවින් URL එකේ පැහැදිලි වරායක් පමණක් ගමනාන්තය වෙනස් කරයි.

විකල්පය එක: පැහැදිලි වරාය තබා ගන්න

බොහෝ විට නිවැරදි පිළිතුර අලංකාර නොවන එකයි. වරාය සමඟ සම්පූර්ණ URL ප්‍රකාශයට පත් කරන්න, එයට සහාය දෙන පිවිසුමක TLS අවසන් කරන්න, සහ ජනනය කරන සෑම සබැඳියක්ම එකම මූලය රඳවා ගන්නා බවට සහතික වන්න. කුඩා, පාලිත ප්‍රේක්ෂකයින් සඳහා මෙය සම්පූර්ණයි, දෘශ්‍ය වරාය අංකයක් හැර වෙනත් කිසිදු වියදමක් නැත.

එහි සිටියදී යොමු කිරීම් සහ cookie විශාලත්වය පරීක්ෂා කරන්න, මන්ද තමන්ගේම hostname එක Location ශීර්ෂයේ ලියන backend එකක් මෙම විධිවිධානය අවලංගු කරයි.

විකල්පය දෙක: පෙරනිමි වරායේ සැබෑ පිවිසුමක් ලබා ගන්න

සමහර සැපයුම්කරුවන් සහ සත්කාරක විධිවිධාන 80 සහ 443 බෙදාගත් හෝ කැපවූ ලිපිනයක ලේඛනගත සේවාවක් ලෙස යොමු කරයි. පොදු පිටවීම් ලිපිනයක් අත්තනෝමතික ඇතුළත වරායන් අදහස් කරන බව උපකල්පනය කරනවාට වඩා සැබවින්ම ඇතුළත් වන්නේ කුමක්දැයි අසන්න. කැපවූ පිටවීම් ලිපිනයක් ඇතුළත යොමු කිරීම ගැන කිසිවක් නොකියයි.

හිමිකාරිත්වය සහ ලබා ගැනීමේ හැකියාව ලිඛිතව තහවුරු කරන්න, උමඟ වෙනත් ලිපිනයක් සමඟ නැවත සම්බන්ධ වන විට පිවිසුමට කුමක් සිදුවේද යන්නද ඇතුළුව. උමඟ සමඟ ගමන් කරන පිවිසුමක් DNS අසාර්ථක බව පෙනෙන බාධා ඇති කරයි.

විකල්පය තුන: ඉදිරියෙන් frontend එකක් තබන්න

ළඟා විය හැකි ලිපිනයක ඇති ප්‍රතිලෝම නියෝජිතයෙකුට 443 හි සවන් දී TLS අවසන් කිරීමට කළ හැකි අතර VPN හරහා backend වෙත වෙනම සම්බන්ධතාවයක් විවෘත කළ හැක. අමුත්තන්ට frontend හි නම සහ පෙරනිමි වරාය පෙනෙන අතර, frontend ඔබ වෙනුවෙන් backend හි ඉහළ වරාය සමඟ කතා කරයි. මෙය ක්‍රියා කරන්නේ පිවිසුම් ලක්ෂ්‍යය සමඟ සටන් කරනවාට වඩා ගෘහ නිර්මාණය වෙනස් කරන බැවිනි. එවිට backend ට පොදු අන්තර්ජාලයේ ඇතුළත වරායක් කිසිසේත් අවශ්‍ය නොවේ.

මෙය ඔබ ක්‍රියාත්මක කරන දේ ද වෙනස් කරයි. frontend සතුව පොදු TLS, ප්‍රවේශ ප්‍රතිපත්තිය, ලොග සහ ලබා ගැනීමේ හැකියාව ඇත, එය backend තේරීම අපේක්ෂිත සේවාවට සීමා කළ යුතුය. frontend සිට backend දක්වා පිම්ම HTTPS භාවිතා කරන්නේ නම්, එම පිම්මේ සහතික වලංගු කිරීම තබා ගන්න.

එක් මූලයක් තබා ගන්න

frontend හි පොදු hostname, යෝජනා ක්‍රමය සහ වරාය අමුත්තන් භාවිතා කරන මූලය සාදයි, එබැවින් යෙදුමේ බාහිර URL, යොමු කිරීම් සහ cookie එම මූලය සඳහා වින්‍යාස කරන්න. යෙදුම නිරපේක්ෂ සබැඳි ගොඩනඟන්නේ නම් මුල් සත්කාරකය සහ යොමු කළ යෝජනා ක්‍රමය යවන්න. පරිශීලකයින් පෞද්ගලික නමකට හෝ ඉහළ වරායකට ආපසු යවන ප්‍රතිචාරයක් ඔබ දැන් ගොඩනගා ඇති පිරිසිදු පිවිසුම අවලංගු කරයි.

පසුව ප්‍රේක්ෂකයින් සිහියේ තබාගෙන තීරණය කරන්න. කෙටි URL එකක් කළමනාකරණය කරන frontend එකක් සාධාරණීකරණය කළ හැකි අතර, VPN සඳහා පමණක් වූ පෞද්ගලික සේවාවක් අහම්බෙන් පොදු එකක් බවට පත් කිරීම වටී නොවේ.