wg-quick കണക്ട് ചെയ്യുമ്പോൾ DNS തകരുന്നു: സെറ്റപ്പ് പിശക് വായിക്കുക
DNS വരി പിയർ പ്രോട്ടോക്കോളിന്റേതല്ല, സെറ്റപ്പ് സഹായിയുടേതാണ്. ആദ്യ പിശക് വായിക്കുക, റിസോൾവർ റൂട്ട് പരിശോധിക്കുക, ക്ലീനപ്പ് പഴയ അവസ്ഥ പുനഃസ്ഥാപിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക.
ടണൽ ഉയരുന്നു, ഹാൻഡ്ഷേക്ക് പൂർത്തിയാകുന്നു, പേര് വിശകലനം നിലയ്ക്കുന്നു. പിയർ കോൺഫിഗറേഷനിൽ ഒന്നും മാറിയിട്ടില്ല, കാരണം DNS വരി ഒരിക്കലും പിയർ കോൺഫിഗറേഷന്റെ ഭാഗമായിരുന്നില്ല. അത് സെറ്റപ്പ് സഹായിയുടേതാണ്, അതായത് പരാജയം WireGuard കീകളിലല്ല, ഹോസ്റ്റിന്റെ റിസോൾവർ ഉപകരണങ്ങളിലാണ് കഴിയുന്നത്.
സഹായി അച്ചടിച്ച ആദ്യ സന്ദേശം വായിക്കുക, അവസാനത്തേതല്ല, എന്നാൽ കാണാത്ത ഉപകരണവും എത്തിപ്പെടാനാവാത്ത സെർവറും തമ്മിലുള്ള വ്യത്യാസം വ്യക്തമാകും.
DNS വരി സഹായിയുടെ സവിശേഷതയാണ്
പ്രധാന കോൺഫിഗറേഷൻ ഫീൽഡുകൾ പിയറുകൾ, കീകൾ, അനുവദനീയമായ വിലാസങ്ങൾ എന്നിവ വിവരിക്കുന്നു. ഇന്റർഫേസ് ഉയർത്തുന്ന സ്ക്രിപ്റ്റ് മുകളിൽ നിന്ന് പേര് വിശകലനം ചേർക്കുന്നു, ഓരോ നടപ്പാക്കലും അത് വ്യത്യസ്തമായി ചെയ്യുന്നു. ഡെസ്ക്ടോപ്പ് ക്ലയന്റിന് സ്വന്തം സേവനത്തിലൂടെ DNS കൈകാര്യം ചെയ്യാം, ഡിസ്ട്രിബ്യൂഷൻ സ്ക്രിപ്റ്റിന് നിരവധി റിസോൾവർ ഉപകരണങ്ങളിൽ ഒന്ന് വിളിക്കാം, കണ്ടെയ്നർ രണ്ടും ചെയ്യണമെന്നില്ല. കോൺഫിഗറേഷൻ ഫയലിന് ഏത് പാതയാണ് പ്രവർത്തിക്കുന്നതെന്ന് പറയാനാവില്ല.
അതുകൊണ്ടാണ് ഒരു കോൺഫിഗറേഷൻ ഫയൽ പ്രോട്ടോക്കോളിന് സാധുവായിരുന്നിട്ടും സെറ്റപ്പിനിടയിൽ പരാജയപ്പെടാവുന്നത്: പരാജയം പ്രോട്ടോക്കോൾ ഒരിക്കലും കാണാത്ത ഒരു ഹൂക്കിന്റേതാണ്.
പ്രധാന കോൺഫിഗറേഷനിൽ ഒരു വിപുലീകൃത ഫീൽഡ് എഴുതി പ്രോട്ടോക്കോൾ ഉപകരണം അത് സ്വീകരിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നത് എതിർദിശയിൽ അതേ ആശയക്കുഴപ്പം സൃഷ്ടിക്കുന്നു. രണ്ട് പാഴ്സറുകളും വ്യത്യസ്ത ഫയലുകൾ വായിക്കുന്നു.
ഏതാണ് പ്രവർത്തിക്കുന്നതെന്ന് അറിയുന്നത് ആദ്യ ഡയഗ്നോസ്റ്റിക് ഘട്ടമാണ്, അത് സാധാരണയായി കോൺഫിഗറേഷൻ ഫയലിലല്ല, നിങ്ങൾ ടൈപ്പ് ചെയ്ത കമാന്റിൽ കാണാം.
സഹായി അച്ചടിക്കുന്ന ആദ്യ പിശക് വായിക്കുക
ഇന്റർഫേസ് മുൻഭാഗത്ത് ഉയർത്തി ഔട്ട്പുട്ട് ക്രമത്തിൽ വായിക്കുക. കാണാത്ത റിസോൾവർ ഉപകരണം, പരാജയപ്പെട്ട ഹൂക്ക്, എത്തിപ്പെടാനാവാത്ത സെർവർ എന്നിവ ഒരേ കമാന്റ് വ്യത്യസ്ത ബിന്ദുക്കളിൽ നിർത്തുന്നു, ഓരോന്നിനും വ്യത്യസ്ത പരിഹാരമുണ്ട്.
wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1
ആദ്യ കമാന്റ് സെറ്റപ്പിന്റെ പുരോഗതി അറിയിക്കുന്നു, രണ്ടാമത്തേത് ഇന്റർഫേസ് ഇപ്പോൾ ഏത് സെർവറുകൾ അവകാശപ്പെടുന്നു എന്ന് കാണിക്കുന്നു, മൂന്നാമത്തേത് റിസോൾവർ വിലാസം ടണലിലൂടെ യഥാർത്ഥത്തിൽ എത്തിപ്പെടാമോ എന്ന് കാണിക്കുന്നു. കോൺഫിഗർ ചെയ്തതെങ്കിലും റൂട്ട് ചെയ്യാനാവാത്ത റിസോൾവർ കോൺഫിഗറേഷൻ പിശകുകൾക്ക് പകരം സമയപരിധി ഉണ്ടാക്കുന്നു, അതുകൊണ്ടാണ് രണ്ട് പരിശോധനകളും ഒരുമിച്ച് വേണ്ടത്. സ്റ്റാറ്റസ് ഔട്ട്പുട്ട് മാത്രം വായിച്ചാൽ ആത്മവിശ്വാസമുള്ളതും തെറ്റായതുമായ നിഗമനം ലഭിക്കും.
സെറ്റപ്പ് പൂർത്തിയായിട്ടും പേര് വിശകലനം പരാജയപ്പെടുന്നെങ്കിൽ, സഹായി ഇൻസ്റ്റാൾ ചെയ്ത റിസോൾവറിനെ നെറ്റ്വർക്ക് മുമ്പ് ഉപയോഗിച്ചിരുന്നതുമായി താരതമ്യം ചെയ്യുക. സ്വകാര്യ റിസോൾവറിന് ടണലിലൂടെ റൂട്ട് വേണം, അതിന്റെ പ്രിഫിക്സ് മൂടാതെ അത് പട്ടികപ്പെടുത്തുന്ന കോൺഫിഗറേഷൻ ഓരോ ക്വറിയും കാത്തിരിക്കാൻ വിടുന്നു.
ഹോസ്റ്റിന് യഥാർത്ഥത്തിൽ ഏത് റിസോൾവറാണുള്ളത്
ആധുനിക Linux ഹോസ്റ്റുകൾ പലപ്പോഴും പ്രാദേശിക സ്റ്റബ് റിസോൾവർ പ്രവർത്തിപ്പിക്കുന്നു, അതിനാൽ സഹായി ഇൻസ്റ്റാൾ ചെയ്യുന്ന വിലാസം ആപ്ലിക്കേഷനുകൾ നേരിട്ടല്ല, ആ സ്റ്റബ് ഉപയോഗിക്കുന്നു. സൃഷ്ടിച്ച ഫയൽ കൈകൊണ്ട് തിരുത്തുന്നത് അടുത്ത വീണ്ടും കണക്ട് ചെയ്യുന്നതുവരെ പ്രവർത്തിക്കുന്നതായി തോന്നാം, അപ്പോൾ സഹായി അത് വീണ്ടും എഴുതുന്നു.
ഡിസ്ട്രിബ്യൂഷനുള്ള പിന്തുണയുള്ള ഇന്റഗ്രേഷൻ ഉപയോഗിക്കുക, ഒരു ഘടകത്തിന് മാത്രം റിസോൾവർ അവസ്ഥയുടെ ഉടമസ്ഥത നൽകുക. രണ്ട് ഉടമകൾ ഇന്റർഫേസ് വിലാസത്തിന്റെ രണ്ട് ഉടമകളെപ്പോലെ അതേ മത്സരം സൃഷ്ടിക്കുന്നു, ലക്ഷണം ഓരോ മാറ്റത്തിനും ശേഷം കുറച്ച് മിനിറ്റ് ശരിയായി വിശകലനം ചെയ്യുന്ന ഹോസ്റ്റാണ്.
ആന്തരിക പേരുകൾക്ക് സ്വന്തം പരിശോധന അർഹതയുണ്ട്. പൊതു റിസോൾവർ സാധാരണ ബ്രൗസിംഗ് പുനഃസ്ഥാപിക്കാം, പക്ഷേ ഓരോ കോർപ്പറേറ്റ് പേരും പരാജയപ്പെടുത്താം, ഇത് ടണലിന്റെ ഉദ്ദേശ്യത്തിന് വിരുദ്ധമാണ്. DNS ശരിയായി എന്ന് നിഗമനം ചെയ്യുന്നതിന് മുമ്പ് ഉദ്ദേശിച്ച സെർവറിൽ ആന്തരിക പേര് ചോദിക്കുക.
ക്ലീനപ്പ് സെറ്റപ്പിനോളം പ്രധാനമാണ്
ഇന്റർഫേസ് താഴേക്ക് ഇറക്കി റിസോൾവർ അവസ്ഥ വീണ്ടും പരിശോധിക്കുക. മുൻ കോൺഫിഗറേഷൻ പുനഃസ്ഥാപിക്കുന്ന സഹായി ഹോസ്റ്റിനെ ഉപയോഗയോഗ്യമായി വിടുന്നു; തന്റെ സെർവറുകൾ പിന്നിൽ വിടുന്നത് അടുത്ത പരാജയം സൃഷ്ടിക്കുന്നു, പലപ്പോഴും ടണൽ വളരെ മുമ്പേ പോയതിന് ശേഷം മണിക്കൂറുകൾ കഴിഞ്ഞ്.
പഴയ അവസ്ഥ തിരയാൻ തുടങ്ങുമ്പോൾ എളുപ്പത്തിൽ കാണാം. റിസോൾവർ പട്ടിക ഇല്ലാത്ത ഇന്റർഫേസിലെ വിലാസത്തിലേക്ക് ചൂണ്ടാം, തിരച്ചിൽ ഡൊമെയിൻ ഇന്ന് രാവിലെ വിട്ട നെറ്റ്വർക്കിൽ നിന്ന് അതിജീവിക്കാം. ഇവയിൽ ഏതെങ്കിലും അടുത്ത കണക്ഷനെ പ്രവചനാതീതമാക്കുന്നു, ഒന്നും ടണലിന്റെ സ്വന്തം സ്റ്റാറ്റസ് ഔട്ട്പുട്ടിൽ പ്രത്യക്ഷപ്പെടുന്നില്ല. പരിശോധന പത്ത് സെക്കൻഡ് എടുക്കുന്നു, അടുത്ത വ്യക്തിക്ക് ഒരു മണിക്കൂർ ലാഭിക്കുന്നു.
ഡയഗ്നോസിസ് പരിഹാരത്തിൽ നിന്ന് വേർതിരിക്കുക. പേര് തിരയൽ മാത്രമല്ല, ഓരോ ലക്ഷ്യവും പരാജയപ്പെടുന്നെങ്കിൽ, റൂട്ടുകളും ഫോർവേഡിംഗുമാണ് സംശയിക്കേണ്ടത്, DNS വരി ശ്രദ്ധ തിരിക്കുന്നതാണ്. wg-quick മാനുവൽ ഏത് ഫീൽഡുകൾ കൈകാര്യം ചെയ്യുന്നു, ഏത് പ്രോട്ടോക്കോളിന്റേതാണ് എന്ന് രേഖപ്പെടുത്തുന്നു, ആ അതിർത്തിയാണ് ഈ റിപ്പോർട്ടുകളിൽ മിക്കതിനും പൂർണ്ണ ഉത്തരം.