നിങ്ങളുടെ VPN ഹോസ്റ്റ് ചെയ്യുന്നതിന് മുൻപ് VPS അനുവദിക്കേണ്ടത് എന്തെല്ലാം

ഇൻസ്റ്റൻസ് ബൂട്ട് ചെയ്യുന്നു, പാക്കേജ് ഇൻസ്റ്റാളുകൾ വിജയിക്കുന്നു, സേവനം പ്രവർത്തിക്കുന്ന അവസ്ഥ പോലും റിപ്പോർട്ട് ചെയ്യുന്നു, പക്ഷേ ഒന്നും കണക്ട് ചെയ്യുന്നില്ല. ഈ മാതൃക വെർച്വൽ സ്വകാര്യ സെർവറുകളിൽ സാധാരണമാണ്, കാരണം ഇന്ത്യർനെറ്റിൽ എളുപ്പം എത്തുന്ന ഗെസ്റ്റിന് പോലും നിങ്ങളുടെ പ്രോട്ടോക്കോൾ ആവശ്യപ്പെടുന്ന ഇന്റർഫേസ് സൃഷ്ടിക്കാൻ കഴിയണമെന്നില്ല. അഞ്ച് പരിശോധനകൾ ടണൽ സേവനം നൽകാൻ കഴിയുന്ന ഹോസ്റ്റിനെ കേവലം തയ്യാറായി തോന്നുന്ന ഹോസ്റ്റിൽ നിന്ന് വേർതിരിക്കുന്നു, ആദ്യം പരാജയപ്പെടുന്ന പരിശോധന സാധാരണയായി അതിനുശേഷമുള്ളതെല്ലാം വിശദീകരിക്കുന്നു. ഓരോന്നും പ്രവർത്തിപ്പിക്കാൻ വിലകുറഞ്ഞതാണ്, കുറിപ്പിന് പകരം തീരുമാനത്തിൽ അവസാനിക്കുന്നു.

പ്രോട്ടോക്കോളിന് ആവശ്യമായ ഇന്റർഫേസ് സ്ഥിരീകരിക്കുക

OpenVPN TUN-ന് മേലെ പ്രവർത്തിക്കാൻ പ്രതീക ഉപകരണവും അതിന് പിന്നിലെ കേർണൽ മൊഡ്യൂളും വേണം; WireGuard-ന് സ്വന്തം കേർണൽ പിന്തുണ അല്ലെങ്കിൽ യോജിക്കുന്ന പ്രതീക്ഷകളുള്ള ഉപയോക്തൃ സ്ഥല നടപ്പാക്കൽ വേണം. മാനേജ് ചെയ്ത കണ്ടെയ്നറുകൾ ഉപകരണം ഒരിക്കലും വെളിപ്പെടുത്താത്ത ഹോസ്റ്റ് കേർണൽ പങ്കിടാം, ചില പ്ലാറ്റ്ഫോമുകൾ എന്ത് ഇൻസ്റ്റാൾ ചെയ്താലും ടണൽ ഇന്റർഫേസുകൾ സൃഷ്ടിക്കുന്നത് പൂർണ്ണമായി വിലക്കുന്നു.

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

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

ആദ്യ ജോടിയിൽ നിരസിക്കൽ എന്നാൽ TUN ലഭ്യമല്ല, OpenVPN-ന്റെ ഡിഫോൾട്ട് മോഡ് ആരംഭിക്കാൻ കഴിയില്ല; അവസാന വരിയിൽ നിരസിക്കൽ എന്നാൽ WireGuard കേർണൽ ഇന്റർഫേസ് ഇല്ല. കേർണലിന്റെ TUN/TAP രേഖ ആദ്യ പരിശോധന പരീക്ഷിക്കുന്ന ഉപകരണത്തെ വിവരിക്കുന്നു. രണ്ട് പരാജയങ്ങളിൽ ഒന്നും VPN പാക്കേജ് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്ത് പരിഹരിക്കുന്നില്ല.

ഇൻബൗണ്ട് പാതയ്ക്ക് രണ്ട് ഉടമകളുണ്ടെന്ന് ഓർക്കുക

പ്രൊവൈഡറുടെ നെറ്റ്‌വർക്ക് നിയമങ്ങളും ഗെസ്റ്റിന്റെ ഫയർവാളും വേറിട്ട സംവിധാനങ്ങളാണ്, ട്രാഫിക് രണ്ടിലൂടെയും കടക്കണം. ഗെസ്റ്റിൽ ബന്ധിച്ച ലിസണർ പ്രൊവൈഡറുടെ സെക്യൂരിറ്റി ഗ്രൂപ്പ് പോർട്ട് ഒഴിവാക്കിയാൽ ഒന്നും അർത്ഥമാക്കുന്നില്ല, തുറന്ന പ്രൊവൈഡർ നിയമം ഗെസ്റ്റ് പാക്കറ്റ് നിരസിച്ചാൽ ഒന്നും ചെയ്യുന്നില്ല. ലിസണർ, പിന്നെ ഗെസ്റ്റ് നിയമങ്ങൾ, പിന്നെ പ്രൊവൈഡർ പാനൽ, ആ ക്രമത്തിൽ പരിശോധിച്ച്, പോർട്ട് നമ്പറിനൊപ്പം പ്രോട്ടോക്കോളും സ്ഥിരീകരിക്കുക. നേരിട്ട് പ്രൊവൈഡർ പാനലിലേക്ക് ചാടുന്നതാണ് ആവശ്യമില്ലാത്ത ഒരു ശ്രേണി തുറക്കാൻ ഇടയാക്കുന്നത്.

UDP സാധാരണ ഇരയാണ്: പല പ്ലാറ്റ്ഫോമുകളും സ്വതവേ TCP അനുവദിക്കുകയും UDP നിയമങ്ങളെ വേറിട്ട എൻട്രിയായി കണക്കാക്കുകയും ചെയ്യുന്നു. ഇൻസ്റ്റൻസ് പൊതു വിലാസം വെക്കുന്നതിന് പകരം പ്രൊവൈഡറുടെ NAT-ന് പിന്നിൽ ആണെങ്കിൽ, പ്രൊവൈഡർ വശത്തെ പോർട്ട് ഫോർവേഡിംഗ് ഒത്തുതീർപ്പാക്കേണ്ട മൂന്നാം കോൺഫിഗറേഷനാകുന്നു.

തിരിച്ചുള്ള വഴി ആസൂത്രണം ചെയ്യുക, പുറപ്പെടൽ മാത്രമല്ല

പൂർണ്ണ ടണൽ സേവനത്തിന് ഫോർവേഡിംഗ് സജീവം, ക്ലയന്റ് ട്രാഫിക്കിനുള്ള വിവർത്തനമോ റൂട്ടിംഗ് രീതിയോ, ക്ലയന്റ് കൂട്ടത്തിലേക്ക് എത്തുന്ന തിരിച്ചുവഴിയോ വേണം. ലിസണർ തുറക്കുന്നത് ഇവയൊന്നും നൽകുന്നില്ല. സ്ഥാപിക്കപ്പെടുന്നെങ്കിലും ഉപയോഗപ്രദമായ ട്രാഫിക് വഹിക്കാത്ത ടണൽ സാധാരണയായി ഓത്തന്റിക്കേഷനിലല്ല, ഇവിടെയാണ് പരാജയപ്പെടുന്നത്. വിജയകരമായ ഹാൻഡ്‌ഷേക്കിനെ രോഗനിർണയത്തിന്റെ അവസാനമല്ല, തുടക്കമായി കാണുക.

പദ്ധതി മൂന്ന് വ്യക്തമായ തീരുമാനങ്ങളായി എഴുതുക: ക്ലയന്റുകൾക്ക് ഏത് സ്രോതസ്സ് ശ്രേണി ലഭിക്കുന്നു, അവരുടെ ട്രാഫിക് ഇന്ത്യർനെറ്റിലേക്ക് എങ്ങനെ പുറപ്പെടുന്നു, മറുപടികൾ തിരിച്ചുവഴി എങ്ങനെ കണ്ടെത്തുന്നു. തുടർന്ന് ക്ലയന്റ് പരീക്ഷിക്കുന്നതിന് മുൻപ് കേർണൽ പദ്ധതിയോട് യോജിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക, നിശ്ശബ്ദമായ പൊരുത്തക്കേടിനെ ക്ലയന്റ് വശത്തെ തകരാറായി തെറ്റിദ്ധരിക്കാതിരിക്കാൻ.

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

IPv6 കാര്യം വ്യക്തമായി തീരുമാനിക്കുക

IPv6 ഗേറ്റ്‌വേയ്ക്ക് വ്യത്യസ്തമായി പെരുമാറുന്ന പല സംവിധാനങ്ങളിലൂടെ വരുന്നു: ഇൻസ്റ്റൻസിലെ വിലാസം, റൂട്ട് ചെയ്ത പ്രിഫിക്സ്, അല്ലെങ്കിൽ ഒന്നുമില്ല. റൂട്ട് ചെയ്ത പ്രിഫിക്സ് മാത്രമാണ് സെർവറിന് സാധാരണ രീതിയിൽ ക്ലയന്റുകൾക്ക് വിലാസങ്ങൾ നൽകാൻ അനുവദിക്കുന്നത്. ഹോസ്റ്റിൽ പ്രവർത്തിക്കുന്ന IPv6 വിലാസം ഉപയോഗയോഗ്യമായ ക്ലയന്റ് പ്രിഫിക്സ് അർത്ഥമാക്കുന്നു എന്ന ഊഹം പിന്നീട് പകുതി മുറിഞ്ഞ കണക്ടിവിറ്റിയായി പ്രത്യക്ഷപ്പെടുന്ന തെറ്റാണ്. IPv4 മാത്രം ഉപയോഗിച്ച് നടത്തുന്ന എല്ലാ പരീക്ഷണങ്ങളെയും അതിജീവിക്കുന്ന തരം തകരാറാണിത്.

പ്രൊവൈഡർ ഒരു പ്രിഫിക്സും റൂട്ട് ചെയ്യുന്നില്ലെങ്കിൽ, ടണൽ IPv4 മാത്രമാണോ, ക്ലയന്റുകളെ അത് അറിയിക്കണോ എന്ന് തീരുമാനിക്കുക. ബന്ധിപ്പിച്ച ഉപയോക്താക്കൾക്ക് IPv6 ലക്ഷ്യങ്ങൾ നിശ്ശബ്ദമായി കറുത്ത കുഴിയിലേക്ക് എറിയുന്ന ഭാഗിക കോൺഫിഗറേഷനെക്കാൾ രേഖപ്പെടുത്തിയ അഭാവം സുരക്ഷിതമാണ്.

പുറം ക്ലയന്റിൽ നിന്ന് അത് തെളിയിക്കുക

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

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

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