VPN കിൽ സ്വിച്ച് പോർട്ട് 53 തടയുമ്പോൾ DNS പരിഹരിക്കപ്പെടുന്നില്ല
കിൽ സ്വിച്ചിന് DNS ബോധപൂർവ്വം തടയാം. ടണലിനുള്ളിലെ പരിഹാരത്തെ പ്രാദേശിക റിസോൾവർ ഒഴിവുകഴിവുമായി താരതമ്യം ചെയ്ത്, ഏത് പാളിയാണ് യഥാർത്ഥത്തിൽ പരാജയപ്പെട്ടതെന്ന് കണ്ടെത്തുക.
കിൽ സ്വിച്ച് ടണൽ വീഴ്ത്തുമ്പോൾ DNS പാതയും കൂടെ കൊണ്ടുപോകുന്നു, ശേഷിക്കുന്ന റിസോൾവർ നിങ്ങൾ പ്രതീക്ഷിക്കുന്നതാകാൻ സാധ്യത കുറവാണ്. രണ്ട് രൂപകൽപ്പനകൾ ആ നിമിഷത്തെ വളരെ വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യുന്നു: ടണലിനുള്ളിൽ അല്ലാത്ത ഓരോ DNS പാക്കറ്റും തടയുക, അല്ലെങ്കിൽഒരു റിസോൾവറിനെ ഒഴിവുകഴിവായി നിർത്തുക. രണ്ടും സമർത്ഥിക്കാവുന്നതാണ്. ബ്രൗസർ ടാബിൽ നിന്ന് ലക്ഷണങ്ങൾ ഏതാണ്ട് ഒരുപോലെ തോന്നും, അതിനാൽ ആദ്യ ജോലി നിങ്ങൾ യഥാർത്ഥത്തിൽ ഏത് രൂപകൽപ്പനയാണ് വിന്യസിച്ചതെന്ന് കണ്ടെത്തുകയാണ്.
ആ വ്യത്യാസം ഞാൻ കണ്ണിനു മുന്നിൽ സൂക്ഷിക്കുന്നു, കാരണം പരിഹാരം ഓരോ കാര്യത്തിലും വിപരീതമാണ്. ഒരു രൂപകൽപ്പനയ്ക്ക് വിശാലമായ ഒഴിവുകഴിവ് വേണം, മറ്റൊന്നിന് ഇടുങ്ങിയതും. ഊഹിക്കുന്നത് നിങ്ങൾക്ക് സ്വകാര്യതയോ ഒരു ഉച്ചയ്ക്കുശേഷമോ നഷ്ടപ്പെടുത്തും.
ഒരേ തകരാറിന് രണ്ട് DNS രൂപകൽപ്പനകൾ
രൂപകൽപ്പന A റിസോൾവറിനെ ടണലിനു പിന്നിലെ മറ്റൊരു സേവനമായി കണക്കാക്കുന്നു. ഫയർവാൾ നിയമങ്ങൾ UDP, TCP 53 എന്നിവ ടണൽ ഇന്റർഫേസിൽ മാത്രം അനുവദിക്കുന്നു, ക്ലൈന്റിന് നൽകുന്ന വിലാസം ടണലിനുള്ളിലെ റിസോൾവറാണ്. ടണൽ വീഴുമ്പോൾ തിരച്ചിലുകൾ നിലയ്ക്കുന്നു, അത് തകരാറല്ല, ഉദ്ദേശിച്ച ഫലമാണ്.
രൂപകൽപ്പന B പ്രാദേശിക നെറ്റ്‌വർക്കിൽ ഒരു റിസോൾവർ ലഭ്യമായി നിർത്തുന്നു, സാധാരണയായി 192.168.1.1-ലെ റൗട്ടർ അല്ലെങ്കിൽ 127.0.0.53-ലെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം സ്റ്റബ്, നാമപരിഹാരം ടണലിനൊപ്പം മരിക്കരുതെന്ന ന്യായത്തിൽ. വീട്ടിലെ LAN-ൽ ഇത് സൗകര്യപ്രദമാണ്, അവിടെ റൗട്ടർ മുഴുവൻ വീട്ടിനും പരിഹരിക്കുന്നു. ഹോട്ടലിലോ വിമാനത്താവളത്തിലോ ഉള്ള Wi-Fi-യിൽ അതേ ഒഴിവുകഴിവ് മറ്റൊരാളുടെ സെർവറിലേക്കാണ് ചൂണ്ടുന്നത്, നിങ്ങൾ ടൈപ്പ് ചെയ്യുന്ന ഓരോ നാമവും വെളിപ്പെടുന്നു, നിങ്ങളുടെ വെബ് ട്രാഫിക് തടയപ്പെട്ടു തന്നെയിരിക്കുമ്പോഴും.
അതിർത്തി റിസോൾവർ ആരുടേതെന്നതാണ്. പ്രാദേശികമായതിൽ വിശ്വസിക്കുന്നുവെങ്കിൽ ഒഴിവുകഴിവ് ചെറിയതും സത്യസന്ധവുമായ ദ്വാരമാണ്. വിശ്വസിക്കുന്നില്ലെങ്കിൽ, ടണൽ-മാത്രം രൂപകൽപ്പന മാത്രമേ നിലനിൽക്കൂ, വില എന്നത് വീണ ടണൽ എല്ലാ നാമങ്ങളും കൂടെ കൊണ്ടുപോകുന്നു എന്നതാണ്.
VPN ക്ലൈന്റിന്റെ സ്വന്തം തിരച്ചിൽ ഇപ്പോഴും പ്രവർത്തിക്കുന്നത് എന്തുകൊണ്ട്
ടണൽ ഉണ്ടാകുന്നതിന് മുൻപ് ക്ലൈന്റ് ഗേറ്റ്‌വേ ഹോസ്റ്റ്നെയിം പരിഹരിക്കണം, അതിനാൽ കർശനമായ തടയൽ ക്ലൈന്റിന്റെ ബൂട്ട്സ്ട്രാപ്പ് പാതയെ മൂടരുത്. മിക്ക ക്ലൈന്റുകളും എൻഡ്‌പോയിന്റ് വിലാസം കാഷ് ചെയ്യുന്നു, അല്ലെങ്കിൽ ആ ഒരു ഹോസ്റ്റിനായി രേഖപ്പെടുത്തിയ ബൂട്ട്സ്ട്രാപ്പ് ഒഴിവുകഴിവ് നൽകുന്നു. നിങ്ങളുടെ നിയമക്കൂട്ടം ആ തിരച്ചിൽ തടയുന്നുവെങ്കിൽ, ടണൽ ഒരിക്കലും തിരികെ വരില്ല, ലോഗുകൾ സ്വന്തം സെർവറിൽ എത്താത്ത ഒരു ക്ലൈന്റിനെ കാണിക്കും; ഇത് DNS-ന്റെയല്ല, നയത്തിന്റെ വീഴ്ചയാണ്.
വിഭജിത DNS ഇത് പ്രത്യക്ഷപ്പെടുന്ന രണ്ടാമത്തെ സ്ഥലമാണ്. ക്ലൈന്റ് ആന്തരിക സോൺ ഒരു സ്വകാര്യ റിസോൾവറിലേക്ക് തള്ളുന്നു, ബാക്കിയെല്ലാം സിസ്റ്റം റിസോൾവറിൽ വിടുന്നു. വീഴ്ചയ്ക്കുശേഷം പൊതു നാമങ്ങൾ ഇപ്പോഴും പരിഹരിക്കപ്പെടാം, എന്നാൽ ആന്തരിക നാമങ്ങൾ സമയപരിധി കഴിഞ്ഞ് പരാജയപ്പെടും, കാരണം സ്വകാര്യ സോണിന് ഇനി വഴിയില്ല. ഉപയോക്താവിന് അത് "VPN ഇന്റർനെറ്റ് തകർത്തു"; റിസോൾവർ ലോഗിന് അത് ഒരിക്കലും എത്താത്ത ഒരു ചോദ്യമാണ്.
systemd-resolved-ന് കീഴിൽ വിഭജനം നേരിട്ട് കാണാം.resolvectl statusഓരോ ലിങ്കിന്റെയും DNS സെർവറുകളും റൂട്ടിംഗ് ഡൊമെയ്നുകളും പട്ടികപ്പെടുത്തുന്നു, ടണൽ താഴേക്ക് പോയതിനുശേഷവും ആന്തരിക ഡൊമെയ്ൻ ഇനി ഇല്ലാത്ത ലിങ്കിലെ സെർവറിലേക്ക് ചൂണ്ടിക്കൊണ്ടിരിക്കുന്നു. 127.0.0.53-ലെ സ്റ്റബ് ചോദ്യം ഇപ്പോഴും സ്വീകരിക്കുന്നു, തുടർന്ന് മറുപടി നൽകാത്ത അപ്‌സ്ട്രീമിനായി കാത്തിരിക്കുന്നു, അതുകൊണ്ടാണ് പരാജയം ഉടനെ മടങ്ങുന്നതിനുപകരം നിമിഷങ്ങൾ എടുക്കുന്നത്.
എൻക്രിപ്റ്റ് ചെയ്ത DNS പാക്കറ്റ് ഫിൽട്ടറിനെ ഭേദിക്കുന്നില്ല
DNS over HTTPS-ഉം DNS over TLS-ഉം 443-ലും 853-ലുമാണ് സഞ്ചരിക്കുന്നത്, അതിനാൽ പോർട്ട് 53 തടയുന്ന നിയമം അവയെക്കുറിച്ച് ഒന്നും പറഞ്ഞിട്ടില്ല. പോർട്ട് അനുസരിച്ച് "DNS" തടയുന്നത് പോർട്ടിനെക്കുറിച്ചുള്ള നയമാണ്, നാമപരിഹാരത്തെക്കുറിച്ചല്ല. നിങ്ങളുടെ കിൽ സ്വിച്ച് ടണലിനു പുറത്തുള്ള എല്ലാ ട്രാഫിക്കും തടയുന്നുവെങ്കിൽ, DoH യാദൃശ്ചികമായി ഉൾപ്പെടും. ഒരു കാപ്റ്റീവ് പോർട്ടലിനോ പൊതു റിസോൾവറിനോ ഒഴിവ് നൽകിയിട്ടുണ്ടെങ്കിൽ, ഉൾപ്പെടില്ല.
ക്ലൈന്റ്-വശത്തെ നിയന്ത്രണങ്ങളാണ് വിലകുറഞ്ഞ ഉത്തോലകം. കാനറി നാമംuse-application-dns.netപരിഹരിക്കപ്പെടാത്തപ്പോൾ Firefox അതിന്റെ DoH റിസോൾവർ ഉപേക്ഷിക്കുന്നു, അതുകൊണ്ടാണ് മാനേജ്ഡ് നെറ്റ്‌വർക്കുകൾ ആ ഡൊമെയ്ൻ NXDOMAIN ആയി പ്രസിദ്ധീകരിക്കുന്നത്; എന്റർപ്രൈസ് നയത്തിന് അത് ഓഫാക്കി പിൻ ചെയ്യാനും കഴിയും. Android Private DNS-നും Chrome-ന്റെ സുരക്ഷിത DNS-നും സ്വന്തം സ്വിച്ചുകളും സ്വന്തം സ്ഥിരസ്ഥിതികളുമുണ്ട്. അവ ഓഫാക്കുന്നത് റിസോൾവർ വിലാസങ്ങൾക്ക് പിന്നാലെ ഓടുന്നതിനേക്കാൾ വിശ്വസനീയമാണ്, കാരണം വിലാസപ്പട്ടിക മാറുന്നു, നിങ്ങളുടെ നിയമക്കൂട്ടം മാറുന്നില്ല.
ഇതിന് ചോർച്ചയുമായി യാതൊരു ബന്ധവുമില്ലാത്ത ഒരു പതിപ്പുമുണ്ട്. പിൻ ചെയ്ത റിസോൾവറുള്ള ആപ്പിന് അവിടെ എത്താൻ നെറ്റ്‌വർക്ക് പാത ഇപ്പോഴും വേണം. എൻക്രിപ്ഷൻ മാറ്റുന്നത് ചോദ്യം ആർക്ക് വായിക്കാമെന്നതാണ്, പാക്കറ്റിന് യന്ത്രം വിടാമോ എന്നതല്ല, അതിനാൽ മുഴുവൻ ഉപകരണത്തിന്റെയും തടയൽ ക്രമീകരണത്തെ സ്പർശിക്കാതെ അതിനെ തോൽപ്പിക്കുന്നു.
ലക്ഷണത്തെ പാളിയുമായി ചേർക്കുക
മിക്ക റിപ്പോർട്ടുകളും ഒരു വാക്യമായി എത്തുന്നു, ആ വാക്യം സാധാരണയായി പാളിയെ ഇതിനകം പേരിടുന്നു. താഴെയുള്ള പട്ടിക ഏതെങ്കിലും നിയമം തൊടുന്നതിന് മുൻപ് ഞാൻ പരിശോധിക്കുന്നതാണ്; ചോദ്യം തടയപ്പെട്ടോ, തെറ്റായി അയച്ചോ, അല്ലെങ്കിൽ അയച്ചിട്ടില്ലയോ എന്ന് തീരുമാനിക്കുകയാണ് ലക്ഷ്യം.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
ആദ്യ രണ്ട് വരികളാണ് ആളുകൾ തെറ്റായി രോഗനിർണയം ചെയ്യുന്നത്. നിശബ്ദ വീഴ്ചയും നിരസിക്കലും ബ്രൗസറിൽ ഒരുപോലെ "DNS തകർന്നു" എന്ന് തോന്നും, പക്ഷേ അവയിൽ ഒന്ന് മാത്രമാണ് നിങ്ങളുടെ കിൽ സ്വിച്ച് തന്റെ ജോലി ചെയ്യുന്നു എന്നർത്ഥം. നിരസിക്കൽ അർത്ഥമാക്കുന്നത് എന്തോ മറുപടി നൽകി എന്നാണ്, അതിനാൽ തടയൽ നിങ്ങൾ കരുതുന്നിടത്തല്ല.
റിസോൾവർ നയം പുനഃസ്ഥാപിക്കുക, പിന്നെ അത് തെളിയിക്കുക
രൂപകൽപ്പന തിരുത്തുക, ലക്ഷണമല്ല. ടണൽ-മാത്രം പരിഹാരത്തിന് ടണൽ ഇന്റർഫേസിൽ 53 അനുവദിക്കുക, ടണൽ കോൺഫിഗറേഷനൊപ്പം ആന്തരിക റിസോൾവർ തള്ളുക, ഭൗതിക ലിങ്ക് ഒരു DNS അനുമതിയും കൂടാതെ വിടുക. wg-quick-ൽ റിസോൾവറിനെ ഇന്റർഫേസ് കോൺഫിഗറേഷനിൽ എഴുതുന്ന വരിDNS =ആണ്, അതിനാൽ അത് ഒഴിവാക്കുന്ന ടണൽ പഴയ റിസോൾവറിനെ അതേ സ്ഥലത്ത് വിടുകയും ഓരോ ചോദ്യവും തെറ്റായ വഴിയിലേക്ക് പോകുകയും ചെയ്യുന്നു.wg-quick കൈപ്പുസ്തകംആ പെരുമാറ്റം ഓരോ പ്ലാറ്റ്‌ഫോമിനും രേഖപ്പെടുത്തുന്നു.
തുടർന്ന് ഈ ക്രമത്തിൽ പരിശോധിക്കുക. Linux-ൽresolvectl statusസജീവ ലിങ്ക് കാണിക്കുന്നു,dig +short example.comപൊതു നാമം പരിശോധിക്കുന്നു,dig @10.8.0.1 internal.example.comസ്വകാര്യ നാമം പരിശോധിക്കുന്നു,sudo tcpdump -ni any port 53രണ്ടും പ്രവർത്തിപ്പിക്കുമ്പോൾ പാക്കറ്റുകൾ ഏത് ഇന്റർഫേസ് ഉപയോഗിക്കുന്നു എന്ന് കാണിക്കുന്നു. Windows-ൽGet-DnsClientServerAddress -AddressFamily IPv4ഉംResolve-DnsName example.comഉം അതേ രണ്ട് വസ്തുതകൾ നൽകുന്നു: ആരാണ് കോൺഫിഗർ ചെയ്തിരിക്കുന്നത്, ആരാണ് മറുപടി നൽകുന്നത്.
നെഗറ്റീവ് പരിശോധനയോടെ അവസാനിപ്പിക്കുക. ടണൽ വിച്ഛേദിക്കുക, പുതിയ പൊതു നാമം പരാജയപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക, സ്വകാര്യ നാമം പരാജയപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക,പോർട്ട് 53-ലെ ഒരു പാക്കറ്റും ഭൗതിക അഡാപ്റ്റർ വിട്ടിട്ടില്ലെന്ന് ഉറപ്പാക്കുക. കാഷ് ചെയ്ത മറുപടികൾക്ക് മാത്രം നിൽക്കുന്ന തടയൽ ഒട്ടും നിൽക്കുന്നില്ല.
ടിക്കറ്റ് അടയ്ക്കുന്നതിന് മുൻപുള്ള പരിശോധനാപട്ടിക:
- തകരാറിനിടയിൽ ഉപയോഗിച്ച റിസോൾവർ നയം ഉദ്ദേശിക്കുന്നതു തന്നെയാണ്.
- ക്ലൈന്റിന്റെ സ്വന്തം എൻഡ്‌പോയിന്റ് തിരച്ചിൽ കാഷ് അല്ലെങ്കിൽ ഒഴിവുകഴിവ് വഴി ഇപ്പോഴും അനുവദനീയമാണ്.
- DoH-ഉം DoT-ഉം തടയലിൽ ഉൾപ്പെടുന്നു, അല്ലെങ്കിൽ നയപ്രകാരം നിഷ്ക്രിയമാണ്.
- ടണൽ പോയാൽ സ്വകാര്യ സോണുകൾ തുറന്നല്ല, അടഞ്ഞ നിലയിൽ പരാജയപ്പെടുന്നു.