ട്രാഫിക് യഥാർത്ഥത്തിൽ VPN വഴി പോകുന്നുണ്ടോ? അത് എങ്ങനെ പരിശോധിക്കാം
റൂട്ട് അന്വേഷണം, ആദ്യ ഹോപ്പ്, ഫിസിക്കൽ അഡാപ്റ്ററിലെ ക്യാപ്ചർ, പുറത്തുനിന്നുള്ള വിലാസ പരിശോധന — ഇവ ചോദ്യത്തിന്റെ വ്യത്യസ്ത ഭാഗങ്ങൾക്ക് ഉത്തരം നൽകുന്നു.
ട്രേ ഐക്കണിൽ നിന്ന് രണ്ട് പരാജയങ്ങൾ ഒരുപോലെ കാണാം: ടണലിലേക്ക് കയറുന്ന ട്രാഫിക്കും അതിനെ നിശ്ശബ്ദമായി ഒഴിവാക്കി പോകുന്ന ട്രാഫിക്കും. രണ്ട് സാഹചര്യങ്ങളിലും ക്ലയന്റ് Connected കാണിക്കുന്നു, കാരണം Connected എന്നത് ടണൽ ഇന്റർഫേസ് ഉണ്ടെന്നും ക്ലയന്റ് ആവശ്യമുള്ള റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്തുവെന്നും മാത്രം അർത്ഥമാക്കുന്നു. ഒരു ആപ്ലിക്കേഷന്റെ ഒരു പാക്കറ്റ് ആ റൂട്ടുകൾ ഉപയോഗിച്ചുവോ എന്നത് വേറെ ചോദ്യമാണ്, അതിന് സ്റ്റാക്കിന്റെ മറ്റൊരിടത്ത് ഉത്തരം ലഭിക്കും. നാല് അളവുകൾ അതിൽ ഭൂരിഭാഗവും പരിഹരിക്കുന്നു — റൂട്ട് അന്വേഷണം, ആദ്യ ഹോപ്പ്, ഫിസിക്കൽ അഡാപ്റ്ററിലെ ക്യാപ്ചർ, പുറത്തുനിന്നുള്ള നിരീക്ഷണം — സർവറിന്റെ സ്വന്തം സെഷൻ കാഴ്ച ബാക്കിയുള്ളത് ഉൾക്കൊള്ളുന്നു.
പാക്കറ്റ് പോകുന്ന റൂട്ടിൽ നിന്ന് തുടങ്ങുക
റൂട്ടിംഗ് ടേബിൾ തന്നെയാണ് തീരുമാനം, അതിനാൽ മുഴുവൻ വായിച്ച് ഊഹിക്കുന്നതിനുപകരം ഒരു ലക്ഷ്യത്തെക്കുറിച്ച് ചോദിക്കുക. Linux-ൽ, ip route get കേർണൽ തിരഞ്ഞെടുത്ത ഇന്റർഫേസും ഉറവിട വിലാസവും പേരിടുന്നു:
ip route get 203.0.113.10
ip route get 10.20.5.7Windows-ൽ, Find-NetRoute -RemoteIPAddress 203.0.113.10 route print -4 നെക്കാൾ ഉപയോഗപ്രദമാണ്, അതേ കാരണത്താൽ: വിജയിച്ച റൂട്ട് റിപ്പോർട്ട് ചെയ്യുന്നു, നിലവിലുള്ള എല്ലാ റൂട്ടുകളല്ല. എന്നിരുന്നാലും 0.0.0.0 വരിക്കുവേണ്ടി ടേബിൾ ഒരിക്കൽ വായിക്കുക. അവിടെ /1 ജോഡി ഉണ്ടെങ്കിൽ പൂർണ്ണ ടണൽ ക്ലയന്റ് ഡിഫോൾട്ട് റൂട്ട് മാറ്റിയെഴുതി എന്നർത്ഥം: OpenVPN-ന്റെ redirect-gateway def1 ഓപ്ഷൻ ടണലിലൂടെ 0.0.0.0/1, 128.0.0.0/1 ഇൻസ്റ്റാൾ ചെയ്യുന്നു, അത് ഫിസിക്കൽ ഡിഫോൾട്ട് ഇല്ലാതാക്കാതെ ഏറ്റവും നീളമുള്ള പ്രിഫിക്സ് പൊരുത്തത്തിൽ നിലവിലുള്ള 0.0.0.0/0 നെ തോൽപ്പിക്കുന്നു. അതുകൊണ്ടാണ് രണ്ട് ഡിഫോൾട്ട് റൂട്ടുകൾ ഒരുമിച്ച് നിൽക്കാമെന്നത്, എല്ലാം ഇപ്പോഴും ടണലിലേക്ക് പോകുമ്പോൾ.
രണ്ട് വിശദാംശങ്ങൾ ടേബിളിനെ കള്ളനാക്കുന്നു. ഒന്നാമതായി, ഡിഫോൾട്ട് റൂട്ടുകളുടെ എണ്ണമല്ല, പൊരുത്തപ്പെട്ട പ്രിഫിക്സ് നോക്കുക, കാരണം ഇന്റർഫേസ് മെട്രിക് അല്ലെങ്കിൽ /1 ജോഡിയാണ് വിജയിയെ നിർണ്ണയിക്കുന്നത്. രണ്ടാമതായി, ഇതിനകം നിലവിലുള്ള കണക്ഷൻ സ്ഥാപിച്ച വഴി നിലനിർത്തുന്നു; ടണൽ ഉയർന്നതിനുശേഷം തുറന്ന സെഷൻ പുനഃസജ്ജീകരിക്കുന്നതുവരെ പഴയ റൂട്ട് ഉപയോഗിച്ചേക്കാം, അതുകൊണ്ടാണ് വീണ്ടും കണക്ട് ചെയ്യുന്നത് റൂട്ടിംഗ് പ്രശ്നം പരിഹരിച്ചതായി തോന്നുന്നത്. പ്രവർത്തിക്കുന്ന ക്ലയന്റ് — ps ax | grep openvpn — പ്രോസസ് തുടങ്ങിയെന്ന് മാത്രം തെളിയിക്കുന്നു.
ഒരു ആന്തരികവും ഒരു പൊതുവായതുമായ പേര് പിന്തുടരുക
റൂട്ട് അന്വേഷണം ഉദ്ദേശ്യം കാണിക്കുന്നു; വഴി വിതരണം കാണിക്കുന്നു. കണക്ട് ചെയ്തിരിക്കുമ്പോൾ ആന്തരികമായിരിക്കേണ്ട ഒരു പേരും ആകരുതാത്ത ഒരു പേരും പിന്തുടർന്ന് ആദ്യ ഹോപ്പ് താരതമ്യം ചെയ്യുക:
traceroute intranet.corp.example
traceroute 1.1.1.1രണ്ടിനും ഒരേ ആദ്യ ഹോപ്പ് എന്നാൽ ആന്തരിക പേര് ഒരിക്കലും ടണലിൽ കടന്നിട്ടില്ല, തകരാർ അതിന് മുകളിലാണ്, സാധാരണയായി പൊതു വിലാസത്തിലേക്ക് പരിഹരിക്കുന്ന പേരോ ഒരിക്കലും ഇൻസ്റ്റാൾ ചെയ്യാത്ത റൂട്ടോ. ആന്തരിക ട്രാഫിക് 10.8.0.1 വഴിയും പൊതു ട്രാഫിക് 192.168.1.1 വഴിയും പോകുന്നെങ്കിൽ, സ്പ്ലിറ്റ് ടണലിംഗ് അതിനായി കോൺഫിഗർ ചെയ്തത് കൃത്യമായി ചെയ്യുന്നു. VPN ഗേറ്റ്വേയിൽ എത്തി പിന്നീട് ടൈംഔട്ടുകൾ മാത്രം തിരികെ നൽകുന്ന ട്രെയ്സ് സാധാരണയായി റിട്ടേൺ പാത്ത് അല്ലെങ്കിൽ സർവർ ഫയർവാൾ പ്രശ്നമാണ്, കാണാത്ത ഫോർവേഡ് റൂട്ടല്ല.
ഫിൽട്ടർ ചെയ്ത ICMP ഈ പരിശോധനയെ കള്ളനാക്കുന്നു: രണ്ട് ട്രെയ്സുകളിലും നക്ഷത്രങ്ങൾ മരിച്ച ടണൽ പോലെ തോന്നുന്നു, സാധാരണയായി അത് ഫയർവാൾ ആണ്. കഴിയുന്നിടത്ത് TCP പോർട്ട് പരിശോധിക്കുക — Linux-ൽ traceroute -T -p 443 — ട്രെയ്സ് ഏത് റിസോൾവർ ഉത്തരം നൽകി എന്ന് പറയുന്നില്ല എന്ന് ഓർക്കുക: ഒരു പേര് പ്രാദേശികമായി പരിഹരിക്കപ്പെട്ട് ടണൽ വഴിയും എത്താനാകും.
ടണലിൽ അല്ല, ഫിസിക്കൽ അഡാപ്റ്ററിൽ ക്യാപ്ചർ ചെയ്യുക
നെറ്റ്വർക്ക് യഥാർത്ഥത്തിൽ എന്ത് കാണുന്നു എന്ന് കാണിക്കുന്ന ഏക സ്ഥലം ഫിസിക്കൽ ലിങ്ക് ആണ്. ടണൽ ഉയർന്നിരിക്കുമ്പോൾ ഓഫീസിലേക്കുള്ള സെഷൻ VPN സർവറിനെ ലക്ഷ്യമിട്ട എൻക്രിപ്റ്റ് ചെയ്ത പേലോഡായി കാണണം, 10.20.5.7 ലേക്കുള്ള കണക്ഷനായി അല്ല:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5ആദ്യ ഫിൽട്ടർ പ്രാദേശികമായി പുറത്തുപോകുന്ന പേര് പരിഹരണം പിടിക്കുന്നു, അതാണ് ഏറ്റവും സാധാരണവും ഏറ്റവും നിശ്ശബ്ദവുമായ ചോർച്ച — പേജ് ഇപ്പോഴും ലോഡ് ചെയ്യുന്നു, റിസോൾവർ ചോദ്യം കണ്ടു മാത്രം. രണ്ടാമത്തേത് ടണലിനുള്ളിൽ മാത്രം നിലനിൽക്കേണ്ട ആന്തരിക വിലാസത്തിലേക്കുള്ള സാധാരണ ട്രാഫിക് പിടിക്കുന്നു. Windows-ൽ, pktmon ഡ്രൈവർ ഇല്ലാതെ അതേ ജോലി ചെയ്യുന്നു: pktmon filter add -p 53, പിന്നെ pktmon start --capture --pkt-size 128, പിന്നെ pktmon stop ഉം pktmon format pktmon.etl -o capture.txt ഉം. ഈ ഫ്ലാഗുകൾ Windows ബിൽഡുകൾക്കിടയിൽ അൽപം വ്യത്യാസപ്പെടുന്നു, അതിനാൽ സിന്റാക്സ് വിശ്വസിക്കുന്നതിന് മുമ്പ് pktmon filter add /? പരിശോധിക്കുക.
ചോർച്ചകൾ കണ്ടെത്താൻ ഫിസിക്കൽ ഇന്റർഫേസിൽ ക്യാപ്ചർ ചെയ്യുക; ടണലിലെ ക്യാപ്ചർ നിങ്ങൾ ഇതിനകം അവിടെ ഉണ്ടെന്ന് വിശ്വസിക്കുന്ന പാക്കറ്റുകൾ ഉൾക്കൊള്ളുന്നു, സർവറിൽ അത് ഉറവിടം ഗേറ്റ്വേ ആയ വായിക്കാനാകാത്ത പുറം പാക്കറ്റുകൾ ഉൾക്കൊള്ളുന്നു. ഏത് ഇന്റർഫേസിലെയും ബൈറ്റ് കൗണ്ടറുകൾ പാക്കറ്റുകളെ വിവരിക്കുന്നു, പ്രോഗ്രാമുകളെയല്ല; ട്രാഫിക് ഒരു പ്രോസസ്സിന് ആരോപിക്കാൻ സോക്കറ്റുകളെ പ്രോസസ്സുകളുമായി ബന്ധിപ്പിക്കുന്ന മോണിറ്റർ വേണം.
ഒരു ബാഹ്യ സേവനത്തോട് ചോദിക്കുക, പിന്നെ ഓരോ ആപ്ലിക്കേഷനും വേണ്ടി വീണ്ടും ചോദിക്കുക
പുറത്തുകടക്കൽ തെളിയിക്കുന്ന ഏക പരിശോധന പുറത്തുനിന്നുള്ള ഉത്തരമാണ്: താൻ കണ്ട ഉറവിട വിലാസം തിരികെ നൽകുന്ന സേവനം. ഇന്റർഫേസ് തിരഞ്ഞെടുക്കാവുന്ന ഒരു ഷെല്ലിൽ നിന്ന് അത് പ്രവർത്തിപ്പിക്കുക, രണ്ടുതവണ പ്രവർത്തിപ്പിക്കുക:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipവ്യത്യസ്ത ഉത്തരങ്ങൾ രണ്ട് വഴികളുടെയും തെളിവും ഒരു നിർദ്ദിഷ്ട ആപ്ലിക്കേഷൻ പരിശോധിക്കാനുള്ള വഴിയും നൽകുന്നു: അത് ബൈൻഡ് ചെയ്യുക, അല്ലെങ്കിൽ ഒരു റൂട്ട് മാത്രമുള്ള നെറ്റ്വർക്ക് നെയിംസ്പേസിൽ പ്രവർത്തിപ്പിച്ച് ദൂരെയുള്ള അറ്റം ഏത് വിലാസം രേഖപ്പെടുത്തുന്നു എന്ന് നോക്കുക. ഒരേ ഉത്തരങ്ങളാണ് രസകരമായ പരാജയം: ഒന്നുകിൽ ബൈൻഡിംഗ് ഫലിച്ചില്ല, അല്ലെങ്കിൽ ഹോസ്റ്റും ദൂരെയുള്ള അറ്റവും തമ്മിലുള്ള എന്തോ എത്തുന്നതിന് മുമ്പ് ഉറവിട വിലാസം മാറ്റിയെഴുതുന്നു. Windows-ൽ, curl --interface അഡാപ്റ്ററിന്റെ പേരല്ല, വിലാസമാണ് ആവശ്യപ്പെടുന്നത്.
VPN വിലാസം റിപ്പോർട്ട് ചെയ്യുന്ന ബ്രൗസർ ബ്രൗസറിനെ തെളിയിക്കുന്നു. മെയിൽ ക്ലയന്റ്, പാക്കേജ് മാനേജർ, ബാക്ക്അപ്പ് ഏജന്റ് അല്ലെങ്കിൽ രണ്ടാമത്തെ ബ്രൗസർ പ്രൊഫൈൽ എന്നിവയ്ക്ക് ഓരോന്നിനും വ്യത്യസ്ത വഴി സ്വീകരിക്കാം, പ്രത്യേകിച്ച് ഒരു പ്രോക്സി ക്രമീകരണമോ സ്പ്ലിറ്റ്-ടണൽ റൂട്ടോ അവയിലൊന്നിനെ മൂടുമ്പോൾ. വിലാസ മാറ്റം അതിൽത്തന്നെ ചോർച്ചയുടെ തെളിവല്ല: ലോഡ് ബാലൻസർ കണ്ട എഗ്രെസ് അനുസരിച്ച് വ്യത്യസ്തമായി ഉത്തരം നൽകാം, അതിനാൽ പേജല്ല, രേഖപ്പെടുത്തിയ ഉറവിട വിലാസം താരതമ്യം ചെയ്യുക.
പിയർ സ്ഥിരീകരിക്കാൻ സർവർ കാഴ്ച ഉപയോഗിക്കുക
സർവർ മറ്റൊരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: പിയർ കണക്ട് ചെയ്തിട്ടുണ്ടോ, എത്ര കൊണ്ടുപോയി, സെഷൻ പുനരാരംഭിച്ചോ. സർവറിൽ പിയർ സജീവമായിരിക്കുമ്പോൾ ക്ലയന്റ് കൗണ്ടറുകൾ കേവലം നീങ്ങുന്നില്ലെങ്കിൽ, ക്ലയന്റ് ടേബിൾ എന്ത് പറഞ്ഞാലും ആപ്ലിക്കേഷൻ ട്രാഫിക് ടണലിൽ കടക്കുന്നില്ല എന്നർത്ഥം. ഒന്നും പ്രവർത്തിക്കുന്നില്ല എന്ന് പറയുന്ന ഉപയോക്താവിന് ധാരാളം ഡാറ്റ നീക്കുന്ന പിയർ മറ്റൊരു അന്വേഷണമാണ്.
ഇവിടെ രണ്ട് കെണികളുണ്ട്. മാസ്കറേഡ് ചെയ്ത ടണൽ ഓരോ ഫ്ലോയും ഗേറ്റ്വേയിൽ നിന്ന് വന്നതായി കാണിക്കുന്നു, അതിനാൽ ലോഗുകളും ഓരോ ക്ലയന്റിന്റെയും അക്കൗണ്ടിംഗും ഒരു വിലാസത്തിൽ ചുരുങ്ങുന്നു. ക്ലയന്റിനെ പ്രാദേശിക ഹോസ്റ്റായി കണക്കാക്കുന്നു, അതിനാൽ ആരെങ്കിലും VPN വഴി ഫയലുകൾ പകർത്തുന്നുണ്ടോ എന്ന ചോദ്യത്തിന് സർവറിലെ ഫയൽ പങ്കിടൽ ട്രാഫിക്കോ സർവറിലെ ഹോസ്റ്റ് ഓഡിറ്റോ ഉത്തരം നൽകുന്നു — ടണൽ നിരീക്ഷിക്കുന്നത് അറ്റങ്ങളും അളവും നൽകുന്നു, ഫയൽ പേരുകളല്ല.
ഡിസൈൻ തീരുമാനത്തെ ചോർച്ചയിൽ നിന്ന് വേർതിരിക്കുക
ടണലിന് പുറത്തുള്ളതെല്ലാം ചോർച്ചയല്ല. ലിങ്ക്-ലോക്കൽ, ബ്രോഡ്കാസ്റ്റ് ട്രാഫിക് ഡിസൈൻ പ്രകാരം പ്രാദേശികമായി തുടരുന്നു, മൾട്ടികാസ്റ്റ് വഴി കണ്ടെത്തിയ പ്രിന്റർ LAN-ൽ പ്രഖ്യാപനം തുടരുന്നു, DHCP പ്രാദേശികമായി പുറത്തുപോകണം. ഒരു നിർദ്ദിഷ്ട ഇന്റർഫേസിലേക്ക് ബൈൻഡ് ചെയ്ത ആപ്ലിക്കേഷൻ മനഃപൂർവം റൂട്ടിംഗ് ടേബിൾ ഒഴിവാക്കുന്നു, ഫയർവാൾ നിയമമോ നെയിംസ്പേസോ പോളിസി റൂട്ടോ മാത്രമാണ് അത് മാറ്റുന്നത്.
IPv6-ന് ചെക്ക്ലിസ്റ്റിൽ സ്വന്തം വരി അർഹതയുണ്ട്. IPv4 മാത്രം വഹിക്കുന്ന ടണൽ ഡ്യുവൽ-സ്റ്റാക്ക് ഹോസ്റ്റിന് രണ്ടാമത്തെ ഉപയോഗയോഗ്യമായ വഴി വിടുന്നു, ഡ്യുവൽ-സ്റ്റാക്ക് ലക്ഷ്യം അതിനെ മുൻഗണന നൽകും — DNS ഉൾപ്പെടെ, റിസോൾവർ IPv6 വഴി എത്താനാകുമെങ്കിൽ. IPv4 ഫലം പൂർണ്ണമായി കണക്കാക്കുന്നതിന് മുമ്പ് അഡാപ്റ്ററിൽ IPv6 പ്രവർത്തനരഹിതമാക്കുകയോ ടണൽ അത് വഹിക്കുന്നുവെന്ന് ഉറപ്പാക്കുകയോ ചെയ്യുക.
പരിശോധനകൾ യോജിക്കാതിരിക്കുമ്പോൾ, ആ വ്യത്യാസമാണ് സാധാരണയായി തകരാറിനെ പേരിടുന്നത്:
| What you see | What it means | Next step |
|---|---|---|
| The route picks tun0 but the capture shows cleartext to 10.20.5.7 | Something bypassed the table: a bound app, a policy route or a session older than the tunnel | Reset the flow, check the app bind, check the ip rule list |
| The route picks eth0 for an internal name | The name resolves to a public address, or the route was never installed | Compare the resolved address with the routes the server pushes |
| The capture shows DNS to the LAN resolver | Resolver leak: data is tunneled, lookups are not | Point the resolver inside, or push it from the server |
| All four checks agree and one app still fails | Path selection is fine; suspect MTU, a per-app proxy or the far end | Test the same destination from a known-good client |
പ്രവർത്തിക്കുന്ന ക്രമം: കണക്ട് ചെയ്യുന്നതിന് മുമ്പും ശേഷവും റൂട്ടിംഗ് ടേബിൾ സംരക്ഷിക്കുക, ഒരു ആന്തരികവും ഒരു പൊതുവായതുമായ പേര് പിന്തുടരുക, ഫിസിക്കൽ അഡാപ്റ്ററിൽ DNS ക്യാപ്ചർ ചെയ്യുക, നിർദ്ദിഷ്ട ആപ്ലിക്കേഷന് വേണ്ടി ഷെല്ലിൽ നിന്ന് എക്സിറ്റ് വിലാസം തിരികെ നൽകുക, പിന്നെ അളവിനായി സർവർ വായിക്കുക. ആദ്യ നാലെണ്ണം യോജിച്ചാൽ, ടണൽ നിങ്ങൾ കരുതുന്നത് വഹിക്കുന്നു, ബാക്കിയുള്ള പ്രശ്നം അതിന് മുകളിലാണ്. അവയിൽ രണ്ടെണ്ണം യോജിക്കുന്നില്ലെങ്കിൽ, യോജിക്കാത്ത ജോഡിയാണ് തകരാർ, ഐക്കണല്ല.