റൂട്ടിംഗ് ടേബിളും യഥാർത്ഥ തിരയലും: VPN ട്രാഫിക് എവിടേക്ക് പോകുന്നു
ഒരു ലക്ഷ്യസ്ഥാനവും അതിന്റെ ഉറവിടവും മുതൽ തുടങ്ങി, ഏത് നിയമവും ടേബിളും യഥാർത്ഥത്തിൽ പാത നിർണ്ണയിക്കുന്നു എന്ന് പരിശോധിക്കുക. ആ സന്ദർഭമില്ലാതെ മുഴുവൻ ടേബിൾ ഡംപ് തെറ്റിദ്ധരിപ്പിക്കുന്നു.
റൂട്ടിംഗ് ടേബിളിന്റെ ഡംപ് VPN പ്രശ്നപരിഹാരത്തിൽ ഏറ്റവും ഉപയോഗപ്രദമല്ലാത്ത ഡയഗ്നോസ്റ്റിക് ആണ്, ഏറ്റവും കൂടുതൽ പേസ്റ്റ് ചെയ്യപ്പെടുന്നതും. നാല്പത് വരികളിലെ പ്രിഫിക്സുകൾ യന്ത്രത്തിന് എന്ത് ചെയ്യാമായിരുന്നു എന്ന് പറയുന്നു, പരാജയപ്പെട്ട അഭ്യർത്ഥനയ്ക്ക് എന്ത് ചെയ്തു എന്നല്ല. യഥാർത്ഥത്തിൽ വേണ്ട മെക്കാനിസം തിരയലാണ്: ഈ ഉറവിടവും ഈ ലക്ഷ്യസ്ഥാനവും നൽകുമ്പോൾ ഏത് നിയമം പൊരുത്തപ്പെട്ടു, ഏത് ടേബിൾ പരിശോധിച്ചു, ഏത് ഇന്റർഫേസും അടുത്ത ഹോപ്പും പുറത്തുവന്നു. ഒരു ലക്ഷ്യസ്ഥാനവും ഒരു ഉറവിടവും മുതൽ തുടങ്ങി, ആ ചോദ്യം കൈയിൽ പിടിച്ച് ടേബിൾ വായിക്കുക, അപ്പോൾ അതേ ഔട്ട്പുട്ട് ബഹളത്തിന് പകരം തെളിവാകുന്നു.
ടേബിൾ സ്ഥാനാർത്ഥികളുടെ ഒരു കൂട്ടമാണ്, തീരുമാനമല്ല
ഓരോ എൻട്രിയും ഒരു പ്രിഫിക്സും അതിനോട് യോജിക്കുന്ന ട്രാഫിക്കിനോട് എന്ത് ചെയ്യണം എന്നും വിവരിക്കുന്നു: അത് ഒരു ഇന്റർഫേസിലേക്ക് അയക്കുക, അടുത്ത ഹോപ്പിന് കൈമാറുക, അല്ലെങ്കിൽ ഉപേക്ഷിക്കുക. ആ പട്ടികയിൽ ഒന്നും ഉദ്ദേശ്യപ്രകാരം ക്രമീകരിച്ചിട്ടില്ല, മനുഷ്യന് ഏറ്റവും നിർദ്ദിഷ്ടമായി തോന്നുന്ന എൻട്രി എപ്പോഴും കെർണൽ തിരഞ്ഞെടുക്കുന്നതല്ല, കാരണം തിരഞ്ഞെടുപ്പ് ഏറ്റവും നീളമുള്ള പ്രിഫിക്സ് പൊരുത്തത്തെയും തുല്യ പ്രിഫിക്സുകൾക്കിടയിൽ മെട്രിക്കിനെയും പിന്തുടരുന്നു.
അതിനാൽ ആദ്യ ചുവട് പട്ടിക വായിക്കുന്നതിന് പകരം കെർണലിനോട് ചോദിക്കുകയാണ്. തിരയൽ കമാൻഡ് ഒരു ലക്ഷ്യസ്ഥാനത്തിന് ഉത്തരം നൽകുന്നു, ഉറവിട ആർഗ്യുമെന്റിനൊപ്പം ഫോർവേഡ് ചെയ്തതോ ബൗണ്ട് ചെയ്തതോ ആയ കണക്ഷൻ ഉപയോഗിക്കുന്ന കൃത്യമായ ജോടിക്ക് ഉത്തരം നൽകുന്നു:
ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40
മുകളിലെ ഓരോ വിലാസവും ഡോക്യുമെന്റേഷൻ ഉദാഹരണമാണ്. കാര്യം ഉത്തരത്തിന്റെ രൂപമാണ്: ഇന്റർഫേസ്, തിരഞ്ഞെടുത്ത ഉറവിട വിലാസം, ഗേറ്റ്വേ, എൻട്രി വന്ന ടേബിൾ. ആ ഔട്ട്പുട്ട് നിങ്ങൾ പ്രതീക്ഷിച്ച ഇന്റർഫേസുമായി പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, ഒരു കമാൻഡിൽ പ്രശ്നം കണ്ടെത്തിയിരിക്കുന്നു, മുഴുവൻ ടേബിളും എത്ര വായിച്ചാലും ഏത് സ്ഥാനാർത്ഥി വിജയിച്ചു എന്ന് പറയില്ലായിരുന്നു.
തിരയൽ ആദ്യം നിയമങ്ങളിലൂടെ, പിന്നീട് ടേബിളുകളിലൂടെ പോകുന്നു
Linux-ൽ തീരുമാനം രണ്ട് ഘട്ടത്തിലാണ്. നയ നിയമങ്ങൾ മുൻഗണനാ ക്രമത്തിൽ വിലയിരുത്തപ്പെടുന്നു, ആദ്യം പൊരുത്തപ്പെടുന്ന നിയമം പരിശോധിക്കേണ്ട ടേബിൾ പേര് നൽകുന്നു; ആ ടേബിൾ പിന്നീട് ഏറ്റവും നീളമുള്ള പ്രിഫിക്സ് പൊരുത്തം നടത്തുന്നു. നിയമം ഉറവിടം, ലക്ഷ്യസ്ഥാനം, ഫയർവാൾ മാർക്ക്, ഇന്റർഫേസ് അല്ലെങ്കിൽ അവയുടെ സംയോജനം എന്നിവയിൽ പൊരുത്തപ്പെടാം, അതിനാൽ പ്രധാന ടേബിളിന്റെ ഡംപ് പൂർണ്ണമായും കൃത്യവും നിങ്ങൾ അന്വേഷിക്കുന്ന പാക്കറ്റിന് പൂർണ്ണമായും അപ്രസക്തവുമാകാം.
ip rule show
ip route show table all | head -40
ip route show table 100
ഒരു നിയമം നിങ്ങളുടെ VPN പൂളിൽ നിന്നുള്ള ട്രാഫിക്കിനെ ടേബിൾ 100-ലേക്ക് അയക്കുന്നുവെങ്കിൽ, പ്രധാനമായത് ടേബിൾ 100 ആണ്, കൂടാതെ പ്രധാന ടേബിൾ ഒരു പ്രലോഭനമാണ്. റൗട്ടറിലെ ഉറവിടാധിഷ്ഠിത റൂട്ടിംഗിന്റെ പിന്നിലെ മെക്കാനിസവും ഇതാണ്: ഒരേ ലക്ഷ്യസ്ഥാനത്തിന് പാക്കറ്റ് എവിടെ നിന്ന് വന്നു എന്നതിന് അനുസരിച്ച് രണ്ട് വ്യത്യസ്ത ഉത്തരങ്ങൾ ഉണ്ടാകാം, ഉറവിട ആർഗ്യുമെന്റുള്ള തിരയൽ മാത്രം ഏതാണ് ബാധകമെന്ന് വെളിപ്പെടുത്തുന്നു.
IPv6-ന് സ്വന്തം നിയമങ്ങളും ടേബിളുകളുമുണ്ട്. രണ്ട് കുടുംബങ്ങളും പ്രവർത്തിപ്പിക്കുന്ന രൂപകൽപ്പനയ്ക്ക് രണ്ട് തിരയലുകളും വേണം, പ്രവർത്തിക്കുന്ന IPv4 ഉത്തരം ഡ്യുവൽ-സ്റ്റാക്ക് ക്ലയന്റ് ഇഷ്ടപ്പെട്ടേക്കാവുന്ന v6 പാതയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
VPN ക്ലയന്റ് എന്ത് ഇൻസ്റ്റാൾ ചെയ്യുന്നു
ക്ലയന്റുകൾ സാധാരണയായി ഡിഫോൾട്ട് റൂട്ട് മാറ്റിസ്ഥാപിക്കുന്നില്ല, അത് ചെയ്താൽ ടണലിന്റെ സ്വന്തം പുറം പാത തകരും. പ്രിഫിക്സ് നീളത്തിൽ വിജയിക്കുന്ന കൂടുതൽ നിർദ്ദിഷ്ടമായ എന്തെങ്കിലും അവർ ഇൻസ്റ്റാൾ ചെയ്യുന്നു: 0.0.0.0/1, 128.0.0.0/1 എന്നിവ ഉൾക്കൊള്ളുന്ന പകുതി-ഡിഫോൾട്ട് ജോടി ക്ലാസിക് തന്ത്രമാണ്, കാരണം രണ്ടും 0.0.0.0/0-നേക്കാൾ നീളമുള്ള പ്രിഫിക്സുകളാണ്, ഒരുമിച്ച് മുഴുവൻ സ്ഥലവും ഉൾക്കൊള്ളുന്നു. മറ്റുള്ളവർ നിർദ്ദിഷ്ട സ്വകാര്യ പ്രിഫിക്സുകളും ഒരു നയ നിയമവും ഇൻസ്റ്റാൾ ചെയ്യുന്നു, ചിലർ തിരഞ്ഞെടുത്ത ട്രാഫിക് മാത്രം പിടിക്കാൻ ഒരു മാർക്ക് ചേർക്കുന്നു.
അതുകൊണ്ടാണ് "VPN എന്റെ ഡിഫോൾട്ട് റൂട്ട് മാറ്റിയില്ല" പരാജയത്തിന്റെ തെളിവല്ല. അത് യഥാർത്ഥത്തിൽ എന്ത് ചേർത്തു, ബന്ധപ്പെട്ട ലക്ഷ്യസ്ഥാനം ആ പ്രിഫിക്സുകൾക്കുള്ളിൽ വരുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക:
ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25
രണ്ട് പകുതി-റൂട്ടുകൾ ഡംപിൽ എളുപ്പം വിട്ടുപോകുന്നു, കാരണം അവ ഡിഫോൾട്ട് പോലെ തോന്നുന്നില്ല. പ്രിഫിക്സ് ഉൾപ്പെടുത്താൻ മറന്ന സ്പ്ലിറ്റ്-ടണൽ കോൺഫിഗറേഷൻ നിങ്ങൾ പിന്തുടരുന്ന ലക്ഷണം തന്നെ സൃഷ്ടിക്കുന്നു: ടണൽ ഉപയോഗിക്കേണ്ട ആപ്ലിക്കേഷൻ പകരം പ്രാദേശികമായി പരിഹരിച്ച് ബന്ധിപ്പിക്കുന്നു. ഇൻസ്റ്റാൾ ചെയ്ത പ്രിഫിക്സുകളെ ഉപയോക്താവിന് യഥാർത്ഥത്തിൽ വേണ്ട ലക്ഷ്യസ്ഥാനങ്ങളുമായി താരതമ്യം ചെയ്യുക, നിങ്ങൾ യാദൃച്ഛികമായി പരീക്ഷിച്ച വിലാസങ്ങളുമായി അല്ല. ഫയൽ സർവറിനെ ഉൾക്കൊള്ളുന്നുവെങ്കിലും അതിന്റെ റിസോൾവറിനെ ഉൾക്കൊള്ളാത്ത സ്പ്ലിറ്റ്-ടണൽ പട്ടിക പൊതു വിലാസത്തിലേക്ക് പരിഹരിക്കപ്പെട്ട് പിന്നീട് പ്രാമാണീകരണത്തിൽ പരാജയപ്പെടുന്ന ഒരു കണക്ഷൻ സൃഷ്ടിക്കുന്നു, അത് പാസ്വേഡ് പ്രശ്നമായി തോന്നുന്നു, എന്നാൽ റൂട്ട് പ്രശ്നമാണ്.
പുറം റൂട്ടും അതിജീവിക്കണം
ടണൽ തന്നെ ട്രാഫിക്കാണ്. എൻകാപ്സുലേറ്റ് ചെയ്ത പേലോഡ് വഹിക്കുന്ന പാക്കറ്റുകൾ ഭൗതിക ഇന്റർഫേസിലൂടെ പിയറിന്റെ വിലാസത്തിലേക്ക് പോകുന്നു, ആ പാത തിരികെ ടണലിലേക്ക് റൂട്ട് ചെയ്യരുത്. അത് സംഭവിക്കുമ്പോൾ, ടണൽ സ്ഥാപിക്കപ്പെട്ട് പിന്നീട് ട്രാഫിക് കടത്തിവിടുന്നത് നിർത്തുന്ന സവിശേഷമായ പരാജയം ലഭിക്കുന്നു, കാരണം ടണലിന്റെ ഗതാഗതം ഇപ്പോൾ ടണലിനുള്ളിലാണ്.
അകത്തെ ലക്ഷ്യസ്ഥാനം പരിശോധിച്ച അതേ രീതിയിൽ പിയർ വിലാസം പരിശോധിക്കുക, അത് ടണലിലേക്കല്ല, ഭൗതിക ഇന്റർഫേസിലേക്ക് പരിഹരിക്കുന്നു എന്ന് ഉറപ്പാക്കുക:
ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10
പുനരാവർത്തന റൂട്ട്, പിയറിനെ പിടിക്കുന്ന നയ നിയമം, അല്ലെങ്കിൽ പൂർണ്ണ-ടണൽ ക്ലയന്റ് മാറ്റിസ്ഥാപിച്ച ഡിഫോൾട്ട് എന്നിവയാണ് മൂന്ന് സാധാരണ കാരണങ്ങൾ. മൂന്നും പുറം തിരയലിൽ കാണാം, ഒന്നും സംഭവത്തിന് ശേഷം എടുത്ത പ്രധാന ടേബിൾ ഡംപിൽ കാണുന്നില്ല.
റൂട്ടിംഗ് ഔട്ട്പുട്ട് നിങ്ങളോട് എന്ത് പറയാൻ കഴിയില്ല
ശരിയായ തിരയൽ അർത്ഥം കെർണൽ പാക്കറ്റ് എവിടെയെങ്കിലും യുക്തിസഹമായ സ്ഥലത്തേക്ക് അയക്കും എന്നാണ്. ഫയർവാൾ അനുവദിക്കുന്നു, IPsec നയം ഉൾക്കൊള്ളുന്നു, NAT നിയമം വിവർത്തനം ചെയ്യുന്നു, അല്ലെങ്കിൽ വിദൂര വശത്തിന് മടക്ക റൂട്ട് ഉണ്ട് എന്നല്ല. അവയിൽ ഓരോന്നും പിന്നീടുള്ള ഘട്ടമാണ്, കൂടാതെ strongSwan-ന്റെ ഫോർവേഡിംഗ് കുറിപ്പുകൾ പാക്കറ്റ് രണ്ട് അറ്റങ്ങളിലും കടന്നുപോകേണ്ട ശൃംഖല വിവരിക്കുന്നു.
ഇത് ആപ്ലിക്കേഷൻ തലത്തിലെ ബൈൻഡിംഗും പരിഗണിക്കുന്നില്ല. ഒരു പ്രോസസ്സിന് ഇന്റർഫേസിലേക്ക് ബൈൻഡ് ചെയ്യാം, മാർക്ക് സെറ്റ് ചെയ്യാം, അല്ലെങ്കിൽ സ്വന്തം റിസോൾവർ ഉപയോഗിച്ച് നിങ്ങൾ പരീക്ഷിച്ചതിൽ നിന്ന് വ്യത്യസ്തമായി പരിഹരിക്കുന്ന പേരിലൂടെ ബന്ധിപ്പിക്കാം. തിരയൽ ശരിയായിരിക്കുമ്പോഴും കണക്ഷൻ ഇപ്പോഴും പരാജയപ്പെടുമ്പോൾ, അടുത്ത ചോദ്യം ഏത് പ്രോസസ്സ് അത് ചെയ്യുന്നു, ആ പ്രോസസ്സ് നിങ്ങൾ കാണുന്ന അതേ ടേബിൾ കാണുന്നുണ്ടോ എന്നതാണ്.
അതിനാൽ ഡയഗ്നോസിസ് ക്രമത്തിൽ സൂക്ഷിക്കുക: ലക്ഷ്യസ്ഥാനവും ഉറവിടവും പേരിടുക, തിരയൽ പ്രവർത്തിപ്പിക്കുക, തിരയൽ പേരിട്ട ടേബിളും നിയമവും മാത്രം വായിക്കുക, പിന്നീട് അടുത്ത ഘട്ടം പരീക്ഷിക്കുക. ആ ക്രമം റൂട്ടിംഗ് അന്വേഷണത്തെ മിനിറ്റുകൾക്കുള്ളിൽ നിർത്തുന്നു, മറ്റൊരാൾക്ക് പിന്തുടരാവുന്ന ഒരു രേഖ അവശേഷിപ്പിക്കുന്നു, പേസ്റ്റ് ചെയ്ത ടേബിൾ ഒരിക്കലും ചെയ്യാത്തത്.