വീട്ടിലെ VPN സർവറിന് ഡൈനാമിക് DNS വേണോ?

ഡൈനാമിക് DNS പേര് ശരിയാക്കുന്നു, അകത്തേക്കുള്ള വഴിയല്ല. മൂന്ന് പരിശോധനകൾ ഹോസ്റ്റ്നെയിം മതിയോ അതോ അകത്തേക്കുള്ള പാത തകർന്നിട്ടുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു.

എന്നോട് ചോദിക്കുന്ന വീട്ടിലെ VPN പരാജയങ്ങളിൽ ഭൂരിഭാഗവും DNS പരാജയങ്ങളല്ല, എന്നിട്ടും ആളുകൾ ആദ്യം ഡൈനാമിക് DNS സബ്സ്ക്രിപ്ഷൻ വാങ്ങുന്നു. എന്തെങ്കിലും കോൺഫിഗർ ചെയ്യുന്നതിന് മുൻപ്, ഹോസ്റ്റ്നെയിമാണോ യഥാർത്ഥത്തിൽ തകർന്ന ഭാഗം എന്ന് തീരുമാനിക്കുക. നിങ്ങളുടെ ISP നൽകിയ വിലാസം മാറുമ്പോൾ അപ്ഡേറ്റർ റെക്കോർഡ് വീണ്ടും എഴുതുന്നു; അതിന് പോർട്ട് തുറക്കാനോ കാരിയർ NAT ഭേദിക്കാനോ പ്രവർത്തിക്കുന്ന WireGuard സെഷനോട് അതിന്റെ എൻഡ്പോയിന്റ് മാറിയെന്ന് അറിയിക്കാനോ കഴിയില്ല. ഡൈനാമിക് DNS മുഴുവൻ പരിഹാരമാണോ അതിന്റെ ഒരു വരി മാത്രമാണോ എന്ന് മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു.

വ്യവസ്ഥ ഒന്ന്: നിങ്ങളുടെ വിലാസം യഥാർത്ഥത്തിൽ മാറുന്നു

വസതി വിലാസങ്ങൾ സാധാരണ കാരണങ്ങളാൽ മാറുന്നു: വൈദ്യുതി മുടങ്ങിയതിന് ശേഷം മോഡം വീണ്ടും സിങ്ക് ചെയ്യുന്നു, ISP പൂൾ വീണ്ടും സന്തുലിതമാക്കുന്നു, നീണ്ട തടസ്സത്തിന് ശേഷം പുതിയ പാട്ടം വരുന്നു. ചില ലൈനുകളിൽ അവ വളരെ അപൂർവമായി മാറുന്നു, അതേ വിലാസം ഒരു വർഷം നിലനിൽക്കുന്നത് ഞാൻ കണ്ടിട്ടുണ്ട്; ബിസിനസ് പ്ലാനുകളിൽ പലപ്പോഴും സ്ഥിരമായ ഒന്നുണ്ട്. പന്ത്രണ്ട് മാസത്തിൽ ഒന്നും മാറിയില്ലെങ്കിൽ, കൈകൊണ്ട് തിരുത്തുന്ന ഒരു A റെക്കോർഡ് ജീവനോടെ നിലനിർത്തേണ്ട ഒരു ഡീമൺ കുറവാണ്.

ഊഹിക്കുന്നതിന് പകരം അളക്കുക. റൗട്ടറിന്റെ സ്റ്റാറ്റസ് പേജിൽ WAN വിലാസം വായിച്ച്, പുറംലോകം കാണുന്നതുമായി താരതമ്യം ചെയ്യുക. ഇത് LAN-ലെ ഒരു യന്ത്രത്തിൽ നിന്ന് പ്രവർത്തിപ്പിക്കുക:

curl -fsS https://api.ipify.org; echo

രണ്ട് മൂല്യങ്ങളും വ്യത്യസ്തമാണെങ്കിൽ, നിങ്ങളുടെ റൗട്ടറിന് മുന്നിൽ എന്തോ വിവർത്തനം ചെയ്യുന്നു, ഒരു ഹോസ്റ്റ്നെയിം അപ്ഡേറ്റും അത് ശരിയാക്കില്ല. 100.64.0.0/10-നുള്ളിലെ വിലാസം കാരിയർ-ഗ്രേഡ് NAT-നുള്ള പങ്കിട്ട ശ്രേണിയാണ്, ശരിയായി അപ്ഡേറ്റ് ചെയ്ത പേരും പുറത്തുനിന്ന് സമയം കവിയുന്നതിന്റെ സാധാരണ കാരണം അതാണ്.

വ്യവസ്ഥ രണ്ട്: ക്ലയന്റുകൾ പേര് വീണ്ടും തിരയുന്നു

ചെറിയ TTL ആളുകൾ ഒഴിവാക്കുന്ന ഭാഗമാണ്. ആവർത്തന റിസോൾവറുകൾ റെക്കോർഡിന്റെ TTL മാനിക്കുന്നു, പക്ഷേ ക്ലയന്റ് സ്റ്റാക്കുകൾ വെവ്വേറെ കാഷെ ചെയ്യുന്നു, ഇതിനകം ഉയർന്ന ടണൽ ഒന്നും വീണ്ടും പരിഹരിക്കുന്നില്ല. ഡീബഗ് ചെയ്യുമ്പോൾ റെക്കോർഡ് 60-300 സെക്കൻഡിൽ വയ്ക്കുക; പഴയ ഉത്തരം നൽകുന്ന ജാലകം അത് ചുരുക്കുന്നു, കണക്ട് ചെയ്ത സെഷൻ കൈമാറ്റം ചെയ്യുന്നില്ല.

OpenVPN വീണ്ടും കണക്ട് ചെയ്യുമ്പോഴെല്ലാം വരി remote vpn.example.net 1194 വീണ്ടും പരിഹരിക്കുന്നു, കൂടാതെ resolv-retry infinite തിരയൽ പരാജയപ്പെടുമ്പോൾ പുറത്തുകടക്കുന്നതിന് പകരം വീണ്ടും ശ്രമിക്കാൻ അതിനെ നിർബന്ധിക്കുന്നു. സർവറിൽ float സ്ഥാപിത സെഷന് സ്രോതസ്സ് വിലാസം മാറിയ സഹപ്രവർത്തകനെ പിന്തുടരാൻ അനുവദിക്കുന്നു. WireGuard കൂടുതൽ നേരിട്ടുള്ളതാണ്: wg-quick up കോൺഫിഗറേഷൻ പ്രയോഗിക്കുമ്പോൾ Endpoint പരിഹരിക്കുന്നു, ടണൽ വീണ്ടും നിർമ്മിക്കുമ്പോൾ ക്ലയന്റ് അത് വീണ്ടും പരിഹരിക്കുന്നു, അതിനാൽ പഴയ വിലാസത്തോട് ഇപ്പോഴും വിജയിക്കുന്ന ഹാൻഡ്ഷേക്ക് നിലയ്ക്കുന്നതുവരെ വിജയിച്ചുകൊണ്ടിരിക്കുന്നു.

ആ വ്യത്യാസമാണ് പ്ലാൻ രൂപപ്പെടുത്തുന്നത്. ക്ലയന്റുകൾ ആവശ്യാനുസരണം കണക്ട് ചെയ്താൽ, വിലാസ മാറ്റത്തിന് ഒരു വീണ്ടും കണക്ഷന്റെ വിലയുണ്ട്. ദിവസങ്ങളോളം സെഷൻ തുറന്നിട്ടാൽ, അടുത്ത ഹാൻഡ്ഷേക്കിൽ ടണൽ മരിക്കുമെന്ന് പ്രതീക്ഷിക്കുക, ഉയർന്നു നിൽക്കുമെന്ന് കരുതുന്നതിന് പകരം ക്ലയന്റിനെ വീണ്ടും ശ്രമിക്കാൻ അനുവദിക്കുക.

വ്യവസ്ഥ മൂന്ന്: അകത്തേക്കുള്ള പാത ഇപ്പോഴും തുറന്നിരിക്കുന്നു

ഡൈനാമിക് DNS പേര് എവിടെ ചൂണ്ടുന്നു എന്ന് മാത്രം മാറ്റുന്നു, മറ്റൊന്നുമില്ല. റൗട്ടറിലെ പോർട്ട് ഫോർവേഡിംഗ്, VPN ഹോസ്റ്റിലെ ഫയർവാൾ നിയമം, ISP-യുടെ ഇൻബൗണ്ട് പാക്കറ്റുകൾക്കുള്ള അനുമതി — എല്ലാം റെക്കോർഡ് പ്രധാനമാകുന്നതിന് മുൻപ് ഉണ്ടായിരിക്കണം. ഫോർവേഡിംഗ് എന്തിനെ ലക്ഷ്യമിടുന്നു എന്ന് നോക്കുക: അത് ഇന്റർഫേസിന് പകരം WAN വിലാസത്തിൽ പിന്നിട്ടിട്ടുണ്ടെങ്കിൽ, വിലാസ മാറ്റം ഫോർവേഡിംഗ് നിശബ്ദമായി തകർക്കുന്നു, കുറ്റം റെക്കോർഡിൽ വീഴുന്നു.

പുറത്തുനിന്ന് പരീക്ഷിക്കുക. Wi-Fi ഓഫാക്കിയ സെല്ലുലാർ ഡാറ്റയിലെ ഫോൺ ഏറ്റവും വിലകുറഞ്ഞ സത്യസന്ധമായ പരീക്ഷണമാണ്; അതേ LAN-ലെ ലാപ്ടോപ്പ് അല്ല. പേര് നിങ്ങളുടെ പൊതു വിലാസത്തിലേക്ക് പരിഹരിക്കുകയും റൗട്ടറിൽ NAT ലൂപ്പ്ബാക്ക് ഇല്ലാതിരിക്കുകയും ചെയ്യുമ്പോൾ, ഉള്ളിലെ പരീക്ഷണം പരാജയപ്പെടുന്നു, റെക്കോർഡ് പൂർണ്ണമായി ശരിയാണ്, ഇത് ഭൂരിഭാഗം ആളുകളെയും ഒരിക്കലും തെറ്റായിരുന്നിട്ടില്ലാത്ത റെക്കോർഡ് തിരുത്താൻ അയയ്ക്കുന്നു.

മൂന്നും ശരിയാകുമ്പോൾ എന്ത് പ്രവർത്തിപ്പിക്കണം

ചെറിയ ഹോസ്റ്റിന് ddclient ഏറ്റവും കുറഞ്ഞ ആശ്ചര്യമുള്ള അപ്ഡേറ്ററാണ്. കുറഞ്ഞ കോൺഫിഗറേഷൻ ദാതാവ് കാണുന്ന വിലാസം പ്രസിദ്ധീകരിക്കുന്നു, ഇത് ഇരട്ട NAT പിശക് ഒഴിവാക്കുന്നു:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

shell ലൂപ്പിന് പകരം ഓരോ കുറച്ച് മിനിറ്റിലും systemd ടൈമറിൽ നിന്ന് ഇത് പ്രവർത്തിപ്പിക്കുക, വിജയം കരുതുന്നതിന് പകരം ദാതാവിന്റെ മറുപടി ലോഗ് ചെയ്യുക. ക്രെഡൻഷ്യലുകളെ താക്കോൽ പോലെ കാണുക, കാരണം ഓരോ ക്ലയന്റും എവിടേക്ക് അയയ്ക്കുന്നു എന്ന് അതാണ് തീരുമാനിക്കുന്നത്: അക്കൗണ്ട് പാസ്വേഡിന് പകരം പരിമിതമായ അപ്ഡേറ്റ് ടോക്കൺ ഉപയോഗിക്കുക, ഫയൽ 0600 മോഡിൽ സൂക്ഷിക്കുക, അപ്ഡേറ്റുകൾ HTTPS-ൽ അയയ്ക്കുക.

പ്രതിജ്ഞാബദ്ധരാകുന്നതിന് മുൻപ് പരിശോധിക്കുക

ഒരു തിരയൽ ബാക്കിയുള്ള ലോകം എന്ത് കാണുന്നു എന്ന് പറയുന്നു, മാറ്റത്തിന് ശേഷം കാത്തിരിക്കേണ്ട TTL അത് അച്ചടിക്കുന്നു:

dig +noall +answer vpn.example.net @1.1.1.1

ആ വിലാസം റൗട്ടറിന്റെ WAN വിലാസവുമായി താരതമ്യം ചെയ്യുക. ഒത്തുപോയാൽ, പേര് അതിന്റെ ജോലി ചെയ്യുന്നു, ഇപ്പോഴും പരാജയപ്പെടുന്നത് ഇൻബൗണ്ട് എത്തിച്ചേരൽ, ഒരു താക്കോൽ, അല്ലെങ്കിൽ വീണ്ടും പരിഹരിക്കാത്ത ക്ലയന്റ് എന്നിവയാണ്. വ്യത്യസ്തമാണെങ്കിൽ, അപ്ഡേറ്റർ തെറ്റായ ഇന്റർഫേസ് പ്രസിദ്ധീകരിക്കുന്നു, പലപ്പോഴും അത് റൗട്ടറിലല്ലാതെ റൗട്ടറിന് പിന്നിലെ VPN ഹോസ്റ്റിൽ പ്രവർത്തിച്ചതിനാൽ.

ഒരു മിനിറ്റ് എടുക്കുന്ന റോൾബാക്ക് സൂക്ഷിക്കുക: അവസാനം പ്രവർത്തിച്ച വിലാസവും മുൻ TTL-ഉം കുറിക്കുക, ദാതാവിന് മോശം ഉച്ചയ്ക്ക് ശേഷമുള്ളപ്പോൾ രണ്ടും കൈകൊണ്ട് പ്രസിദ്ധീകരിക്കാം.

ഉത്തരം ഇല്ല എന്നാകുമ്പോൾ

വ്യവസ്ഥ ഒന്നോ മൂന്നോ പരാജയപ്പെട്ടാൽ, കോൺഫിഗറേഷനല്ല, തീരുമാനമാണ് മാറുന്നത്. കാരിയർ NAT-ന് പിന്നിൽ നിങ്ങളുടെ പ്രായോഗിക ഓപ്ഷനുകൾ ISP-യോട് പൊതു വിലാസം ആവശ്യപ്പെടുക, പ്രവേശന കേന്ദ്രം സ്ഥിരമായ വിലാസമുള്ള ചെറിയ VPS-ലേക്ക് മാറ്റുക, അല്ലെങ്കിൽ സ്വന്തം കൂടിക്കാഴ്ച സൂക്ഷിക്കുന്ന ഒരു ഓവർലേ ഉപയോഗിക്കുക എന്നിവയാണ്. വിലാസം സ്ഥിരമാണെങ്കിൽ, അപ്ഡേറ്റർ ഒഴിവാക്കുക: ഒരു A റെക്കോർഡ്, IPv6 ഉപയോഗിക്കുന്നുവെങ്കിൽ ഒരു AAAA റെക്കോർഡ്, അതേ പോർട്ട് ഫോർവേഡിംഗ്.

ക്ലയന്റുകൾ കണക്ട് ചെയ്തിരിക്കെ വിലാസം മാറിയാൽ, സത്യസന്ധമായ പരിഹാരം ക്ലയന്റിലാണ്: വീണ്ടും കണക്ഷന്റെ യുക്തിയും വീണ്ടും ശ്രമത്തിന്റെ ഇടവേളയും, വേഗമേറിയ അപ്ഡേറ്ററല്ല. രണ്ടാമത്തെ ദാതാവ് ചേർക്കുന്നത് ഇടവേള മറയ്ക്കുന്നു മാത്രം.

മുന്നോട്ട് പോകുന്നതിന് മുൻപ് നാല് കാര്യങ്ങൾ ക്രമത്തിൽ സ്ഥിരീകരിക്കുക:

  • അപ്ഡേറ്റർ പ്രസിദ്ധീകരിക്കുന്ന വിലാസം റൗട്ടറിന്റെ WAN വിലാസവുമായി ഒത്തുപോകുന്നു.
  • റെക്കോർഡിന്റെ TTL മാറ്റം കുറച്ച് മിനിറ്റുകൾക്കുള്ളിൽ കാണാവുന്നത്ര ചെറുതാണ്.
  • പോർട്ട് ഫോർവേഡിംഗ് സ്ഥിരമായ വിലാസത്തോടല്ല, ഇന്റർഫേസിനോട് ബന്ധിപ്പിച്ചിരിക്കുന്നു.
  • അവസാന മാറ്റത്തിന് ശേഷം ഒരു യഥാർത്ഥ ക്ലയന്റ് വീണ്ടും കണക്ട് ചെയ്ത് ട്രാഫിക് കടത്തിവിട്ടു.

നാലും ശരിയാണെങ്കിൽ, ക്രമീകരണം വെറുതെ വിടുക; നിങ്ങളുടെ അടുത്ത പരാജയം പേരിടൽ പ്രശ്നമല്ല, ഒരു താക്കോലോ ഫയർവാൾ നിയമമോ ആണ്. ഏതെങ്കിലും പരാജയപ്പെട്ടാൽ, മറ്റൊരു ചലിക്കുന്ന ഭാഗം ചേർക്കുന്നതിന് മുൻപ് ആ വരി ശരിയാക്കുക. RFC 2136 അപ്ഡേറ്റ് സംവിധാനം തന്നെ വിവരിക്കുന്നു, ഡീമൺ താരിൽ എന്ത് വയ്ക്കുന്നു എന്ന് കാണാൻ താൽപ്പര്യമുണ്ടെങ്കിൽ.

അനുബന്ധ ലേഖനങ്ങൾ