നിങ്ങളുടെ ഹോം VPN-ന് nas.home.arpa-യ്ക്കായി സ്വന്തം DNS റെക്കോർഡുകൾ നൽകുക
dnsmasq-ൽ നിന്ന് ഒരു പേര് പ്രസിദ്ധീകരിക്കുക, resolver-നെ WireGuard വഴി റൂട്ട് ചെയ്യുക, തുടർന്ന് മുഴുവൻ ക്ലയന്റിനും DNS പുഷ് ചെയ്യുന്നതും home.arpa-യ്ക്ക് മാത്രം split-DNS-ഉം തമ്മിൽ തിരഞ്ഞെടുക്കുക.
ടണൽ മുകളിലെത്തിയാൽ, അവസാന ഘട്ടം സാധാരണയായി ബുക്ക്മാർക്കിൽ ഒട്ടിക്കുന്ന വിലാസത്തിന് പകരം പ്രവർത്തിക്കുന്ന ഒരു പേരാണ്. dnsmasq ഹോസ്റ്റ് റെക്കോർഡും ക്ലയന്റിന് എത്താവുന്ന resolver വിലാസവും രണ്ട് ഫയലുകളിൽ multicast ഇല്ലാതെ അത് ചെയ്യുന്നു. യഥാർത്ഥത്തിൽ ചിന്തിക്കേണ്ട തീരുമാനം കൂടുതൽ ഇടുങ്ങിയതാണ്: ക്ലയന്റ് എല്ലാ DNS-ഉം വീട്ടിലെ resolver വഴി അയയ്ക്കുന്നുണ്ടോ, അതോ home.arpa-ന് കീഴിലുള്ള പേരുകൾ മാത്രമോ? താഴെയുള്ള എല്ലാം Linux ക്ലയന്റും വീട്ടിലെ അഡ്മിൻ ഇതിനകം കൈകാര്യം ചെയ്യുന്ന ലാബ് resolver-ഉം ഉള്ള അംഗീകൃത WireGuard ക്രമീകരണം അനുമാനിക്കുന്നു.
ക്ലയന്റിന് resolver നൽകാനുള്ള മൂന്ന് വഴികൾ
| Approach | Scope | Cost |
|---|---|---|
DNS = in the wg-quick interface | the client's general DNS while the tunnel is up | every name in the house now depends on the tunnel |
Platform split-DNS for home.arpa | only that suffix | more configuration per client platform |
Manual dig @resolver | one query at a time | fine for testing, useless for applications |
ഇടയ്ക്കിടെ ടണലിൽ ചേരുന്ന ലാപ്ടോപ്പിന് split-DNS മികച്ച സ്ഥിരസ്ഥിതിയാണ്: സാധാരണ ഇന്റർനെറ്റ് പേരുകൾ യന്ത്രം ഇതിനകം വിശ്വസിക്കുന്ന resolver-ൽ തന്നെ നിലനിർത്തുന്നു. വീട്ടിലെ സേവനങ്ങളിൽ എത്താൻ വേണ്ടി മാത്രമുള്ള യന്ത്രത്തിന് resolver പുഷ് ചെയ്യുന്നത് ലളിതമാണ്, പരിധിയുടെ ചെലവ് പ്രശ്നമല്ല.
സോൺ സ്വന്തമാക്കിയ resolver-ൽ റെക്കോർഡ് പ്രസിദ്ധീകരിക്കുക
കോൺഫിഗറേഷൻ എഴുതുന്നതിന് മുമ്പ് റോളുകൾ വേർതിരിക്കുക: VPN ക്ലയന്റ് വിലാസം, resolver, സേവനം എന്നിവ മൂന്ന് വ്യത്യസ്ത ജോലികളുള്ള മൂന്ന് വ്യത്യസ്ത ഹോസ്റ്റുകൾ ആണ്. ഈ ലാബിൽ അവ ക്ലയന്റിന് 10.77.0.2, dnsmasq-ന് 192.168.50.53, NAS-ന് 192.168.50.20 എന്നിവയാണ്, ടണൽ വീട്ടിലെ LAN റൂട്ട് ചെയ്യുന്നു.
listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20host-record വരി വിലാസം നൽകുന്നു, local= വരി അജ്ഞാതമായ home.arpa ചോദ്യങ്ങൾ മുകളിലേക്ക് അയയ്ക്കുന്നതിന് പകരം ഈ resolver-നുള്ളിൽ നിർത്തുന്നു. ആദ്യം നിങ്ങളുടെ നിലവിലുള്ള കോൺഫിഗറേഷൻ വായിച്ച്, സർവർ, ഇന്റർഫേസ് അല്ലെങ്കിൽ അതേ ലോക്കൽ ഡൊമെയ്ൻ ഇതിനകം നിർവചിക്കുന്ന എല്ലാം ഒത്തുചേർക്കുക; വൈരുദ്ധ്യമുള്ളതിന് മേൽ ഒരു ഭാഗം കൂട്ടിച്ചേർത്താൽ സന്തോഷത്തോടെ ലോഡ് ചെയ്ത് തെറ്റായി ഉത്തരം നൽകുന്ന resolver ഉണ്ടാകും. dnsmasq കൈപ്പുസ്തകം രണ്ട് നിർദ്ദേശങ്ങളും ശ്രവണ നിയന്ത്രണങ്ങളും നിർവചിക്കുന്നു.
തുടർന്ന് ഫയലല്ല, പ്രവർത്തിക്കുന്ന സേവനം പരിശോധിക്കുക. കോൺഫിഗറേഷൻ പരിശോധനയും പുനരാരംഭവും കുറഞ്ഞതാണ്, യഥാർത്ഥ ഉത്തരം അന്വേഷണം തിരികെ നൽകുന്നതാണ്.
resolver റൂട്ട് ചെയ്യുക, വെബ് പേജ് മാത്രമല്ല
WireGuard-ന്റെ AllowedIPs ഏത് ലക്ഷ്യസ്ഥാനങ്ങൾ ടണലിൽ പ്രവേശിക്കുന്നു എന്ന് തീരുമാനിക്കുന്നു. resolver വിലാസം അതിന് പുറത്ത് വീണാൽ, അന്വേഷണം സാധാരണ പാതയിലൂടെ പുറത്തുപോകുകയും dnsmasq-ൽ എത്താതിരിക്കുകയും ചെയ്യും, NAS തന്നെ ലഭ്യമാണെങ്കിലും. resolver-ന്റെ വിലാസമോ അത് ഉൾക്കൊള്ളുന്ന LAN പ്രിഫിക്സോ ഉൾപ്പെടുത്തുക, മറുവശത്തെ ഗേറ്റ്വേയുടെ ഫോർവേഡിംഗ് നയം പരിശോധിക്കുക.
അധികാരമുള്ള ടണൽ ശ്രേണിയിൽ നിന്ന് പോർട്ട് 53-ൽ UDP-ഉം TCP-യും അനുവദിക്കുക, ക്ലയന്റിന്റെ ടണൽ വിലാസത്തിലേക്ക് തിരിച്ചുള്ള പാതയോടെ. പരിശോധന എളുപ്പമാക്കാൻ WAN-ൽ നിന്ന് പോർട്ട് 53 ഫോർവേഡ് ചെയ്യരുത്: വീട്ടിലെ കണക്ഷനിൽ തുറന്ന റിക്കർസീവ് resolver മണിക്കൂറുകൾക്കുള്ളിൽ കണ്ടെത്തപ്പെടും. ഇന്റർഫേസിൽ ബന്ധിക്കുന്നത് അതിൽത്തന്നെ ഒരു ആക്സസ് നയമല്ല.
ആപ്ലിക്കേഷന് മുമ്പ് ഉത്തരം പരിശോധിക്കുക
ആദ്യം resolver-നോട് നേരിട്ട് ചോദിക്കുക, പിന്നെ സിസ്റ്റത്തോട്, പിന്നെ ആപ്ലിക്കേഷനോട്. ഓരോ ഘട്ടവും ശൃംഖലയിലെ ഒരു കണ്ണി വേർതിരിക്കുന്നു, അവ തമ്മിലുള്ള വ്യത്യാസമാണ് രോഗനിർണയം.
dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'TCP അന്വേഷണം പ്രവർത്തിപ്പിക്കുന്നത് മൂല്യവത്താണ്, കാരണം മുറിഞ്ഞ UDP ഉത്തരം വീണ്ടും ശ്രമിക്കാൻ നിർബന്ധിക്കുന്നു, TCP 53 ഉപേക്ഷിക്കുന്ന നയം ഇടയ്ക്കിടെയുള്ളതായി തോന്നുന്ന പരാജയങ്ങൾ സൃഷ്ടിക്കുന്നു. getent ഘട്ടം യന്ത്രത്തിന്റെ resolver കോൺഫിഗറേഷൻ യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു എന്ന് കാണിക്കുന്നു, അത് നിങ്ങൾ അയച്ചത് തന്നെയായിരിക്കണമെന്നില്ല.
ടണൽ താഴെയായിരിക്കുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് തീരുമാനിക്കുക
ക്ലയന്റിന്റെ പൊതു DNS 192.168.50.53-ലേക്ക് ചൂണ്ടുന്നുവെങ്കിൽ, ടണൽ മുകളിലില്ലാത്തപ്പോൾ എല്ലാ പേര് നിർണ്ണയവും നിലയ്ക്കും. ടണലിനൊപ്പം മാത്രം ഉപയോഗപ്രദമായ യന്ത്രത്തിൽ ഇത് സ്വീകാര്യമാണ്, കഫേയുടെ Wi-Fi-ഉം ഉപയോഗിക്കുന്ന ലാപ്ടോപ്പിൽ സ്വീകാര്യമല്ല. Split-DNS ഈ ചോദ്യം പൂർണ്ണമായി ഒഴിവാക്കുന്നു, കാരണം home.arpa തിരച്ചിലുകൾ മാത്രമാണ് വീട്ടിലെ resolver-നെ ആശ്രയിക്കുന്നത്.
പേര് എന്താണെന്ന് ഓർക്കുക: home.arpa താമസ നെറ്റ്വർക്കുകൾക്കായി സംവരണം ചെയ്തതാണ്, ആഗോളതലത്തിൽ അതുല്യമല്ല, അതിനാൽ മറ്റൊരു നെറ്റ്വർക്കിന് അതേ പേര് നിയമാനുസൃതമായി ഉപയോഗിക്കാം. ഇത് പ്രാദേശിക സൗകര്യമാണ്, വിശ്വസനീയമായ ഐഡന്റിഫയർ അല്ല. സേവനം മാറുമ്പോൾ റെക്കോർഡ് കാലികമായി സൂക്ഷിക്കുക, ലാബ് ഒഴിവാക്കുമ്പോൾ resolver നയം നീക്കം ചെയ്യുക, ഇനി നിലവിലില്ലാത്ത ടണലിലൂടെ മാത്രം എത്താവുന്ന ഒരു വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന ലാപ്ടോപ്പ് വിട്ടേക്കരുത്.