Windows-ൽ OpenVPN ബന്ധിപ്പിച്ചതിന് ശേഷം DNS എന്തിന് പ്രവർത്തനം നിർത്തുന്നു

പോർട്ട് 53 എങ്ങോട്ടും എത്തുന്നില്ലെങ്കിലും റിസോൾവർ ഇപ്പോഴും ping-ന് ഉത്തരം നൽകുന്നു. block-outside-dns ഫിൽട്ടർ ചെയ്യുന്നുണ്ടോ എന്ന് പരിശോധിച്ച്, ടണൽ എത്താവുന്ന ഒരു റിസോൾവർ നൽകുക.

ഓഫീസ് റിസോൾവറിലേക്കുള്ള ping-ന് "OpenVPN" ബന്ധിപ്പിച്ചതിന് ശേഷവും ഉത്തരം ലഭിക്കുന്നു, എന്നിട്ടും ഓരോ നാമാന്വേഷണവും പരാജയപ്പെടുന്നു. വിലാസം എത്താവുന്നതാണ്, പോർട്ട് അല്ല, Windows അഡാപ്റ്റർ അനുസരിച്ച് DNS ഫിൽട്ടർ ചെയ്യാമെന്ന് അറിഞ്ഞാൽ ഈ കൂട്ട് അർത്ഥവത്താണ്. പ്രൊഫൈലിൽ block-outside-dns ഉണ്ടെങ്കിൽ ആ ഫിൽട്ടറാണ് ആദ്യ സംശയം, റൂട്ട് പട്ടിക നോക്കേണ്ട തെറ്റായ സ്ഥലമാണ്. താഴെയുള്ള രണ്ട് പരിശോധനകൾ പാളികളെ സെക്കൻഡുകൾക്കുള്ളിൽ വേർതിരിക്കുന്നു.

എത്താവുന്ന വിലാസം, മരിച്ച പോർട്ട്

വിജയകരമായ ping ഹോസ്റ്റ് പ്രവർത്തിക്കുന്നു എന്നും ഒരു വഴിയുണ്ട് എന്നും തെളിയിക്കുന്നു. പോർട്ട് 53 ലേക്ക് എത്താനുള്ള അനുമതിയെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല, കാരണം ബന്ധപ്പെട്ട ഫിൽട്ടർ മറ്റൊരു പാളിയിൽ പ്രവർത്തിക്കുന്നു, അഡാപ്റ്ററിനെ ആശ്രയിക്കുന്നു. അതിനാൽ അതേ യന്ത്രത്തിന് ICMP-യ്ക്ക് ഉത്തരം നൽകാം, അതേ വിലാസത്തിലേക്ക് അയച്ച ഓരോ ചോദ്യവും നിരസിക്കാം. ഏതെങ്കിലും ക്രമീകരണം മാറ്റുന്നതിന് മുൻപ് രണ്ട് പരിശോധനകളും ഒരേ സെഷനിൽ നടത്തുക.

ping <resolver-ip>
nslookup <name> <resolver-ip>

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

ഈ ഓപ്ഷൻ ഫിൽട്ടറിംഗ് പ്ലാറ്റ്ഫോമിന്റെ നിയമമാണ്

OpenVPN റഫറൻസ് block-outside-dns-നെ Windows Filtering Platform-ന്റെ ഒരു നിയന്ത്രണമായി വിവരിക്കുന്നു, ഇത് ടണലിന് പുറത്തുള്ള അഡാപ്റ്ററുകളിൽ അപ്ലിക്കേഷനുകൾ DNS-ൽ എത്തുന്നത് തടയുന്നു. ഇത് TCP, UDP പോർട്ട് 53 എന്നിവ ഉൾക്കൊള്ളുന്നു. ഫിൽട്ടർ സാധാരണ ഫയർവാൾ നിയമപ്പട്ടികയിലല്ല, WFP-യിൽ കഴിയുന്നതിനാൽ മറ്റൊരിടത്ത് അനുമതി നിയമം ചേർക്കുന്നത് ഫലം മാറ്റണമെന്നില്ല. അതുകൊണ്ടാണ് DNS അനുവദിക്കാനുള്ള പതിവ് ഉപദേശം പരാജയപ്പെട്ടുകൊണ്ടിരിക്കുന്നത്.

ക്രമീകരണം ഇറക്കുമതി ചെയ്ത പ്രൊഫൈലിൽ നിന്നോ സർവറിൽ നിന്നോ വരാം, നിങ്ങൾ അവസാനം തിരുത്തിയ ഫയൽ "ക്ലയന്റ് എന്ത് ലോഡ് ചെയ്തു എന്നതിന് തെളിവല്ല". ഫലപ്രദ ക്രമീകരണവും കണക്ഷൻ ലോഗും ഒരുമിച്ച് വായിക്കുക. ഈ ഓപ്ഷൻ Windows-ന് പ്രത്യേകവുമാണ്, അതിനെ കൈകാര്യം ചെയ്യാവുന്നതായി കണക്കാക്കിയാൽ ബാധകമല്ലാത്ത ഉപദേശം വരും.

കൂടുതൽ നിയമങ്ങൾ ചേർക്കുന്നതിന് പകരം ആ നിയന്ത്രണം ഉള്ള ക്ലയന്റ് ഘടകം തിരയുക. ഉടമസ്ഥൻ അത് യഥാർത്ഥത്തിൽ നീക്കാൻ കഴിയുന്ന കാര്യമാണ്.

ഫിൽട്ടർ റിസോൾവർ അല്ല

ടണലിന് പുറത്തുള്ള ട്രാഫിക് തടയുന്നത് അതിനുള്ളിൽ പ്രവർത്തിക്കുന്ന റിസോൾവർ ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല. ഓപ്ഷൻ ഒരു വഴി നീക്കി ടണലിന്റെ DNS ക്രമീകരണം പ്രൊഫൈൽ ഉണ്ടാക്കിയവർക്ക് വിടുന്നു. ഒരിക്കലും റിസോൾവർ അയച്ചിട്ടില്ലാത്ത പ്രൊഫൈലിന് ഇപ്പോൾ ഒന്നുമില്ല.

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

  1. ഉപയോഗത്തിലുള്ള റിസോൾവർ: Resolve-DnsName -Server <resolver-ip> <name> എന്നത് ipconfig /all പട്ടികപ്പെടുത്തുന്ന DNS സർവറുകളുമായി താരതമ്യം ചെയ്യുക.
  2. VPN DNS പ്രയോഗിച്ചു: അതേ ipconfig /all ഔട്ട്പുട്ടിൽ ടണൽ അഡാപ്റ്ററിന്റെ DNS എൻട്രികൾ പരിശോധിക്കുക.
  3. ഉപയോഗിച്ച ഇന്റർഫേസ്: Find-NetRoute -RemoteIPAddress <resolver-ip> ആ ലക്ഷ്യത്തിനുള്ള പുറത്തേക്കുള്ള ഇന്റർഫേസ് പേര് നൽകുന്നു.

ഈ നയത്തിന് കീഴിൽ LAN റിസോൾവർ രൂപകൽപ്പനയനുസരിച്ച് എത്താനാവാത്തതാകുന്നു, മറ്റ് LAN ട്രാഫിക് പ്രവർത്തിക്കുമ്പോഴും. അതാണ് ഓപ്ഷൻ അതിന്റെ ജോലി ചെയ്യുന്നത്. രൂപകൽപ്പനയ്ക്ക് VPN DNS വേണമെങ്കിൽ റിസോൾവർ രജിസ്ട്രേഷനും ടണൽ വഴിയും ശരിയാക്കുക; ലോക്കൽ ഒഴിവുകളോടെ split DNS വേണമെങ്കിൽ ക്രമീകരണത്തിന്റെ ഉടമ ആ ഒഴിവുകൾ പിന്തുണയുള്ള രീതിയിൽ പ്രകടിപ്പിക്കണം.

ഈ ഓപ്ഷൻ ഉൾക്കൊള്ളാത്തത്

പോർട്ട് 53 മുഴുവൻ നാമപരിഹാരവുമല്ല. DNS over HTTPS, DNS over TLS എന്നിവ വ്യത്യസ്ത ഗതാഗതം ഉപയോഗിക്കുന്നു, ചില അപ്ലിക്കേഷനുകൾ സിസ്റ്റം ക്രമീകരണങ്ങൾ കണക്കിലെടുക്കാതെ സ്വന്തം റിസോൾവർ യുക്തി പ്രവർത്തിപ്പിക്കുന്നു. അതിനാൽ ബ്രൗസറിന് നാമങ്ങൾ പരിഹരിക്കാം, കമാൻഡ് ലൈനിന് കഴിയില്ല.

ആ വ്യത്യാസത്തെ വൈരുദ്ധ്യമല്ല, രോഗനിർണയമായി കാണുക. സിസ്റ്റം റിസോൾവർ കേടാണെന്ന് തീരുമാനിക്കുന്നതിന് മുൻപ് രണ്ടും താരതമ്യം ചെയ്യുക.

എഴുതുമ്പോൾ നിഗമനം ഇടുങ്ങിയതായി സൂക്ഷിക്കുക. ഈ ഓപ്ഷൻ ഒരു പ്ലാറ്റ്ഫോമിൽ ഒരു ഗതാഗതം പരിമിതപ്പെടുത്തുന്നു, പരിഹാര വഴിയുടെ ബാക്കി സ്വന്തം ഉടമയുള്ള പ്രത്യേക രൂപകൽപ്പന ചോദ്യമാണ്.

വിച്ഛേദനത്തിന് മുൻപും ശേഷവും അവസ്ഥ പരിശോധിക്കുക

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

ipconfig /displaydns
nslookup <name> <resolver-ip>

ക്ലയന്റ് സേവനമോ യന്ത്രമോ പുനരാരംഭിക്കുന്നത് സാധാരണയായി പഴയ ഫിൽട്ടർ നീക്കും. ഇത് രോഗനിർണയം സ്ഥിരീകരിക്കുന്നു, സ്ഥിരമായ പരിഹാരം തെളിയിക്കുന്നില്ല. കണ്ടത് രേഖപ്പെടുത്തുക, കാരണം വിച്ഛേദനത്തെ അതിജീവിക്കുന്ന ഫിൽട്ടർ അത് വീണ്ടും ചെയ്യും, ആ രേഖയാണ് ബഗ് റിപ്പോർട്ടിനെ ന്യായീകരിക്കുന്നത്.

ഈ പരിശോധനകൾക്ക് ശേഷം മാത്രമേ റിസോൾവർ മാറ്റുന്നതോ ഫയർവാൾ നയം പുനർനിർമ്മിക്കുന്നതോ അർത്ഥവത്താകൂ. രണ്ടും തെളിവുകൾ പിന്തുണയ്ക്കുന്നതിനേക്കാൾ വലിയ മാറ്റങ്ങളാണ്.

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