ടണൽ ഓണാണ്, പക്ഷേ സ്വകാര്യ നാമം ഇപ്പോഴും പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്?

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

ഏത് റിസോൾവറിലാണ് അഭ്യർത്ഥന എത്തിയത്?

ടണൽ നോക്കുന്നതിന് മുമ്പ് ഓരോ ലിങ്കിനോടും ബന്ധിപ്പിച്ച റിസോൾവർ കണ്ടെത്തുക. Linux റിസോൾവർ സ്റ്റാറ്റസ് കമാൻഡിലൂടെ ഓരോ ലിങ്കിന്റെയും സെർവറുകൾ കാണിക്കുന്നു, macOS അതിന്റെ DNS കോൺഫിഗറേഷൻ ഡംപ്പിൽ സ്കോപ്പ് ചെയ്ത റിസോൾവറുകൾ കാണിക്കുന്നു. ഉത്തരം ഇപ്പോഴും വീട്ടിലെ റൂട്ടറിൽ നിന്നാണ് വരുന്നതെങ്കിൽ, ടണൽ ലിങ്ക് ഒരിക്കലും പരിശോധിച്ചിട്ടില്ല.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

ഇവിടെ രണ്ട് ഘട്ടങ്ങൾ കലരുന്നു: റിസോൾവർ വിലാസം തള്ളുന്ന സെർവറും അത് സജീവ ലിങ്കിൽ ഇൻസ്റ്റാൾ ചെയ്യുന്ന ക്ലയന്റും. പ്രൊഫൈലിൽ ഓപ്ഷൻ ഉണ്ടാകാം, ലോഗ് അത് വരുന്നതായി കാണിക്കാം, എന്നാൽ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം പഴയ സെർവർ തുടർന്നും ഉപയോഗിക്കുന്നു. ലോഗിനെ ലിങ്ക് റിപ്പോർട്ട് ചെയ്യുന്നതുമായി താരതമ്യം ചെയ്ത്, ലിങ്കിനെ വിശ്വസിക്കുക.

ക്ലൗഡ് നെറ്റ്വർക്ക് ശരിക്കും ഉത്തരം നൽകുന്ന വിലാസം ഉപയോഗിക്കുക

ക്ലൗഡ് നെറ്റ്വർക്കുകൾ സാധാരണയായി ശ്രേണിയുടെ അടിത്തറയിൽ നിന്ന് രണ്ട് സ്ഥാനം മാറിയ സംരക്ഷിത വിലാസത്തിലൂടെ സ്വകാര്യ നാമങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, അതിനാൽ 10.0.0.0 ൽ തുടങ്ങുന്ന നെറ്റ്വർക്ക് 10.0.0.2 ൽ ഉത്തരം നൽകുന്നു. ചില ദാതാക്കൾ ശ്രേണി അറിയാതെ പ്രവർത്തിക്കുന്ന ലിങ്ക്-ലോക്കൽ റിസോൾവറും പ്രസിദ്ധീകരിക്കുന്നു, നെറ്റ്വർക്ക് മറ്റാരെങ്കിലും നിർമ്മിച്ചപ്പോൾ ഇത് സഹായിക്കുന്നു. സ്ഥാനാർത്ഥി വിലാസം ആർക്കെങ്കിലും നൽകുന്നതിന് മുമ്പ് നേരിട്ട് ചോദിക്കുക. റിസോൾവറല്ലാത്ത വിലാസം ഫയർവാൾ ഡ്രോപ്പ് പോലെ തന്നെ കാണുന്നു, കാരണം അഭ്യർത്ഥന ഒരിക്കലും ഉത്തരം ലഭിക്കുന്നില്ല.

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

ടണൽ നാമസ്ഥലം വഹിക്കുന്നില്ല

പാക്കറ്റുകൾ കടക്കുന്നു; പേരുകൾ കടക്കുന്നില്ല. ഏത് നാമസ്ഥലം മറുവശത്തിനുള്ളതാണെന്ന് ഓരോ വശത്തിനും പറയണം, അത് സോൺ കൈവശമുള്ളവന്റെ ഉടമസ്ഥതയിലുള്ള വേറിട്ട വസ്തുവാണ്. സാധാരണ രൂപം ഒരു നാമസ്ഥലത്തിനുള്ള ഫോർവേർഡ് ആണ്, ടണലിലൂടെ എത്താവുന്ന റിസോൾവറിലേക്ക് ചൂണ്ടുന്നത്.

പ്രായോഗികമായി ഓരോ ദിശയ്ക്കും സ്വന്തം നിയമം വേണം, കാരണം സോൺ ഉള്ള വശമാണ് അഭ്യർത്ഥന അയക്കേണ്ടത്. രണ്ട് ദിശകൾക്കും അഭ്യർത്ഥനയുടെ ഉറവിടം റൂട്ട് ചെയ്ത് അനുവദിക്കണം, ഉത്തരം നൽകുന്ന വശം ഉത്തരങ്ങൾ ഇന്റർനെറ്റിലേക്കല്ല, ടണലിലൂടെ തിരികെ അയക്കണം. ഫോർവേർഡിംഗ് ഇടുങ്ങിയതായി സൂക്ഷിക്കുക, സ്വകാര്യ നാമസ്ഥലം മാത്രം ലിങ്കിനെ ആശ്രയിക്കുന്നതിന്. ഓരോ അഭ്യർത്ഥനയും അതിലൂടെ അയക്കുന്നത് ചെറിയ ആശ്രയത്വത്തെ ടണൽ വീഴുന്ന നിമിഷത്തിൽ പൂർണ തടസ്സമാക്കി മാറ്റുന്നു.

അതിരുകൾ ക്രമത്തിൽ കടക്കുക

സജീവ ലിങ്കിൽ ഇൻസ്റ്റാൾ ചെയ്ത റിസോൾവർ, തുടർന്ന് ആ റിസോൾവറിലേക്കുള്ള നേരിട്ടുള്ള അഭ്യർത്ഥന, തുടർന്ന് അതേ അഭ്യർത്ഥന അകലെയുള്ള വശത്തുനിന്ന്, ഒടുവിൽ അതേ നാമം ഉപയോഗിക്കുന്ന അപ്ലിക്കേഷൻ എന്നിവ പരീക്ഷിക്കുക. ഓരോ ഘട്ടവും ഒരു അതിർത്തിയെ വേർതിരിക്കുന്നു, അതിനാൽ പരാജയം അന്വേഷണം വീണ്ടും തുടങ്ങുന്നതിനുപകരം എവിടെ നോക്കണമെന്ന് പറയുന്നു. അപ്ലിക്കേഷൻ പരാജയപ്പെടുമ്പോൾ പ്രവർത്തിക്കുന്ന ഉത്തരം DNS-നെക്കാൾ സർട്ടിഫിക്കറ്റ് വിശ്വാസത്തെയോ API നയത്തെയോ സൂചിപ്പിക്കുന്നു. ആ തകരാറുകൾ യഥാർത്ഥമാണ്, ഒരു റിസോൾവർ മാറ്റവും അവ പരിഹരിക്കില്ല.

ഏത് ഘട്ടമാണ് പരാജയപ്പെട്ടതെന്ന് എഴുതുക. ആ ഒരു വരിയാണ് അടുത്ത വ്യക്തിക്ക് വേണ്ടത്, അത് രേഖപ്പെടുത്താൻ പത്ത് സെക്കൻഡ് മതി.

അടുത്ത വ്യക്തിക്ക് കണ്ടെത്താവുന്നിടത്ത് ശൃംഖല സൂക്ഷിക്കുക

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

രേഖ കൃത്യമായി തുടരാൻ ആവശ്യമായത്ര ചെറുതായി സൂക്ഷിക്കുക: നാല് വരി, ഒരു തീയതി, ഓരോ ഭാഗത്തിന്റെ ഉടമയുടെ പേര്. പഴയ രേഖ ഇല്ലാത്തതിനേക്കാൾ മോശമാണ്, കാരണം അത് തെറ്റായിരിക്കുമ്പോഴും അധികാരമുള്ളതായി തോന്നുന്നു.