openfortivpn എപ്പോഴും DNS അമിതമായി എഴുതുന്നുണ്ടോ? യഥാർത്ഥ ഉടമയെ കണ്ടെത്തുക

കണക്ഷൻ ഉയരുന്ന നിമിഷം മുതൽ പിന്തുടരുക: ക്ലയന്റ് ആധികാരികമാക്കുന്നു, pppd ചർച്ച ചെയ്യുന്നു, പിന്നെ എന്തോ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിലേക്ക് DNS ക്രമീകരണങ്ങൾ എഴുതുന്നു. VPN നിങ്ങളുടെ റെസോൾവർ മാറ്റി എന്ന് മാത്രം അറിയാമെങ്കിൽ, ആ ഘട്ടങ്ങളിൽ ഏതാണ് അത് ചെയ്തതെന്ന് ഇപ്പോഴും അറിയില്ല. അവയിൽ രണ്ടെണ്ണത്തിന് സാധിക്കും, ഡോക്യുമെന്റ് ചെയ്ത pppd ഇന്റഗ്രേഷൻ ഉപയോഗിക്കുന്ന ക്ലയന്റിൽ അവ ഒരൊറ്റ പ്രവർത്തകനെപ്പോലെ തോന്നിക്കുന്നത്ര അടുത്ത് പ്രവർത്തിക്കുന്നു. എഴുത്തുകാരനെ പേരിടുന്നത് ആദ്യ ചുവട്; അയാളുടെ പകരക്കാരനെ തിരഞ്ഞെടുക്കുന്നത് രണ്ടാമത്തേത്, അത് സ്വന്തം പരാജയ രീതികളുള്ള വേറിട്ട തീരുമാനമാണ്.

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

കണക്ഷൻ യഥാർത്ഥത്തിൽ എന്ത് മാറ്റി എന്നതിൽ നിന്ന് തുടങ്ങുക

നിങ്ങളുടെ സാധാരണ കമാൻഡ് ഉപയോഗിച്ച് ഒരിക്കൽ ബന്ധിപ്പിച്ച് മുൻപും പിൻപും ഉള്ള റെസല്യൂഷൻ താരതമ്യം ചെയ്യുക. systemd-resolved പ്രവർത്തിക്കുന്ന Linux ഹോസ്റ്റിൽ, resolvectl status ഓരോ ലിങ്കിനും DNS സെർവറുകളും തിരയൽ ഡൊമെയ്നുകളും അച്ചടിക്കുന്നു, സ്വന്തം സെർവറുകൾ വഹിക്കുന്ന പുതിയ tun അല്ലെങ്കിൽ ppp ലിങ്ക് ക്ലയന്റ് വശത്തെ അപ്ഡേറ്റിന്റെ വിരലടയാളമാണ്. macOS-ൽ, scutil --dns റെസോൾവർ കോൺഫിഗറേഷൻ ആപ്ലിക്കേഷനുകൾ അതിനെ സമീപിക്കുന്ന ക്രമത്തിൽ കാണിക്കുന്നു.

അത് മാറുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിച്ച ഫയലുമായി താരതമ്യം ചെയ്യുക. ഓരോ ലിങ്കിന്റെ കാഴ്ചയിലെ കണക്ഷൻ ബന്ധിത എൻട്രിയും വീണ്ടും എഴുതിയ /etc/resolv.conf രണ്ട് വ്യത്യസ്ത ഫലങ്ങളാണ്, രണ്ടാമത്തേത് തികച്ചും മറ്റൊന്ന് കൈകാര്യം ചെയ്യുന്ന സിംബോളിക് ലിങ്ക് ആകാം. റെസോൾവറിന്റെ വിലാസം, തിരയൽ ഡൊമെയ്നുകൾ, ഇന്റർഫേസ് നാമം എന്നിവ അതേ നിമിഷത്തിൽ രേഖപ്പെടുത്തുക; അവയിൽ ഏതെങ്കിലും മാറിയാൽ മറ്റൊരു എഴുത്തുകാരനെ സൂചിപ്പിക്കുന്നു. ആ അടിസ്ഥാന രേഖയില്ലാതെ, തുടർന്നുള്ള ഓരോ തിരുത്തലും മൂന്ന് ഘടകങ്ങളിൽ ഏതാണ് നീങ്ങിയതെന്ന ഊഹമാണ്.

രണ്ട് സ്വിച്ചുകളും ഓരോന്നും അടക്കുന്ന എഴുത്തുകാരനും

openfortivpn-ന് നിയന്ത്രിക്കാവുന്ന രണ്ട് എഴുത്തുകാരെയും ഓഫാക്കുന്ന ഒരു ഓപ്ഷൻ ശകലം ഡോക്യുമെന്റ് ചെയ്യുന്നു, ഓരോ സ്വിച്ചിനും മാനുവൽ അതേ ക്രമീകരണമായി കണക്കാക്കുന്ന പൂർണ്ണമായി എഴുതിയ തുല്യരൂപമുണ്ട്.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns ക്ലയന്റ് ഗേറ്റ്വേയിൽ നിന്ന് പഠിച്ച DNS സെർവറുകൾ പ്രയോഗിക്കുന്നത് നിർത്തുന്നു, അതേസമയം --pppd-no-peerdns pppd പിയർ DNS സിസ്റ്റത്തിലേക്ക് തള്ളുന്നത് നിർത്തുന്നു. upstream മാനുവൽ PPP വഴിയുള്ള DNS അപ്ഡേറ്റുകൾ ക്ലയന്റിന്റെ സ്വന്തം DNS അപ്ഡേറ്റുകളുമായി മത്സരിക്കാമെന്ന് മുന്നറിയിപ്പ് നൽകുന്നു, അതിനാൽ രണ്ട് സ്വിച്ചുകളും ശകലത്തിൽ ഉണ്ടായിരിക്കണം, ഒന്നിനെ മതിയെന്ന് കണക്കാക്കുന്നതിന് പകരം.

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

എന്തെങ്കിലും പ്രവർത്തനരഹിതമാക്കുന്നതിന് മുൻപ് ഉടമയെ തിരഞ്ഞെടുക്കുക

ജോലി നാമങ്ങൾക്കുള്ള ചോദ്യങ്ങൾക്ക് ആര് ഉത്തരം നൽകുമെന്ന് ആദ്യം തീരുമാനിക്കുക, കാരണം ആ തിരഞ്ഞെടുപ്പ് പിന്നീടുള്ള എല്ലാം പരിമിതപ്പെടുത്തുന്നു. നിലവിലുള്ള റെസോൾവർ നിലനിർത്തുക എന്നാൽ സ്വകാര്യ മേഖല ക്ലയന്റ് ഇരിക്കുന്നിടത്ത് നിന്ന് ഇതിനകം എത്താവുന്നതായിരിക്കണം, കൂടാതെ ഓഫീസിനുള്ളിലെ സ്വകാര്യ റെസോൾവറിന് ടണൽ ഉയരുമ്പോഴും നിലനിൽക്കുന്ന ഒരു പാത വേണം. ഓരോ ചോദ്യവും ഒരു ആന്തരിക സേവനത്തിലേക്ക് അയക്കുന്നത് കൂടുതൽ മൂർച്ചയുള്ള പരാജയ രീതിയുള്ള മൂന്നാമത്തെ നയമാണ്: ആ സേവനം എത്താനാവാത്തതാകുമ്പോൾ, പൊതു നാമങ്ങൾ സ്വകാര്യ നാമങ്ങളോടൊപ്പം പരാജയപ്പെടുന്നു.

പാത ഉടമസ്ഥത ബോധപൂർവം വേറിട്ട് നിൽക്കുന്നു. പാത ഓപ്ഷനുകൾ നിങ്ങൾ DNS മാറ്റിയതുകൊണ്ട് ആവശ്യമല്ല, പകരം ഇൻസ്റ്റാൾ ചെയ്യാതെ പാത ഇൻസ്റ്റലേഷൻ ഓഫാക്കുന്നത് നിങ്ങൾ ഇപ്പോൾ തിരഞ്ഞെടുത്ത റെസോൾവറിനെ എത്താനാവാത്തതാക്കാം. റൂട്ടിംഗ് പട്ടികയിൽ പ്രത്യേകിച്ച് റെസോൾവറിന്റെ വിലാസത്തിനായി നോക്കുക, നിങ്ങൾ യാദൃച്ഛികമായി പരീക്ഷിച്ച ആപ്ലിക്കേഷൻ സബ്നെറ്റിനായി മാത്രമല്ല.

റെസല്യൂഷൻ ഓരോ ഫയലിനും വേണ്ടി അല്ല, ഓരോ ലിങ്കിനും വേണ്ടി പരിശോധിക്കുക

പരിമിതമായ അല്ലെങ്കിൽ ഡൊമെയ്ൻ അടിസ്ഥാനമാക്കിയ റെസല്യൂഷനുള്ള ഹോസ്റ്റിൽ ആപ്ലിക്കേഷനുകൾ യഥാർത്ഥത്തിൽ എന്ത് ഉപയോഗിക്കുന്നു എന്നതിന്റെ പട്ടിക ഒരു /etc/resolv.conf അല്ല, അതിനാൽ പ്ലാറ്റ്ഫോം അത് വെളിപ്പെടുത്തുന്ന രീതിയിൽ റെസോൾവറിന്റെ അവസ്ഥ വായിക്കുക.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

വീണ്ടും ബന്ധിപ്പിച്ച് വിച്ഛേദിച്ച അവസ്ഥ ഉറപ്പാക്കുക

കണക്ഷൻ താഴ്ത്തി രണ്ട് ചോദ്യങ്ങളും ആവർത്തിക്കുക. തിരഞ്ഞെടുത്ത ഉടമ ഇൻസ്റ്റാൾ ചെയ്തത് അതേ ഉടമ നീക്കം ചെയ്യുകയോ പുനഃസ്ഥാപിക്കുകയോ വേണം, നിങ്ങൾ നിശ്ശബ്ദമാക്കിയ ക്ലയന്റ് അത് ഉപേക്ഷിച്ച് പോകരുത്. ടണലിനെക്കാൾ കൂടുതൽ കാലം നിലനിൽക്കുന്ന പഴയ ലിങ്ക് എൻട്രി ഇപ്പോൾ എത്താനാവാത്ത വിലാസത്തിലേക്ക് സ്വകാര്യ ചോദ്യങ്ങൾ അയച്ചുകൊണ്ടിരിക്കുന്നു.

തുടർന്ന് വീണ്ടും ബന്ധിപ്പിച്ച് അതേ മൂന്ന് മൂല്യങ്ങൾ വായിക്കുക: റെസോൾവറിന്റെ വിലാസം, തിരയൽ ഡൊമെയ്നുകൾ, ഇന്റർഫേസ്.

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