VPN എൻഡ്‌പോയിന്റ് പേരും സ്വകാര്യ സേവനത്തിന്റെ പേരും: രണ്ട് ഉടമകൾ

രണ്ട് പേരുകൾക്ക് ഒരേ ശാഖയെ വിവരിക്കാനും തികച്ചും വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകാനും കഴിയും. ദൂരെയുള്ള പങ്കാളിക്ക് VPN എൻഡ്‌പോയിന്റ് എവിടെ കണ്ടെത്താമെന്ന് vpn.branch.example പറയുന്നു, ഏതെങ്കിലും ടണൽ നിലവിൽ വരുന്നതിന് മുമ്പ് അത് റിസോൾവ് ചെയ്യണം. അധികാരമുള്ള ഉപയോക്താവിന് സ്വകാര്യ ആപ്ലിക്കേഷൻ എവിടെയാണെന്ന് inventory.branch.example പറയുന്നു, ടണൽ ഉയർന്നതിന് ശേഷം മാത്രമേ അതിന് പ്രസക്തിയുള്ളൂ. ഒന്ന് പരിപാലിക്കുന്നത് മറ്റൊന്നിന് ഒന്നും ചെയ്യുന്നില്ല.

ഏതെങ്കിലും ഒന്ന് ഡീബഗ് ചെയ്യുന്നതിന് മുമ്പ് രണ്ട് റെക്കോർഡുകൾക്കും പേര് നൽകുക

രണ്ടും അവയുടെ ഉടമകളോടൊപ്പം എഴുതിവയ്ക്കുക. എൻഡ്‌പോയിന്റിന്, പൊതു വിലാസം ആരാണ് അപ്‌ഡേറ്റ് ചെയ്യുന്നതെന്നും VPN ക്ലയന്റ് തന്റെ ഉത്തരം എങ്ങനെ പുതുക്കുന്നുവെന്നും രേഖപ്പെടുത്തുക. സേവനത്തിന്, സ്വകാര്യ വിലാസത്തിന്റെ ഉടമ ആരാണെന്നും ഏത് സോൺ റെക്കോർഡ് സൂക്ഷിക്കുന്നുവെന്നും ഏത് റിസോൾവറുകൾ അതിന് ഉത്തരം നൽകണമെന്നും രേഖപ്പെടുത്തുക.

ഈ ചെറിയ പട്ടിക ഈ മേഖലയിലെ ഏറ്റവും സാധാരണമായ തെറ്റായ നിർണ്ണയം തടയുന്നു: പൂർണ്ണമായും അതിനുള്ളിൽ മാത്രം നിലനിൽക്കുന്ന ഒരു റെക്കോർഡ് നന്നാക്കാൻ പ്രവർത്തിക്കുന്ന ശാഖാ ടണൽ പുനരാരംഭിക്കുന്നത്. ടണൽ സേവനത്തിന്റെ പേരിനുള്ള ഗതാഗതമാണ്; അത് അതിന്റെ അധികാരമല്ല.

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

ഏതെങ്കിലും ടണൽ നിലവിൽ വരുന്നതിന് മുമ്പ് എൻഡ്‌പോയിന്റ് റിസോൾവ് ചെയ്യണം

ശാഖയുടെ ഇന്റർനെറ്റ് കണക്ഷന് പുതിയ പൊതു വിലാസം ലഭിച്ചുവെന്ന് കരുതുക. എൻഡ്‌പോയിന്റ് അപ്‌ഡേറ്റർ പുതിയ വിലാസം പ്രസിദ്ധീകരിക്കുന്നു, ദൂരെയുള്ള VPN നടപ്പാക്കൽ മാറിയ ഉത്തരം വായിക്കാൻ കഴിയണം. ഏത് റിസോൾവർ ആ ഉത്തരം നൽകിയാലും അത് ടണൽ ഇല്ലാതെ എത്താവുന്നതായിരിക്കണം, അല്ലെങ്കിൽ കണ്ടെത്താൻ കഴിയാത്തതുമായി ബന്ധിപ്പിച്ചതിന് ശേഷം മാത്രം റിസോൾവ് ചെയ്യാവുന്ന ഒരു പേരിനെ ക്ലയന്റ് പിന്തുടരുന്നു.

ഈ ബൂട്ട്‌സ്ട്രാപ്പ് ആശ്രിതത്വം വ്യക്തമായി പറയേണ്ടതാണ്, കാരണം എല്ലാ ആന്തരിക റിസോൾവറുകളും VPN-ന് പിന്നിലായാൽ അത് അബദ്ധത്തിൽ സൃഷ്ടിക്കാൻ എളുപ്പമാണ്. എൻഡ്‌പോയിന്റ് അന്വേഷണത്തിന് ടണലിന് മുമ്പുള്ള ഒരു പാത സൂക്ഷിക്കുക, പുതിയ ഉത്തരം ഉടൻ സ്വീകരിക്കുമെന്ന് അനുമാനിക്കുന്നതിന് പകരം ക്ലയന്റിന്റെ പുനഃബന്ധന സ്വഭാവം സ്ഥിരീകരിക്കുക.

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

അവസാനം, പ്രവർത്തിക്കുന്ന ക്ലയന്റ് വീണ്ടും ബന്ധിപ്പിക്കുന്നതുവരെ കാഷെ ചെയ്ത എൻഡ്‌പോയിന്റ് ഉപയോഗിക്കുന്നത് തുടരാം. നിങ്ങളുടെ കുറിപ്പുകളിൽ പ്രസിദ്ധീകരണം, കാഷെ, പുനഃബന്ധന നയം എന്നിവ വേർതിരിക്കുക, പഴയ പങ്കാളിയെ കേടായ അപ്‌ഡേറ്ററായി തെറ്റിദ്ധരിക്കാതിരിക്കാൻ.

സേവനത്തിന്റെ പേര് ആപ്ലിക്കേഷൻ എവിടെയാണെന്ന് വിവരിക്കുന്നു

ഇപ്പോൾ ടണൽ ആരോഗ്യകരമായി തുടരുന്നു, പക്ഷേ ഇൻവെന്ററി സെർവർ 172.26.14.20 ൽ നിന്ന് 172.26.14.35 ലേക്ക് മാറുന്നു എന്ന് കരുതുക. പൊതു എൻഡ്‌പോയിന്റ് റെക്കോർഡ് ബാധിക്കപ്പെടുന്നില്ല, അതേസമയം സ്വകാര്യ സേവന റെക്കോർഡ് മാറണം. ആ സേവനത്തിനായി സംവരണം ചെയ്ത വിലാസമോ സ്ഥിരമായ അനുവദനമോ ഉപയോഗിക്കുന്നത് ഇത് അപൂർവ്വമാക്കുന്നു; അധികാരമുള്ള അപ്‌ഡേറ്റ് പാത അത് ഉദ്ദേശ്യപൂർവ്വമായ സന്ദർഭങ്ങൾ കൈകാര്യം ചെയ്യുന്നു.

ഇവിടെ രണ്ട് അപ്‌ഡേറ്റ് സംവിധാനങ്ങൾ കൂടിക്കലരുന്നു. RFC 2136 ഒരു സോണിൽ DNS റെക്കോർഡുകൾ ചേർക്കാനും ഇല്ലാതാക്കാനുമുള്ള പ്രോട്ടോക്കോൾ നിർവചിക്കുന്നു, അതേസമയം വാണിജ്യ ഡൈനാമിക് DNS ദാതാവ് മറ്റൊരു ആവശ്യത്തിനായി തികച്ചും വ്യത്യസ്തമായ HTTP API നൽകിയേക്കാം. ഒന്ന് ഉപയോഗിക്കുന്നത് മറ്റൊന്ന് നിങ്ങളുടെ പരിസ്ഥിതിയിൽ ഉണ്ടെന്ന് അർത്ഥമാക്കുന്നില്ല. അതിനെതിരെ അപ്‌ഡേറ്റർ എഴുതുന്നതിന് മുമ്പ് നിങ്ങളുടെ സോൺ യഥാർത്ഥത്തിൽ ഏത് സംവിധാനം സ്വീകരിക്കുന്നുവെന്ന് പരിശോധിക്കുക.

ശരിയായ സ്വകാര്യ ഉത്തരം ആദ്യ വ്യവസ്ഥ മാത്രമാണ്. ദൂരെയുള്ള വിളിക്കുന്നയാൾക്ക് അത് ഉപയോഗിക്കാൻ, ക്ലയന്റിന് സ്വകാര്യ സോൺ വഹിക്കുന്ന റിസോൾവർ, ആ റിസോൾവറിലേക്കുള്ള ചോദ്യങ്ങൾ അനുവദിക്കുന്ന നയം, തിരികെ വരുന്ന വിലാസത്തിനുള്ള ഫോർവേഡിംഗ് എന്നിവ വേണം. ക്ലയന്റിന് എത്താൻ കഴിയാത്ത വിലാസത്തിലേക്ക് റിസോൾവ് ചെയ്യുന്ന പേര് സെർവർ തകരാറിനോട് സാമ്യമുള്ള ഒരു ടൈംഔട്ട് സൃഷ്ടിക്കുന്നു.

രണ്ട് പാതകളും വെവ്വേറെ പരിശോധിക്കുക

ടണലിന് പുറത്തുനിന്ന് എൻഡ്‌പോയിന്റും അതിനുള്ളിൽ നിന്ന് സേവനവും പരിശോധിച്ച്, ഫലങ്ങൾ രണ്ട് സ്വതന്ത്ര വസ്തുതകളായി സൂക്ഷിക്കുക:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

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

ഓരോ വിലാസ മാറ്റത്തിനും ശേഷം ജോടി പ്രവർത്തിപ്പിക്കുക, ഏത് റെക്കോർഡ് നീങ്ങിയെന്ന് കുറിക്കുക. «DNS അപ്‌ഡേറ്റ് ചെയ്തു» എന്ന് മാത്രം പറയുന്ന കൈമാറ്റം, രണ്ട് ജീവിതചക്രങ്ങളിൽ ഏതാണ് യഥാർത്ഥത്തിൽ നടന്നതെന്ന് അടുത്ത എൻജിനീയറെ ഊഹിക്കാൻ വിടുന്നു.