VPN കണക്ട് ചെയ്യുന്നതിന് മുമ്പ് ഹോട്ട്‌സ്പോട്ട് DNS എന്തിന് വീണ്ടും വഴിതിരിച്ചുവിടുന്നു?
ഹോട്ട്‌സ്പോട്ട് സ്വന്തം നെറ്റ്‌വർക്കിൽ ലുക്കപ്പുകൾ വീണ്ടും എഴുതുന്നു, ഏതെങ്കിലും ടണൽ നിലവിൽ വരുന്നതിന് മുമ്പേ ഹോസ്റ്റ്നെയിം എൻഡ്‌പോയിന്റ് പരിഹരിക്കപ്പെടുന്നു. ഓരോ ക്വറിക്കും ഉത്തരം നൽകിയത് ഏത് റിസോൾവർ എന്ന് കണ്ടെത്തുക.
ഒരു ഹോട്ടൽ നെറ്റ്‌വർക്കിൽ ചേരുന്നത് വ്യത്യസ്ത സമയങ്ങളിൽ രണ്ട് DNS തീരുമാനങ്ങൾ നിങ്ങളുടെ മുന്നിൽ വയ്ക്കുന്നു: സൈൻ ഇൻ ചെയ്യുമ്പോൾ ഉപകരണം നടത്തുന്ന ലുക്കപ്പുകൾ, ടണൽ ഉയർന്നതിന് ശേഷം നടത്തുന്ന ലുക്കപ്പുകൾ. ഹോട്ട്‌സ്പോട്ടിന് താൻ നിയന്ത്രിക്കുന്ന നെറ്റ്‌വർക്കിലൂടെ ആദ്യത്തേതിനെ സ്വാധീനിക്കാം. രണ്ടാമത്തേത് ക്ലൈന്റിന്റെ സ്വന്തം നയത്തെ ആശ്രയിച്ചിരിക്കുന്നു, ഇത് വെവ്വേറെ പരിശോധിക്കേണ്ട കാര്യമാണ്.
ബന്ധം ക്രമത്തിൽ പരിശോധിക്കുക, ആദ്യ DHCP ലീസ് മുതൽ സ്വകാര്യ നാമം പരിഹരിച്ച ക്വറി വരെ. അപ്പോൾ സപ്പോർട്ട് ടിക്കറ്റിൽ ഒരുപോലെ തോന്നുന്ന രണ്ട് പരാജയങ്ങൾ വ്യക്തമായി വേർതിരിയുന്നു: ഒന്ന് ടണലിന് മുമ്പ് സംഭവിച്ചു, മറ്റൊന്ന് അതിനുള്ളിൽ സംഭവിച്ചു.
ഹോട്ട്‌സ്പോട്ടിന് തൊടാനാകുന്നതും ആകാത്തതും
ആക്സസ് നെറ്റ്‌വർക്ക് DHCP-യിൽ ഒരു റിസോൾവർ വിലാസം നൽകുന്നു, കൂടാതെ ആ വിലാസത്തിലേക്കുള്ള പോർട്ട് 53 തടയാനും കഴിയും. സംരക്ഷിക്കപ്പെടാത്ത ഓരോ ലുക്കപ്പിനും പോർട്ടൽ വിലാസമോ ബ്ലോക്ക് പേജോ നൽകി ഉത്തരം പറയാൻ ഇത് മതി. എൻഡ്‌പോയിന്റ് ഹോസ്റ്റ്നെയിമായി എഴുതിയ VPN ക്ലൈന്റ് തകർക്കാനും ഇത് മതി.
ഹോട്ട്‌സ്പോട്ടിന് ചെയ്യാനാകാത്തത്, സ്ഥാപിതമായ ടണലിനുള്ളിലൂടെ ക്വറി സഞ്ചരിച്ചതിന് ശേഷം അത് വായിക്കുകയോ വീണ്ടും എഴുതുകയോ ചെയ്യുന്നതാണ്, ടണൽ അത് യഥാർത്ഥത്തിൽ വഹിക്കുന്നുവെങ്കിൽ. തടയൽ പ്ലെയിൻ ടെക്സ്റ്റിൽ ചോദ്യം കാണുന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.
ക്വറികൾ ഹോട്ട്‌സ്പോട്ടുമായി ബന്ധമില്ലാത്ത കാരണങ്ങളാൽ ടണൽ വിടുന്നു: ബ്രൗസറിന്റെ സുരക്ഷിത DNS ക്രമീകരണം, കോർപ്പറേറ്റ് പ്രത്യയം പ്രാദേശിക റിസോൾവറിൽ നിലനിർത്തുന്ന split-DNS നിയമം, അല്ലെങ്കിൽ DNS ടണലിൽ നിന്ന് ഒഴിവാക്കാൻ ക്രമീകരിച്ച ക്ലൈന്റ്. ഓരോന്നും ക്ലൈന്റ് ഭാഗത്തെ തിരഞ്ഞെടുപ്പാണ്, പുറത്തുനിന്ന് നോക്കുമ്പോൾ ഓരോന്നും ഹോട്ട്‌സ്പോട്ടിന്റെ ഇടപെടൽ പോലെ തോന്നുന്നു.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
ആദ്യ ലുക്കപ്പ് ടണൽ നിലവിൽ വരുന്നതിന് മുമ്പ് സംഭവിക്കുന്നു
ഹോസ്റ്റ്നെയിം ലഭിച്ച ക്ലൈന്റ് ആദ്യം അത് പരിഹരിക്കണം, ആ നിമിഷത്തിൽ ഒരു ടണലും ക്വറിയെ സംരക്ഷിക്കുന്നില്ല. ഹോട്ട്‌സ്പോട്ട് പോർട്ടൽ വിലാസത്തോടെ ഉത്തരം നൽകിയാൽ, ചർച്ച പരാജയപ്പെടുകയോ തൂങ്ങിക്കിടക്കുകയോ ചെയ്യും. ഒന്നും ഉത്തരം നൽകിയില്ലെങ്കിൽ, ക്ലൈന്റ് നാമ പിശക് റിപ്പോർട്ട് ചെയ്യുന്നു, ടണൽ ഒരിക്കലും ആരംഭിക്കുന്നില്ല. ഈ രണ്ട് ഫലങ്ങളിൽ ഏതും, അല്ലാത്തപക്ഷം നിരപരാധിയായി തോന്നുന്ന ശൂന്യമായ ടണൽ ലോഗിനെ വിശദീകരിക്കുന്നു.
ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങൾ സ്വന്തം കണക്റ്റിവിറ്റി പരിശോധനകളും പോർട്ടൽ കണ്ടെത്തലും നടത്തുന്നു, അവ RFC 8910, RFC 8952 എന്നിവയിൽ വിവരിച്ചിരിക്കുന്നു, ആ അഭ്യർത്ഥനകൾ ഏതെങ്കിലും VPN ഉയരുന്നതിന് മുമ്പ് പുറത്തുപോകുന്നു. അവ പ്രോക്സി ലോഗിൽ കാണുന്നത് ചോർച്ചയുടെ തെളിവല്ല, പ്രതീക്ഷിത സ്വഭാവമാണ്.
പ്രായോഗിക പരിഹാരം ക്ലൈന്റിന് ലുക്കപ്പ് ആവശ്യമില്ലാത്ത എൻഡ്‌പോയിന്റ് നൽകുകയാണ്. അത് അസാധ്യമാകുമ്പോൾ, ആദ്യം സൈൻ ഇൻ പൂർത്തിയാക്കി പിന്നീട് കണക്ട് ചെയ്യുക.
ഏത് റിസോൾവർ ഉത്തരം നൽകി എന്ന് കണ്ടെത്തുക
ബ്രൗസറിനോടല്ല, സിസ്റ്റത്തോട് ചോദിക്കുക, ക്വറി രണ്ടുതവണ പ്രവർത്തിപ്പിക്കുക: ഒരിക്കൽ ഉപകരണം ഇപ്പോൾ ഉപയോഗിക്കുന്ന റിസോൾവറിലൂടെ, ഒരിക്കൽ ഒരു സ്ഥിര വിലാസത്തിനെതിരെ.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
ആദ്യ കമാൻഡിന്റെ ഉത്തരം മൂന്നാമത്തേതിൽ നിന്ന് വ്യത്യസ്തമാണെങ്കിൽ, പ്രാദേശിക റിസോൾവർ മറ്റെന്തോ തിരികെ നൽകുന്നു എന്ന് അത് പറയുന്നു, വഴിതിരിച്ചുവിടുന്ന ഹോട്ട്‌സ്പോട്ട് ചെയ്യുന്നത് അതാണ്. മൂന്നാമത്തേതിന്റെ പരാജയം ആദ്യത്തേതിന്റെ വിജയത്തോടൊപ്പം പോർട്ടലിലേക്ക് വിരൽ ചൂണ്ടുന്നു: പ്രാദേശിക റിസോൾവർ സൈൻ-ഇൻ വിലാസം നൽകി, പുറത്തേക്കുള്ള പോർട്ട് 53 ഉപേക്ഷിക്കപ്പെട്ടു. രണ്ടിലും സമയം കഴിയുന്നത്, പ്രാമാണീകരണം പൂർത്തിയാകുന്നതുവരെ നെറ്റ്‌വർക്ക് DNS ഉപേക്ഷിക്കുന്നു എന്നാണ് അർത്ഥം.
കണക്ട് ചെയ്ത ശേഷം ആവർത്തിച്ച് താരതമ്യം ചെയ്യുക. കാഷ് ചെയ്ത ഉത്തരം പരിവർത്തനത്തെ അതിജീവിക്കുന്നു, അതിനാൽ കാഷ് ശൂന്യമാക്കുക അല്ലെങ്കിൽ രണ്ടാം നിരീക്ഷണത്തിന് പുതിയ നാമം ചോദിക്കുക.
പിന്നീടുള്ള ലുക്കപ്പുകൾ നിങ്ങൾ ഉദ്ദേശിച്ച വഴിയിൽ നിലനിർത്തുക
DNS-ഉം പിടിച്ചെടുക്കുന്ന ഫുൾ-ടണൽ പ്രൊഫൈൽ ഏറ്റവും ലളിതമായ ക്രമീകരണമാണ്: ഓരോ ആപ്പിന്റെയും ഓരോ ക്വറിയും ടണൽ തള്ളുന്ന റിസോൾവറിലേക്ക് പോകുന്നു, പ്രാദേശിക നെറ്റ്‌വർക്ക് എൻക്രിപ്റ്റ് ചെയ്ത ട്രാഫിക് മാത്രം കാണുന്നു. കണക്ട് ചെയ്ത ശേഷം ആന്തരികവും പൊതുവുമായ ഒരു നാമം പരിഹരിച്ച്, രണ്ട് ഉത്തരങ്ങളും ടണൽ റിസോൾവർ ഒറ്റയ്ക്ക് തിരികെ നൽകുന്നതുമായി താരതമ്യം ചെയ്ത് അത് തെളിയിക്കുക.
Split-DNS-ന് ഉദ്ദേശത്തോടെ എഴുതിയ ഡൊമെയിൻ പട്ടിക വേണം: കോർപ്പറേറ്റ് പ്രത്യയങ്ങൾ ടണലിലൂടെ, ബാക്കിയെല്ലാം പ്രാദേശികമായി, രണ്ടിനും ഇടയിൽ ഓവർലാപ്പ് ഇല്ല.
ബ്രൗസറിന്റെ സുരക്ഷിത DNS ആ നയത്തിന് പുറത്താണ്, അതിനാൽ പ്രൊഫൈൽ പ്രവചനീയമായി പെരുമാറാൻ അത് ഓഫ് ചെയ്യേണ്ടതുണ്ടെങ്കിൽ, മെഷീന് വേണ്ടിയല്ല, ആ പ്രൊഫൈലിന് വേണ്ടി ഓഫ് ചെയ്യുക. സിസ്റ്റം റിസോൾവർ തിരുത്തുന്നതിലൂടെയല്ല, ബ്രൗസർ ക്രമീകരണങ്ങളിൽ അത് ചെയ്യുക, അതുവഴി മാറ്റം അടുത്ത തവണ കാണാം. ഓരോ പരിശോധനയ്ക്കും ഒരു വരിയിൽ ഉത്തരം, റിസോൾവർ, കണക്ഷൻ ഘട്ടം എന്നിവ രേഖപ്പെടുത്തുക. ഹോട്ടൽ Wi-Fi-യിൽ DNS പരാജയപ്പെട്ടു എന്ന റിപ്പോർട്ട് കുറഞ്ഞത് മൂന്ന് വ്യത്യസ്ത കാരണങ്ങളുള്ള ഒരു ലക്ഷണത്തെ വിവരിക്കുന്നു.