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

ഘട്ടം 1: റിസോൾവറിനും വഴിക്കും പേരു നൽകുക

ഫയർവാളിൽ തൊടുന്നതിന് മുമ്പ് മൂന്ന് കാര്യങ്ങൾ എഴുതുക: റിസോൾവറിന്റെ വിലാസം, നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന പ്രോട്ടോക്കോളും പോർട്ടും, ക്വറി പുറത്തുപോകേണ്ട ഇന്റർഫേസ്. ഈ പട്ടികയില്ലാതെ ഒരു നിയമം ഗതാഗതത്തെക്കുറിച്ചുള്ള ഊഹമാണ്, ഒരു തീരുമാനത്തിന്റെ നടപ്പാക്കലല്ല. VPN ആപ്ലിക്കേഷൻ ഡാറ്റ കൊണ്ടുപോകുമ്പോൾ DNS വേറിട്ട ക്രമീകരണം പിന്തുടരാം, അത് സ്വതവേ തെറ്റല്ല. ആരും ക്ലയന്റിനോട് മറ്റൊന്ന് പറയാത്തപ്പോൾ സംഭവിക്കുന്നതാണത്.

വഴിക്ക് വ്യക്തമായി പേരു നൽകുന്നതാണ് രൂപരേഖയും യാദൃച്ഛികതയും തമ്മിലുള്ള വ്യത്യാസം. പിന്നീട് പരിശോധിക്കാൻ എന്തെങ്കിലും ഇത് നൽകുന്നു, കാരണം ഓരോ നിരീക്ഷണവും എഴുതിയ പ്രതീക്ഷയുമായി താരതമ്യം ചെയ്യാം. ആ പട്ടിക മാറ്റ ടിക്കറ്റിൽ സൂക്ഷിക്കുക, ആരുടെയെങ്കിലും തലയിൽ അല്ല.

ഘട്ടം 2: നയം യഥാർത്ഥത്തിൽ കിടക്കുന്നിടത്ത് വയ്ക്കുക

റിസോൾവർ തിരഞ്ഞെടുപ്പ് ക്ലയന്റിന്റേതാണ്: ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ നെറ്റ്വർക്ക് ക്രമീകരണം, VPN ക്ലയന്റിന്റെ സ്വന്തം ക്രമീകരണങ്ങൾ, അല്ലെങ്കിൽ മാനേജ് ചെയ്ത ബ്രൗസർ നയം. ആദ്യം അവിടെ വയ്ക്കുക, പ്ലാറ്റ്ഫോം പിന്തുണയ്ക്കുന്ന രീതിയിൽ, കാരണം ഒരിക്കലും അറിയിച്ചിട്ടില്ലാത്ത റിസോൾവർ തിരഞ്ഞെടുക്കാൻ ഫയർവാൾ ക്ലയന്റിനെ നിർബന്ധിക്കാനാവില്ല. സ്പ്ലിറ്റ് ടണൽ ക്ലയന്റിൽ ഏത് ഡൊമെയ്നുകൾ ആന്തരിക റിസോൾവറിലേക്ക് പോകുന്നു എന്ന് വ്യക്തമായി പറയുക. മാനേജ് ചെയ്ത കൂട്ടത്തിൽ DoH-യ്ക്ക് ബ്രൗസർ നയം മാത്രമായിരിക്കും പലപ്പോഴും ഉപായം, കാരണം സിസ്റ്റം ക്രമീകരണത്തിൽ നിന്ന് സ്വതന്ത്രമായി ബ്രൗസറിന് സ്വന്തം എൻക്രിപ്റ്റ് ചെയ്ത റിസോൾവർ തിരഞ്ഞെടുക്കാം.

ഇത് ഒഴിവാക്കി നേരെ ഫയർവാളിലേക്ക് പോയാൽ ശരിയായ റിസോൾവറിന് അനുമതി നൽകുന്ന നിയമവും അത് ഒരിക്കലും ഉപയോഗിക്കാത്ത ക്ലയന്റും ലഭിക്കും. നിയമം ശരിയായി തോന്നും, റിസോൾവറിന്റെ ലോഗുകൾ ശൂന്യമായി തുടരും, ഇത് ഡീബഗ്ഗിംഗിന് ആശയക്കുഴപ്പമുള്ള ജോടിയാണ്. ആദ്യം തിരഞ്ഞെടുപ്പ് ക്രമീകരിക്കുക, പിന്നീട് അത് നടപ്പാക്കുക.

ഘട്ടം 3: വഴി ഇടുങ്ങിയതായി നടപ്പാക്കുക

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

PathPortWho controls it
Classic DNSUDP and TCP 53System resolver settings
DNS over TLSTCP 853Resolver or stub configuration
DNS over HTTPSTCP 443Browser or application policy

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

ഘട്ടം 4: സ്വകാര്യ, പൊതു നാമങ്ങൾ പിന്തുടരുക

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

നിങ്ങളുടെ റിസോൾവർ റിപ്പോർട്ട് ചെയ്യുന്ന പരീക്ഷണ സൈറ്റ് സൂചനയാണ്, തെളിവല്ല, കാരണം അതിൽ എത്തിയ ക്വറികൾ മാത്രമേ അത് കാണുന്നുള്ളൂ. ക്വറി യഥാർത്ഥത്തിൽ ഏത് വഴിയാണ് സ്വീകരിച്ചതെന്ന് അറിയേണ്ടിവരുമ്പോൾ ക്ലയന്റ് വശത്ത് അത് പിടിച്ചെടുക്കുക, പിന്നീട് രണ്ട് നിരീക്ഷണങ്ങളും താരതമ്യം ചെയ്യുക. അവ യോജിക്കാതിരുന്നാൽ ആരും രേഖപ്പെടുത്താത്ത ഒരു പിന്നോട്ടുവീഴ്ച നിങ്ങൾ കണ്ടെത്തി.

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

ഘട്ടം 5: മടങ്ങിവരാൻ ഒരു വഴി സൂക്ഷിക്കുക

ഗേറ്റ്വേയിലെ DNS പ്രവേശനം കർശനമാക്കുന്നതിന് മുമ്പ്, നാമ പരിഹാരത്തെ ആശ്രയിക്കാത്ത ഒരു വീണ്ടെടുപ്പ് രീതി ഉറപ്പാക്കുക. തകർന്ന റിസോൾവർ ഓരോ അറ്റകുറ്റപ്പണി ഉപകരണവും എത്തിച്ചേരാൻ ബുദ്ധിമുട്ടാക്കുന്നു, മാറ്റം പിൻവലിക്കാൻ നിങ്ങൾ ഉപയോഗിക്കുന്നവയും ഉൾപ്പെടെ. പുതിയ നയം തെളിയിക്കുന്നതുവരെ പ്രാദേശിക കൺസോളോ ഔട്ട്-ഓഫ്-ബാൻഡ് വഴിയോ തുറന്നിടുക. നയം ഒരു പുനഃസംയോജനം അതിജീവിച്ചതിനു ശേഷം മാത്രം അത് നീക്കുക.

പുനഃസംയോജനത്തിനോ ബ്രൗസർ നയ അപ്ഡേറ്റിനോ ശേഷം ഫലപ്രദമായ അവസ്ഥ വീണ്ടും പരിശോധിക്കുക, കാരണം രണ്ടും നിങ്ങളുടെ നിയമം മാറ്റാതെ റിസോൾവർ മാറ്റാം. ആവശ്യകത ക്വറികൾക്ക് അറിയപ്പെടുന്ന സ്വീകർത്താവും സംരക്ഷിത വഴിയുമാണ്, ഒരു സ്ക്രീൻഷോട്ടിലെ ആശ്വാസകരമായ റിസോൾവർ ലേബലല്ല. RFC 8484 DNS over HTTPS സ്പെസിഫിക്കേഷൻ നിങ്ങളുടെ പോർട്ട് നിയമം കാണാത്ത എൻക്രിപ്റ്റ് ചെയ്ത വഴിക്കുള്ള ആധാരമാണ്.

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