നിങ്ങളുടെ 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 അവസാനിപ്പിക്കുക, സൃഷ്ടിക്കുന്ന ഓരോ ലിങ്കും അതേ ഉത്ഭവം നിലനിർത്തുന്നുവെന്ന് ഉറപ്പാക്കുക. ചെറിയ, നിയന്ത്രിത പ്രേക്ഷകർക്ക് ഇത് പൂർണ്ണമാണ്, കാണുന്ന പോർട്ട് നമ്പറല്ലാതെ മറ്റൊന്നും ചെലവാക്കുന്നില്ല.

അവിടെയുള്ളപ്പോൾ റീഡയറക്ടുകളും കുക്കി പരിധിയും പരിശോധിക്കുക, കാരണം സ്വന്തം ഹോസ്റ്റ്നെയിം Location ഹെഡറിൽ എഴുതുന്ന backend ഈ ക്രമീകരണം അസാധുവാക്കുന്നു.

ഓപ്ഷൻ രണ്ട്: ഡിഫോൾട്ട് പോർട്ടിൽ യഥാർത്ഥ പ്രവേശനം നേടുക

ചില ദാതാക്കളും ഹോസ്റ്റിംഗ് ക്രമീകരണങ്ങളും രേഖപ്പെടുത്തിയ സേവനമായി പങ്കിട്ടതോ സമർപ്പിതമോ ആയ വിലാസത്തിൽ 80-ഉം 443-ഉം ഫോർവേഡ് ചെയ്യുന്നു. പൊതു എക്സിറ്റ് വിലാസം ഏകപക്ഷീയമായ ഇൻബൗണ്ട് പോർട്ടുകൾ അർത്ഥമാക്കുന്നു എന്ന് അനുമാനിക്കുന്നതിന് പകരം യഥാർത്ഥത്തിൽ എന്താണ് ഉൾപ്പെടുന്നതെന്ന് ചോദിക്കുക. സമർപ്പിത ഔട്ട്ബൗണ്ട് വിലാസം ഇൻബൗണ്ട് ഫോർവേഡിംഗിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

ഉടമസ്ഥതയും ലഭ്യതയും രേഖാമൂലം സ്ഥിരീകരിക്കുക, ടണൽ മറ്റൊരു വിലാസത്തിൽ വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ പ്രവേശനത്തിന് എന്ത് സംഭവിക്കും എന്നത് ഉൾപ്പെടെ. ടണലിനൊപ്പം നീങ്ങുന്ന പ്രവേശനം DNS പരാജയങ്ങൾ പോലെ തോന്നുന്ന തടസ്സങ്ങൾ സൃഷ്ടിക്കുന്നു.

ഓപ്ഷൻ മൂന്ന്: മുന്നിൽ ഒരു ഫ്രണ്ട്എൻഡ് വയ്ക്കുക

എത്താവുന്ന വിലാസത്തിലെ ഒരു റിവേഴ്സ് പ്രോക്സിക്ക് 443-ൽ കേൾക്കാനും TLS അവസാനിപ്പിക്കാനും കഴിയും, VPN വഴി backend-ലേക്ക് വേറിട്ട ഒരു കണക്ഷൻ തുറക്കാം. സന്ദർശകർ ഫ്രണ്ട്എൻഡിന്റെ പേരും ഡിഫോൾട്ട് പോർട്ടും കാണുന്നു, ഫ്രണ്ട്എൻഡ് നിങ്ങൾക്കുവേണ്ടി backend-ന്റെ ഉയർന്ന പോർട്ടുമായി സംസാരിക്കുന്നു. ഇത് പ്രവർത്തിക്കുന്നത് പ്രവേശന ബിന്ദുവിനോട് പോരാടുന്നതിന് പകരം ആർക്കിടെക്ചർ മാറ്റുന്നതുകൊണ്ടാണ്. അപ്പോൾ backend-ന് പൊതു ഇന്റർനെറ്റിൽ ഇൻബൗണ്ട് പോർട്ട് ആവശ്യമില്ല.

ഇത് നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നതിനെയും മാറ്റുന്നു. ഫ്രണ്ട്എൻഡിനാണ് പൊതു TLS, പ്രവേശന നയം, ലോഗുകൾ, ലഭ്യത എന്നിവയുടെ ഉടമസ്ഥത, അത് backend തിരഞ്ഞെടുപ്പ് ഉദ്ദേശിച്ച സേവനത്തിലേക്ക് പരിമിതപ്പെടുത്തണം. ഫ്രണ്ട്എൻഡിൽ നിന്ന് backend-ലേക്കുള്ള ചാട്ടം HTTPS ഉപയോഗിക്കുന്നുവെങ്കിൽ, ആ ചാട്ടത്തിൽ സർട്ടിഫിക്കറ്റ് സാധൂകരണം നിലനിർത്തുക.

ഒരു ഉത്ഭവം നിലനിർത്തുക

ഫ്രണ്ട്എൻഡിന്റെ പൊതു ഹോസ്റ്റ്നെയിം, സ്കീം, പോർട്ട് എന്നിവ സന്ദർശകർ ഉപയോഗിക്കുന്ന ഉത്ഭവം രൂപപ്പെടുത്തുന്നു, അതിനാൽ ആപ്ലിക്കേഷന്റെ ബാഹ്യ URL, റീഡയറക്ടുകൾ, കുക്കികൾ എന്നിവ ആ ഉത്ഭവത്തിനായി കോൺഫിഗർ ചെയ്യുക. ആപ്ലിക്കേഷൻ കേവല ലിങ്കുകൾ നിർമ്മിക്കുന്നുവെങ്കിൽ യഥാർത്ഥ ഹോസ്റ്റും ഫോർവേഡ് ചെയ്ത സ്കീമും അയയ്ക്കുക. ഉപയോക്താക്കളെ സ്വകാര്യ പേരിലേക്കോ ഉയർന്ന പോർട്ടിലേക്കോ തിരികെ അയയ്ക്കുന്ന പ്രതികരണം നിങ്ങൾ ഇപ്പോൾ നിർമ്മിച്ച വൃത്തിയുള്ള പ്രവേശനം അസാധുവാക്കുന്നു.

തുടർന്ന് പ്രേക്ഷകരെ മനസ്സിൽ കരുതി തീരുമാനിക്കുക. ചെറിയ URL-ന് ഒരു മാനേജ്ഡ് ഫ്രണ്ട്എൻഡിനെ ന്യായീകരിക്കാം, VPN-ന് മാത്രമുള്ള ഒരു സ്വകാര്യ സേവനത്തെ അബദ്ധത്തിൽ പൊതു സേവനമാക്കുന്നത് വിലപ്പെട്ടതല്ല.