റൗട്ടറിന്റെ സ്വന്തം DNS എന്തുകൊണ്ട് VPN ടണൽ ഒഴിവാക്കുന്നു?
ക്ലൈന്റിന്റെ ലുക്കപ്പും റൗട്ടറിന്റെ അപ്സ്ട്രീം ചോദ്യവും രണ്ട് വ്യത്യസ്ത പ്രവാഹങ്ങളാണ്. രണ്ടും ക്യാപ്ചർ ചെയ്യുക, റിസോൾവറിന്റെ എക്സിറ്റ് തിരഞ്ഞെടുക്കുക, തുടർന്ന് ടണൽ വിച്ഛേദിക്കുന്ന സാഹചര്യം പരിശോധിക്കുക.
ക്ലൈന്റ് ലുക്കപ്പുകൾ ടണലിനെ പിന്തുടരുന്നു, എന്നാൽ റൗട്ടറിന്റെ സ്വന്തം ലുക്കപ്പുകൾ WAN വഴി പുറത്തുപോകുന്നു, ഒന്നിനെ നിയന്ത്രിക്കുന്ന ഫയർവാൾ നിയമത്തിന് മറ്റൊന്നിൽ യാതൊരു സ്വാധീനവുമില്ല. കാരണം ബഗ് അല്ല: ഫോർവേഡ് ചെയ്ത അഭ്യർത്ഥനയും റൗട്ടർ സ്വയം സൃഷ്ടിക്കുന്ന അഭ്യർത്ഥനയും രണ്ട് വേറിട്ട പ്രവാഹങ്ങളാണ്, ഓരോന്നും കോൺഫിഗറേഷന്റെ വ്യത്യസ്ത ഭാഗവുമായി ഒത്തുനോക്കുന്നു. ക്ലൈന്റിന്റെ പകുതി മാത്രം ക്യാപ്ചർ ചെയ്താൽ രണ്ടാം പകുതി ഒരിക്കലും ഉപയോഗിക്കാത്ത പാതയെക്കുറിച്ച് ഉറച്ച ഉത്തരം ലഭിക്കും. പരിഹാരം റൗട്ടറിന്റെ റിസോൾവർ ബോധപൂർവം ലക്ഷ്യമിട്ട്, തുടർന്ന് രണ്ട് പാതകളും വെവ്വേറെ പരിശോധിക്കുകയാണ്.
പാക്കറ്റ് ക്യാപ്ചർ യഥാർത്ഥത്തിൽ ഏത് പ്രവാഹത്തിന്റേതാണ്
ഒരു ലുക്കപ്പിൽ രണ്ട് കൈമാറ്റങ്ങൾ ഉണ്ട്. LAN ക്ലൈന്റ് റൗട്ടറിന്റെ റിസോൾവറിലേക്ക് ചോദ്യം അയക്കുന്നു, അത് LAN ഇന്റർഫേസിൽ ഫോർവേഡ് ചെയ്ത ട്രാഫിക്കായി എത്തുന്നു, അതിനാൽ ഫോർവേഡ് ചെയ്ത പാക്കറ്റുകൾക്കായി എഴുതിയ പോളിസി റൂട്ടോ NAT നിയമമോ അതുമായി പൊരുത്തപ്പെടാം. തുടർന്ന് റൗട്ടർ കാഷെയിൽ നിന്ന് ഉത്തരം നൽകുന്നു, അല്ലെങ്കിൽ രേഖയില്ലെങ്കിൽ അപ്സ്ട്രീം സെർവറിലേക്ക് സ്വന്തം ചോദ്യം തുറക്കുന്നു.
ആ രണ്ടാം ചോദ്യത്തിന്റെ ഉറവിടം റൗട്ടർ തന്നെയാണ്, ലക്ഷ്യവും അതുതന്നെ, പ്ലാറ്റ്ഫോം അതിന്റെ പാത മറ്റൊരു കോൺഫിഗറേഷൻ ബ്ലോക്കിൽ നിന്ന് തിരഞ്ഞെടുക്കുന്നു. രണ്ട് കൈമാറ്റങ്ങളും ഒരേ പേര് വഹിക്കുന്നു, ഒന്നും മറ്റൊന്നിന്റെ പകർപ്പല്ല. അതിനാൽ LAN ഭാഗത്ത് എടുത്ത ക്യാപ്ചർ ക്ലൈന്റിന്റെ പാക്കറ്റ് എവിടെ പോയി എന്ന് തെളിയിക്കുന്നു, പുറത്തുപോകുന്ന പാക്കറ്റിനെക്കുറിച്ച് ഒന്നും പറയുന്നുമില്ല.
പ്രായോഗിക പരിശോധന ഇരു ഭാഗങ്ങളും ഒരുമിച്ച് നിരീക്ഷിക്കുകയാണ്. റൗട്ടറിൽ റിസോൾവറിന്റെ സോക്കറ്റ് ലിസ്റ്റ് ചെയ്യുക, പ്രാദേശികമായി അതിനോട് ചോദിക്കുക, WAN ഇന്റർഫേസ് ക്യാപ്ചർ ചെയ്യുക:
sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53സോക്കറ്റ് ലിസ്റ്റ് loopback അല്ലെങ്കിൽ LAN വിലാസത്തിൽ ബന്ധിപ്പിച്ച ശ്രോതാവിനെ കാണിച്ചാൽ, റൗട്ടർ മറ്റൊരു ഹോസ്റ്റിലേക്ക് ഫോർവേഡ് ചെയ്യുന്നതിനുപകരം പ്രാദേശികമായി ഉത്തരം നൽകുന്നു. അപ്പോൾ ക്യാപ്ചർ, ഉണ്ടായ അപ്സ്ട്രീം ചോദ്യം ടണൽ ഇന്റർഫേസിലൂടെയാണോ WAN വഴിയാണോ പുറത്തുപോകുന്നതെന്ന് കാണിക്കുന്നു, അതാണ് പോളിസി റൂട്ട് നിയമം ഒരിക്കലും നൽകാത്ത ഉത്തരം.
പോളിസി റൂട്ട് രണ്ടാം ചോദ്യം ഒരിക്കലും കാണാത്തതെന്തുകൊണ്ട്
ഫയർവാൾ നിയമങ്ങൾ ഇന്റർഫേസ്, ഉറവിടം, ലക്ഷ്യം, പോർട്ട് എന്നിവയ്ക്കെതിരെ എഴുതുന്നു, ഉപകരണത്തിലൂടെ കടന്നുപോകുന്ന പാക്കറ്റുകൾക്ക് അവ വിലയിരുത്തുന്നു. റൗട്ടർ സൃഷ്ടിക്കുന്ന ചോദ്യം ഒന്നിലൂടെയും കടന്നുപോകുന്നില്ല, കാരണം ഒരു പ്രാദേശിക പ്രക്രിയ അത് നേരിട്ട് റൂട്ടിംഗ് പട്ടികയ്ക്ക് നൽകുന്നു. പോളിസി റൂട്ടിംഗും NAT-ഉം അതിനാൽ ഫോർവേഡ് ചെയ്ത പാതയ്ക്ക് മാത്രം ബാധകമാണ്, അതുകൊണ്ടുതന്നെ നിയമക്കൂട്ടം പൂർണ്ണമായി തോന്നിയാലും റൗട്ടറിന്റെ DNS ടണലിന് പുറത്ത് വിടാം.
ഈ വ്യത്യാസം ഓരോ ഫേംവെയർ പുനരെഴുത്തിന് ശേഷവും നിലനിൽക്കുന്നു, കാരണം അത് ഒരു സവിശേഷതയിൽ നിന്നല്ല, പാക്കറ്റിന്റെ പാതയിൽ നിന്നാണ് ഉണ്ടാകുന്നത്. ഉപകരണം തനിക്കായി സൃഷ്ടിക്കുന്നതെല്ലാം — റിസോൾവർ ചോദ്യങ്ങൾ, സമയ സമന്വയം, അപ്ഡേറ്റ് പരിശോധനകൾ, പാക്കറ്റ് കണ്ണാടികളിലേക്കുള്ള പ്രവേശനം — പ്രാദേശിക ഉത്ഭവമുള്ളതാണ്, അതേ അന്ധമായ പോയിന്റിൽ വീഴുന്നു. ലാപ്ടോപ്പിൽ നിന്നുള്ള പരിശോധന റൗട്ടറിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കാത്തതും അതുകൊണ്ടാണ്.
pfSense റിസോൾവർ സ്വന്തം അപ്സ്ട്രീം പാത എവിടെ തീരുമാനിക്കുന്നു
pfSense ഈ വിഭജനം ദൃശ്യമാക്കുന്നു. ക്ലൈന്റ് ട്രാഫിക് പോളിസി വഴി VPN ഗേറ്റ്വേയിലൂടെ കടത്തിവിടാം, എന്നാൽ ഫയർവാളിന്റെ സ്വന്തം ട്രാഫിക് LAN നിയമങ്ങൾക്കുപകരം റിസോൾവറിന്റെ ഔട്ട്ഗോയിംഗ് ക്രമീകരണം പിന്തുടരുന്നു. വെബ് ഇന്റർഫേസിൽ ആ ക്രമീകരണം Services > DNS Resolver > Outgoing Network Interfaces-ന് കീഴിലാണ്, അതിന്റെ മൂല്യം റിസോൾവർ അപ്സ്ട്രീം ചോദ്യങ്ങൾക്ക് ഉപയോഗിക്കാവുന്ന ഇന്റർഫേസുകളുടെ പട്ടികയാണ്.
അവിടെ ടണൽ ഇന്റർഫേസ് പേരിടുന്നതും, ആ ഇന്റർഫേസ് മാത്രം പേരിടുന്നതുമാണ് റൗട്ടറിന്റെ സ്വന്തം ലുക്കപ്പുകളെ ടണലിനെ പിന്തുടരാൻ പ്രേരിപ്പിക്കുന്നത്. സ്ഥിരസ്ഥിതിയിൽ വിട്ടാൽ, റിസോൾവർ റൂട്ടിംഗ് പട്ടികയിൽ നിന്ന് എക്സിറ്റ് തിരഞ്ഞെടുക്കുന്നു, ഇരട്ട WAN അല്ലെങ്കിൽ VPN ഹോസ്റ്റിൽ അത് പലപ്പോഴും WAN ആണ്.
മറ്റ് ഫേംവെയറുകൾ അതേ തീരുമാനം മറ്റൊരു ലേബലിൽ വെളിപ്പെടുത്തുന്നു: ഉറവിട വിലാസത്തിൽ ബന്ധിപ്പിച്ച അപ്സ്ട്രീം സെർവർ പട്ടിക, ഫോർവേഡിംഗ് മാത്രം മോഡ്, അല്ലെങ്കിൽ രേഖപ്പെടുത്തിയ റൂട്ട് പോളിസി. അന്വേഷിക്കേണ്ട ക്രമീകരണം എപ്പോഴും പ്രാദേശികമായി സൃഷ്ടിക്കുന്ന ചോദ്യങ്ങൾക്ക് എക്സിറ്റോ ഉറവിടമോ തിരഞ്ഞെടുക്കുന്നതാണ്. റിസോൾവർ കോൺഫിഗറേഷൻ റഫറൻസ് pfSense-നുള്ള ആ ഓപ്ഷൻ രേഖപ്പെടുത്തുന്നു, മാറ്റത്തിന് മുമ്പ് വായിക്കേണ്ടതാണ്.
ക്രമീകരണത്തിന് മുമ്പ് പരാജയ സ്വഭാവം തിരഞ്ഞെടുക്കുക
ടണൽ വീഴുമ്പോൾ രണ്ട് സ്വഭാവങ്ങൾ സമർത്ഥിക്കാവുന്നതാണ്: ഒന്നും ചോരാതിരിക്കാൻ അപ്സ്ട്രീം ചോദ്യങ്ങൾ നിർത്തുക, അല്ലെങ്കിൽ അറിയാവുന്ന പാതയിലുള്ള അംഗീകൃത റിസോൾവറിലേക്ക് മടങ്ങുക. രണ്ടും നയങ്ങളാണ്, സ്ഥിരസ്ഥിതിയായി ഒന്നും ലഭിക്കുന്നുമില്ല. ഇന്റർഫേസ് പട്ടിക തൊടുന്നതിന് മുമ്പ് നെറ്റ്വർക്കിന് ഏതാണ് വേണ്ടതെന്ന് തീരുമാനിക്കുക.
പരാജയത്തിൽ അടയ്ക്കുന്നത് സമർത്ഥിക്കാൻ എളുപ്പമാണ്, പക്ഷേ അത് ടണൽ വിച്ഛേദത്തെ റൗട്ടറിന് പിന്നിലുള്ള ഓരോ ഉപകരണത്തിനും പേരു നിർണ്ണയ വിച്ഛേദമാക്കി മാറ്റുന്നു. പിൻവാങ്ങൽ ഓഫീസിനെ ഉപയോഗയോഗ്യമായി നിർത്തുന്നു, പക്ഷേ ടണലിന് പുറത്തുള്ള അപ്സ്ട്രീം കൈമാറ്റത്തിന്റെ വിലയ്ക്ക്, അത് ആകസ്മികമല്ല, ബോധപൂർവം സ്വീകാര്യമായിരിക്കണം. തിരഞ്ഞെടുപ്പ് എഴുതിവയ്ക്കുക, കാരണം VPN-ന് പുറത്ത് റിസോൾവർ വിലാസം കാണുന്ന അടുത്ത വ്യക്തി കുറിപ്പ് വേറെ പറയുന്നില്ലെങ്കിൽ അത് ചോർച്ചയായി വായിക്കും. ആ കുറിപ്പാണ് രേഖപ്പെടുത്തിയ പിൻവാങ്ങലിനെ അടുത്ത പാദത്തിലെ അവലോകനത്തിലുള്ള വിശദീകരിക്കാത്ത കണ്ടെത്തലിൽ നിന്ന് വേർതിരിക്കുന്നത്.
രണ്ട് സാഹചര്യങ്ങൾ തീരുമാനം സങ്കീർണ്ണമാക്കുന്നു. സ്വകാര്യ നാമങ്ങൾക്ക് ടണൽ എത്തിച്ചേരാവുന്ന ആന്തരിക റിസോൾവർ വേണ്ടിവരാം, സ്വന്തം എൻക്രിപ്റ്റ് ചെയ്ത DNS ഉള്ള ബ്രൗസറിനോ ആപ്പിനോ റൗട്ടറിനെ പൂർണ്ണമായി ഒഴിവാക്കാം, അതിനാൽ നിങ്ങൾ കോൺഫിഗർ ചെയ്ത റിസോൾവർ എപ്പോഴും ഒരു നിർദ്ദിഷ്ട ആപ്പ് ഉപയോഗിക്കുന്നതല്ല.
രണ്ട് പാതകളും പരിശോധിച്ച് ഫലങ്ങൾ വെവ്വേറെ സൂക്ഷിക്കുക
ബ്രൗസർ അടിസ്ഥാനമാക്കിയ DNS പരിശോധന ഒരു ഇടുങ്ങിയ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ആ പരിശോധനയുടെ സാഹചര്യങ്ങളിൽ ആ ബ്രൗസർ ഏത് റിസോൾവറുകൾ ഉപയോഗിച്ചു. അത് നെറ്റ്വർക്കിലെ ഉപകരണങ്ങൾ കണക്കെടുക്കുന്നില്ല, റൗട്ടർ തനിക്കായി സൃഷ്ടിച്ച ചോദ്യം കാണാനും കഴിയില്ല. അതിന്റെ ഔട്ട്പുട്ടിനെ ഓഡിറ്റല്ല, ഒരു ഡാറ്റാ പോയിന്റായി കാണുക.
LAN ക്ലൈന്റിൽ നിന്ന് റൗട്ടറിനോട് ആദ്യം പൊതു നാമവും, തുടർന്ന് നിങ്ങളുടെ ആന്തരിക മേഖല മാത്രം ഉത്തരം നൽകേണ്ട സ്വകാര്യ നാമവും ചോദിക്കുക. രണ്ടാം ചോദ്യത്തിൽ മാത്രം പരാജയം ടണലല്ല, പേര് ഫോർവേഡിംഗിനെ സൂചിപ്പിക്കുന്നു:
dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lanതുടർന്ന് ടണൽ താഴ്ത്തി രണ്ട് ചോദ്യങ്ങളും ആവർത്തിക്കുക. നിരസിച്ച ഉത്തരങ്ങൾ എന്നാൽ റിസോൾവർ പരാജയത്തിൽ അടയ്ക്കുന്നു; വിജയകരമായ ഉത്തരം പിൻവാങ്ങൽ റിസോൾവറിനെയും അത് ഉപയോഗിച്ച പാതയെയും സൂചിപ്പിക്കുന്നു. അതിനെ നിങ്ങൾ എഴുതിയ കുറിപ്പുമായും അതേ മിനിറ്റിൽ WAN ഇന്റർഫേസിൽ എടുത്ത ക്യാപ്ചറുമായും താരതമ്യം ചെയ്യുക.
രേഖയിൽ നിരീക്ഷണങ്ങൾ വെവ്വേറെ സൂക്ഷിക്കുക: ക്ലൈന്റും റൗട്ടറും തമ്മിലുള്ള കൈമാറ്റം, റൗട്ടറും അപ്സ്ട്രീമും തമ്മിലുള്ള കൈമാറ്റം, രണ്ടാമത്തേത് തീരുമാനിച്ച കോൺഫിഗറേഷൻ. പിന്നീടുള്ള റൂട്ടിംഗ് മാറ്റം ആ രണ്ടാം കൈമാറ്റം മുന്നറിയിപ്പില്ലാതെ പ്രവർത്തിപ്പിക്കും. VPN എൻഡ്പോയിന്റല്ലാത്ത ഇടത്തുനിന്ന് വരുന്ന ഉത്തരം സ്വയം ചോർച്ചയല്ല; കോൺഫിഗറേഷൻ ആ പാത ആകസ്മികമായി തിരഞ്ഞെടുത്തപ്പോൾ മാത്രമാണ് അത് ചോർച്ചയാകുന്നത്.