നിങ്ങളുടെ DNS നാമം ഇപ്പോൾ ഒരു VPN ദാതാവിന്റെ വിലാസത്തിലേക്ക് പരിഹരിക്കുന്നു, കൂടാതെ അപ്ഡേറ്റ് ലോഗ് പൂർണ്ണമായും ആരോഗ്യകരമായി കാണുന്നു. ഈ സംയോജനം സാധാരണമാണ്. വെബ് അധിഷ്ഠിത കണ്ടെത്തൽ പ്രോബ് ഒരു ബാഹ്യ സേവനത്തോട് താൻ ഏത് ഉറവിടമാണ് കാണുന്നതെന്ന് ചോദിക്കുന്നു, അഭ്യർത്ഥന പൂർണ ടണൽ VPN വഴി പുറത്തുപോകുമ്പോൾ, ഉത്തരം VPN എക്സിറ്റ് ആണ്, നിങ്ങളുടെ വീട്ടിലെ WAN വിലാസമല്ല. അപ്ഡേറ്റർ തന്റെ ജോലി ചെയ്തു; ജോലി തെറ്റായ നിരീക്ഷണത്തിലേക്കാണ് തിരിച്ചിരുന്നത്.

നാമം എന്തിലേക്ക് എത്തണമെന്ന് സ്ഥിരീകരിക്കുക

ഇൻബൗണ്ട് വീട്ടു സേവനത്തിന് പൊതു നാമത്തിന് അംഗീകൃത ഇൻബൗണ്ട് കണക്ഷനുകൾക്ക് ആ സേവനത്തിലേക്ക് എത്താൻ കഴിയുന്ന ഒരു വിലാസം വേണം. പങ്കിട്ട ദാതാവ് എക്സിറ്റ് പ്രസിദ്ധീകരിക്കുന്നത് അവിടെ ഇൻബൗണ്ട് ഫോർവേഡിംഗ് ഒരുക്കുന്നില്ല, ഒരു DNS കോൺഫിഗറേഷനും ആ ഫോർവേഡിംഗ് സൃഷ്ടിക്കുന്നില്ല. അപ്ഡേറ്ററിനെ സ്പർശിക്കുന്നതിന് മുമ്പ് ഇത് തീരുമാനിക്കുക, കാരണം ഏത് വിലാസമാണ് ശരിയെന്ന് ഇത് നിർണ്ണയിക്കുന്നു.

VPN ക്ലയന്റിന്റെ ടണൽ വിലാസത്തിനുള്ള സ്വകാര്യ നാമം വേറെ ഉത്തരമുള്ള വേറെ പ്രശ്നമാണ്: അത് സ്വകാര്യ DNS-ൽ ഉൾപ്പെടുന്നു, പൊതു കണ്ടെത്തൽ സേവനം ഒട്ടും ആവശ്യമില്ല. രണ്ട് ആവശ്യകതകൾ കൂട്ടിക്കലർത്തുന്നതാണ് പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷൻ ആരും ആവശ്യപ്പെടാത്ത ഒരു വിലാസം പ്രസിദ്ധീകരിക്കാൻ തുടങ്ങുന്ന വഴി.

ഇന്റർഫേസ് വിലാസങ്ങൾക്കും വ്യാഖ്യാനം വേണം. വീട്ടിലെ റൗട്ടറിന് പിന്നിലുള്ള ലാപ്ടോപ്പിന്റെ വിലാസം പൊതു WAN വിലാസമല്ല, റൗട്ടറിന്റെ WAN വിലാസം പോലും കാരിയർ-ഗ്രേഡ് NAT-ന് പിന്നിലായിരിക്കാം, അവിടെ അത് പ്രസിദ്ധീകരിച്ചാൽ ഇൻബൗണ്ട് എത്തിച്ചേരൽ ഉണ്ടാകില്ല.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് മൂല്യം പുനർനിർമ്മിക്കുക

രണ്ട് പാതകളും വെവ്വേറെ നിരീക്ഷിക്കുക. ടണൽ ഉയർത്തിയിരിക്കുമ്പോൾ പ്രോബ് എക്സിറ്റ് റിപ്പോർട്ട് ചെയ്യുന്നു; ടണൽ താഴ്ത്തിയിരിക്കുമ്പോൾ, അല്ലെങ്കിൽ പ്രോബ് ഭൗതിക ഇന്റർഫേസിൽ ബന്ധിച്ചിരിക്കുമ്പോൾ, അത് വീട്ടിലെ വിലാസം റിപ്പോർട്ട് ചെയ്യുന്നു: curl --interface eth0 https://ifconfig.me. ആ രണ്ട് ഉത്തരങ്ങൾ വ്യത്യസ്തമാണെങ്കിൽ, അപ്ഡേറ്ററിനെ സ്പർശിക്കാതെ തന്നെ നിങ്ങൾ തകരാർ പുനർനിർമ്മിച്ചിരിക്കുന്നു.

പിന്നീട് അപ്ഡേറ്റ് ചെയ്യാതെ കോൺഫിഗറേഷൻ പരിശോധിക്കുന്ന മോഡിൽ ക്ലയന്റ് പ്രവർത്തിപ്പിക്കുക, ഉദാഹരണത്തിന് ddclient -verbose -noexec, കൂടാതെ അത് ഏത് കണ്ടെത്തൽ രീതി തിരഞ്ഞെടുത്തുവെന്ന് വായിക്കുക. വിശദമായ ഔട്ട്പുട്ട് രീതിയും ലഭിച്ച മൂല്യവും പറയുന്നു, എന്തെങ്കിലും എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് നിങ്ങൾക്ക് വേണ്ട വസ്തുത അതാണ്.

കണ്ടെത്തൽ തിരഞ്ഞെടുത്ത പാതയിലേക്ക് നയിക്കുക

നാമം വീട്ടിലെ WAN വിലാസം പ്രസിദ്ധീകരിക്കേണ്ടതുണ്ടെങ്കിൽ, കണ്ടെത്തൽ ആ വിലാസം തന്നെ നിരീക്ഷിക്കണം. ഏകദേശ മുൻഗണനാ ക്രമത്തിൽ മൂന്ന് ഓപ്ഷനുകൾ പ്രവർത്തിക്കുന്നു: റൗട്ടർ അതിന്റെ സ്വന്തം പിന്തുണയുള്ള അപ്ഡേറ്റർ വഴി പ്രസിദ്ധീകരിക്കട്ടെ; റൗട്ടർ യഥാർത്ഥത്തിൽ നൽകുന്ന പേജിനെതിരെ ddclient-ന്റെ റൗട്ടർ-സ്റ്റാറ്റസ് കണ്ടെത്തൽ ഉപയോഗിക്കുക; അല്ലെങ്കിൽ വെബ് പ്രോബ് നിലനിർത്തുക പക്ഷേ ടണലിന് പുറത്തുപോകാൻ അത് ഭൗതിക ഇന്റർഫേസിൽ ബന്ധിക്കുക.

റൗട്ടർ-സ്റ്റാറ്റസ് പാതയ്ക്ക്, പുതിയ ddclient റിലീസുകൾ usev4, fwv4 എന്ന ഓപ്ഷൻ കുടുംബം ഉപയോഗിക്കുന്നു, പേജിന് ചുറ്റുമുള്ള വാചകത്തിന് ഐച്ഛിക സ്കിപ്പ് പാറ്റേണും. നിങ്ങളുടെ ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പിന്റെ README പരിശോധിക്കുക, കാരണം പഴയ റിലീസുകൾ അതേ ആശയം use, fw ഉപയോഗിച്ച് എഴുതുന്നു, തെറ്റായ റിലീസിൽ നിന്ന് പകർത്തിയ ഓപ്ഷൻ പേര് സ്റ്റാർട്ടപ്പിൽ പരാജയപ്പെടുന്നു.

നിങ്ങൾ വെബ് കണ്ടെത്തൽ നിലനിർത്തുന്നുവെങ്കിൽ, പ്രോബിന്റെ റൂട്ടിംഗും അപ്ഡേറ്റ് API കോളിന്റെ റൂട്ടിംഗും വേറിട്ട തീരുമാനങ്ങളാണെന്ന് ഓർക്കുക. അപ്ഡേറ്റ് കോൾ റെക്കോർഡ് എത്തിക്കുന്നു; ഏത് മൂല്യം എത്തിക്കണമെന്ന് പ്രോബ് തീരുമാനിക്കുന്നു.

രഹസ്യങ്ങളും പതിപ്പുകളും ക്രമത്തിൽ സൂക്ഷിക്കുക

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

ddclient README കണ്ടെത്തൽ സമീപനങ്ങളും അവയുടെ ഓപ്ഷൻ പേരുകളും രേഖപ്പെടുത്തുന്നു. ഒരേ റെക്കോർഡിൽ IPv4, IPv6 ഫലങ്ങൾ കലർത്തരുത്, ഒരു റിലീസിലുള്ള ഓപ്ഷൻ മറ്റൊന്നിലും ഉണ്ടെന്ന് അനുമാനിക്കരുത്.

മൂല്യം പരിശോധിക്കുക, പിന്നീട് എത്തിച്ചേരൽ

ലൈവ് അപ്ഡേറ്റ് അനുവദിക്കുന്നതിന് മുമ്പ് നിർദ്ദേശിച്ച വിലാസം ഉദ്ദേശിച്ച അന്ത്യബിന്ദുവുമായി താരതമ്യം ചെയ്യുക, പിന്നീട് ഒരു അംഗീകൃത അപ്ഡേറ്റിന് ശേഷം അധികാരമുള്ള DNS പരിശോധിക്കുകയും റിസോൾവർ കാഷുകൾ കണക്കിലെടുക്കുകയും ചെയ്യുക. കുറഞ്ഞ TTL കാത്തിരിപ്പ് ചുരുക്കുന്നു; തെറ്റായ മൂല്യത്തെ ശരിയാക്കുന്നില്ല.

റെക്കോർഡ് ശരിയായതിന് ശേഷം മാത്രമേ, ആവശ്യമായ ഫയർവാളും ഫോർവേഡിംഗും മുൻകൂട്ടി അംഗീകരിച്ചിരിക്കുമ്പോൾ, സ്വതന്ത്ര നെറ്റ്വർക്കിൽ നിന്ന് ഇൻബൗണ്ട് സേവനം പരീക്ഷിക്കാവൂ. ശരിയായ A റെക്കോർഡ് എത്തിച്ചേരാവുന്ന സേവനം തെളിയിക്കുന്നില്ല, സ്ഥിര VPN പാട്ടം സ്വകാര്യ നാമകരണം ലളിതമാക്കിയേക്കാം, പക്ഷേ തെറ്റായ WAN-ലേക്ക് ചൂണ്ടുന്ന പൊതു ഹോസ്റ്റ്നെയിം ശരിയാക്കുന്നില്ല.

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