സമർപ്പിത VPN IP നിങ്ങളുടെ വെബ്സൈറ്റ് പ്രസിദ്ധീകരിക്കുന്നില്ല
സമർപ്പിത എക്സിറ്റ് വിലാസം ഇൻബൗണ്ട് ഡെലിവറിയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഫോർവേഡിംഗ് കരാർ പരിശോധിക്കുക, ഒറിജിൻ ഭാഗം പൂർത്തിയാക്കുക, തുടർന്ന് ഉയർന്ന പോർട്ട് പ്രസിദ്ധീകരിക്കുക.
VPN ദാതാവിൽ നിന്ന് സമർപ്പിത IP വാങ്ങുന്നത് മുൻവാതിൽ വാങ്ങുന്നത് പോലെ തോന്നുന്നു. വിലാസം സ്ഥിരമാണ്, ടണൽ പ്രവർത്തിക്കുന്നു, എന്നിട്ടും പുറത്തുള്ള ആർക്കും സൈറ്റ് ലോഡ് ചെയ്യുന്നില്ല. നിങ്ങൾ വാങ്ങിയത് ഒരു അനുവദനമാണ്, ഇൻബൗണ്ട് ഫോർവേഡിംഗ് നിയമമല്ല. രണ്ടും ഒരേ കടയിൽ വിൽക്കുന്നു, പക്ഷേ പൂർണ്ണമായും വ്യത്യസ്ത സ്ഥലങ്ങളിൽ ക്രമീകരിക്കുന്നു.
വിലാസം ഒരു അനുവദനമാണ്, ഫോർവേഡിംഗ് നിയമമല്ല
ഇൻബൗണ്ട് പൊതു വിലാസമോ ഹോസ്റ്റ്നാമമോ, അനുവദനീയമായ ട്രാൻസ്പോർട്ട്, അനുവദിച്ച ബാഹ്യ പോർട്ട്, ദാതാവ് ഡെലിവർ ചെയ്യുന്ന ക്ലയന്റ്-സൈഡ് ലക്ഷ്യസ്ഥാനം എന്നിവ രേഖപ്പെടുത്തുക. തുടർന്ന് നിങ്ങൾ തിരഞ്ഞെടുത്ത സെർവർ, പ്രോട്ടോക്കോൾ, അക്കൗണ്ട് സവിശേഷത എന്നിവ യഥാർത്ഥത്തിൽ ഫോർവേഡിംഗ് പിന്തുണയ്ക്കുന്നുണ്ടെന്നും ദാതാവ് അതിൽ ഹോസ്റ്റിംഗ് അനുവദിക്കുന്നുണ്ടെന്നും സ്ഥിരീകരിക്കുക.
സമർപ്പിത എന്ന വാക്ക് വിലാസ അനുവദനത്തെ വിവരിക്കുന്നു. ആവശ്യപ്പെടാത്ത ഇൻബൗണ്ട് ട്രാഫിക് അനുവദനീയമാണെന്ന് അത് അർത്ഥമാക്കുന്നില്ല, ഒരേ ഓപ്പറേറ്ററുടെ വ്യത്യസ്ത ആഡ്-ഓണുകൾക്ക് വ്യത്യസ്ത കഴിവുകൾ ഉണ്ടാകാം. സമർപ്പിത വിലാസവും സമർപ്പിത സെർവർ ഉൽപ്പന്നവുമാണ് ഏറ്റവും കൂടുതൽ ആശയക്കുഴപ്പത്തിലാകുന്ന രണ്ട് ലേബലുകൾ, പിന്തുണാ പേജുകൾ സാധാരണയായി ഏതാണ് ഫോർവേഡ് ചെയ്യുന്നതെന്ന് വ്യക്തമാക്കുന്നു.
| What you have | What it gives you | What it does not |
|---|---|---|
| Dedicated exit address | A stable source address for outbound traffic | Any inbound delivery at all |
| Port-forwarding add-on | A provider-side mapping to your session | Permanence across reconnects |
| Local DNAT rule | Handling for packets that arrive | Making packets arrive |
ഒരു ഉദാഹരണ കരാർ ഇങ്ങനെയാണ്: ദാതാവ് TCP 203.0.113.60:45000 നിങ്ങളുടെ ബന്ധിപ്പിച്ച ഉപകരണത്തിന്റെ HTTPS സേവനത്തിലേക്ക് 8443 പോർട്ടിൽ എത്തിക്കുന്നു. ഇത് മറ്റൊരാൾ ക്രമീകരിച്ച മാപ്പിംഗിന്റെ വിവരണമാണ്, നിങ്ങളുടെ സ്വന്തം ഫയർവാളിൽ ടൈപ്പ് ചെയ്ത് അവരുടെ എഡ്ജിൽ നിങ്ങൾക്ക് സൃഷ്ടിക്കാൻ കഴിയുന്ന നിയമമല്ല.
ഒറിജിൻ ഭാഗം പൂർത്തിയാക്കുക
വെബ് ആപ്ലിക്കേഷൻ VPN ക്ലയന്റിൽ തന്നെ പ്രവർത്തിക്കുന്നുവെങ്കിൽ, ഡെലിവർ ചെയ്ത പോർട്ടിൽ ഒരു ശ്രോതാവും ആ പോർട്ടിന് പരിമിതമായ പ്രാദേശിക-ഇൻപുട്ട് അനുമതിയും ആവശ്യമാണ്. ക്ലയന്റ് മാപ്പ് ചെയ്ത കണക്ഷൻ മറ്റൊരു ഹോസ്റ്റിലേക്ക് ഫോർവേഡ് ചെയ്യുന്നുവെങ്കിൽ, ലക്ഷ്യ വിവർത്തനം, ഫോർവേഡിംഗ് നയം, പോയി-വരവ് അതിജീവിക്കുന്ന മറുപടി പാത എന്നിവ ആവശ്യമാണ്.
ദാതാവിന്റെ പാത യഥാർത്ഥത്തിൽ അവതരിപ്പിക്കുന്ന ഉറവിട വിലാസത്തിന് ചുറ്റും ആക്സസ് നിയമങ്ങൾ രൂപകൽപ്പന ചെയ്യുക. അത് എപ്പോഴും യഥാർത്ഥ സന്ദർശകനല്ല, എപ്പോഴും VPN സെർവറുമല്ല, ആ വിലാസങ്ങളിൽ ഒന്നിന് മാത്രം പൊരുത്തപ്പെടുന്ന ഒരു നിയമം എഴുതുമ്പോൾ ഇത് പ്രധാനമാണ്.
പോർട്ട് വിവർത്തനവും HTTP-യെ HTTPS ആക്കുന്നില്ല. പൊതു പോർട്ടും പ്രാദേശിക ആപ്ലിക്കേഷൻ പോർട്ടും സ്വതന്ത്രമായി വ്യത്യാസപ്പെടാം, പക്ഷേ സ്കീം, സർട്ടിഫിക്കറ്റ് ഐഡന്റിറ്റി, റീഡയറക്ടുകൾ എന്നിവ ആളുകൾ യഥാർത്ഥത്തിൽ എത്തുന്ന സേവനവുമായി പൊരുത്തപ്പെടണം. സർട്ടിഫിക്കറ്റ് പൊതു ഹോസ്റ്റിനെ പേരിടുന്നുവെങ്കിൽ, ഓരോ ഘട്ടത്തിലും ആ പേര് നിലനിർത്തുക. ഇവിടെയുള്ള പൊരുത്തക്കേട് റൂട്ടിംഗ് പരാജയമായല്ല, ബ്രൗസർ മുന്നറിയിപ്പായി കാണപ്പെടുന്നു, ഇത് ആളുകളെ ഒരു മണിക്കൂർ തെറ്റായ ലോഗുകളിലേക്ക് അയയ്ക്കുന്നു.
ഉയർന്ന പോർട്ട് സത്യസന്ധമായി പ്രസിദ്ധീകരിക്കുക
സന്ദർശകർ നേരിട്ട് ബന്ധിപ്പിക്കുകയും ദാതാവ് ഉയർന്ന പോർട്ട് അനുവദിക്കുകയും ചെയ്താൽ, അവർക്ക് പൂർണ്ണ URL നൽകുക. സാധാരണ DNS വിലാസ റെക്കോർഡിന് സ്വതവേ 443 ഉപയോഗിക്കുന്ന HTTPS അഭ്യർത്ഥനയിൽ പോർട്ട് ചേർക്കാൻ കഴിയില്ല, TTL ക്രമീകരണത്തിന് അത് മാറ്റാനും കഴിയില്ല.
ഒരു വെബ് ഫ്രണ്ട്എൻഡിന് സന്ദർശകരെ സാധാരണ പോർട്ടിൽ സ്വീകരിച്ച് ഫോർവേഡ് ചെയ്ത ഒറിജിൻ പോർട്ടിലേക്ക് സ്വന്തം കണക്ഷൻ ഉണ്ടാക്കി ഇത് പരിഹരിക്കാം. എന്നാൽ Cloudflare-ന്റെ സ്ഥിരസ്ഥിതി പ്രോക്സി പോർട്ടുകൾ ഒരു നിർവചിച്ച പട്ടികയാണ്, പ്രോക്സി ചെയ്ത DNS റെക്കോർഡ് ചേർത്തതുകൊണ്ട് മാത്രം ഏകപക്ഷീയമായി അനുവദിച്ച പോർട്ട് പിന്തുണയുള്ള എഡ്ജ് പോർട്ടാകുന്നില്ല.
ഒറിജിന്റെ ലക്ഷ്യ പോർട്ട് മാറ്റുന്നത് സന്ദർശക പോർട്ട് മാറ്റുന്നതിൽ നിന്ന് വ്യത്യസ്ത പ്രവർത്തനമാണ്. Cloudflare-ന്റെ Origin Rules ബാക്കെൻഡ് കണക്ഷനുവേണ്ടി ലക്ഷ്യ-പോർട്ട് ഓവർറൈഡ് രേഖപ്പെടുത്തുന്നു, പിന്തുണയുള്ള നിയമം, സ്കീം, ഹോസ്റ്റ്നാമം എന്നിവയിൽ പരിമിതമാണ്. പോർട്ട് ഓവർറൈഡ് ഏകപക്ഷീയമായ UDP-ക്കോ മറ്റ് പ്രോട്ടോക്കോളുകൾക്കോ ഉള്ള പൊതു റിലേയല്ല.
ഒരു ഫ്രണ്ട്എൻഡ് TLS അവസാനിപ്പിക്കുമ്പോൾ, രണ്ട് ഘട്ടങ്ങളും സാധൂകരിക്കുക: ബ്രൗസറിൽ നിന്ന് ഫ്രണ്ട്എൻഡിലേക്കുള്ള സർട്ടിഫിക്കറ്റും ഫ്രണ്ട്എൻഡിൽ നിന്ന് ഒറിജിനിലേക്കുള്ള കണക്ഷനും. VPN ഘട്ടം രണ്ട് പരിശോധനകളിൽ ഒന്നിനെയും മാറ്റിസ്ഥാപിക്കുന്നില്ല, ആന്തരിക വിലാസം റീഡയറക്ടുകളിലേക്കോ കുക്കികളിലേക്കോ ചോർന്ന് പോകുന്നത് രണ്ടിൽ ഒന്ന് മാത്രം പൊതു പേര് മനസ്സിൽ വച്ച് ക്രമീകരിച്ചതിന്റെ സാധാരണ സൂചനയാണ്.
മാപ്പിംഗ് ജീവനോടെ നിലനിർത്തുക
ചില ദാതാക്കൾ വീണ്ടും ബന്ധിപ്പിച്ചതിന് ശേഷം മറ്റൊരു പോർട്ട് അനുവദിക്കുന്നു, പാട്ടത്തിനെടുത്ത മാപ്പിംഗിന് ദാതാവിന്റെ ഭാഗത്തെ പ്രവർത്തനത്തിലൂടെ പുതുക്കൽ ആവശ്യമായി വന്നേക്കാം. നിങ്ങളുടെ ദാതാവ് രേഖപ്പെടുത്തുന്ന സംവിധാനം പിന്തുടരുക, ശ്രോതാവ്, പ്രാദേശിക നിയമങ്ങൾ, DNS അല്ലെങ്കിൽ ഫ്രണ്ട്എൻഡ് നിയമം എന്നിവ നിലവിലെ കരാർ ആവശ്യപ്പെടുന്നിടത്ത് മാത്രം അപ്ഡേറ്റ് ചെയ്യുക.
സ്ഥിരമായ പൊതു വിലാസം പോർട്ട് പാട്ടത്തെ സ്ഥിരമാക്കുന്നില്ല. ഡാഷ്ബോർഡിൽ ഇപ്പോഴും കാണിക്കുന്ന വിലാസവും പോർട്ടും സജീവ സെഷൻ മാപ്പിംഗിന്റെ ഉടമസ്ഥനാണെന്നതിന് തെളിവല്ല, അതുകൊണ്ടാണ് പരീക്ഷണം സ്ക്രീൻഷോട്ടല്ല, പുറത്തുനിന്നുള്ള പുതിയ അഭ്യർത്ഥനയാണ്.
തുടർന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന സന്ദർഭങ്ങൾ ആവർത്തിക്കുക: സാധാരണ വീണ്ടും ബന്ധിപ്പിക്കൽ, VPN നഷ്ടം. നഷ്ടം ഒറിജിനെ ലഭ്യമല്ലാതാക്കണമെങ്കിൽ, അപ്ഡേറ്റർ പശ്ചാത്തലത്തിൽ നേരിട്ടുള്ള ISP പാത നിശബ്ദമായി വീണ്ടും പ്രസിദ്ധീകരിക്കാൻ അനുവദിക്കരുത്. ഫോർവേഡിംഗ് കരാർ സൈറ്റിന്റെ സ്ഥിരതാ ആവശ്യകതകൾ പാലിക്കാൻ കഴിയില്ലെങ്കിൽ, മറ്റൊരു വിലാസ ലേബൽ വാങ്ങി സെർവർ പോലെ പെരുമാറുമെന്ന് പ്രതീക്ഷിക്കുന്നതിന് പകരം മറ്റൊരു പ്രസിദ്ധീകരണ ക്രമീകരണം തിരഞ്ഞെടുക്കുക.