VPN റൂട്ട് ip route ഔട്ട്പുട്ടിൽ ഗേറ്റ്വേ എന്തുകൊണ്ട് കാണിക്കുന്നില്ല
ഉപകരണമുണ്ടെങ്കിലും ഗേറ്റ്വേയില്ലാത്ത വരി നേരിട്ടുള്ള റൂട്ടാണ്, തകർന്നതല്ല. ലക്ഷ്യം, dev, scope എന്നിവ വായിച്ച്, പിന്നീട് ip route get ഉപയോഗിച്ച് സ്ഥിരീകരിക്കുക.
ഗേറ്റ്വേ കോളം ശൂന്യമാകുമ്പോഴെല്ലാം റൂട്ടിംഗ് പട്ടികകളെ തകർന്നതായി വായിക്കാറുണ്ട്, എന്നാൽ വരി സാധാരണയായി അതിൽത്തന്നെ പൂർണ്ണമാണ്. via ഫീൽഡ് കർണൽ പാക്കറ്റ് അടുത്ത ഹോപ്പിന്റെ വിലാസത്തിന് കൈമാറുമ്പോൾ മാത്രമാണ് പ്രത്യക്ഷപ്പെടുന്നത്; ഇന്റർഫേസിൽ ഘടിപ്പിച്ച റൂട്ട് അതിന്റെ ലക്ഷ്യങ്ങളിലേക്ക് പകരം ലിങ്ക്-പാളി റെസല്യൂഷനിലൂടെയോ പോയിന്റ്-ടു-പോയിന്റ് പങ്കാളിയിലൂടെയോ എത്തുന്നു. കോളങ്ങൾ ഇടത്തുനിന്ന് വലത്തോട്ട് വായിക്കുന്നത് നിങ്ങൾ ഏത് സാഹചര്യത്തിലാണെന്ന് പറയുന്നു, ആ വായന ആരെങ്കിലും ഡിഫോൾട്ട് റൂട്ട് എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് നടക്കണം. കാണാതായ ഗേറ്റ്വേയെക്കുറിച്ചുള്ള മിക്ക ടിക്കറ്റുകളും ഈ വ്യത്യാസത്തിൽ അവസാനിക്കുന്നു.
ഒരു റൂട്ട് വരി കോളം തോറും വായിക്കുക
ഓരോ എൻട്രിയും ലക്ഷ്യത്തോടും അതിന്റെ പ്രിഫിക്സ് നീളത്തോടും തുടങ്ങി, പിന്നീട് സ്ഥിരമായ പദാവലിയിൽ മാറ്റങ്ങൾ ചേർക്കുന്നു: via, dev, proto, scope, src എന്നിവയും metric യും. 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 പോലുള്ള ഒരു വരി സാന്ദ്രമാണ്, പക്ഷേ പൂർണ്ണമായി നിർദ്ദിഷ്ടമാണ്. അതിൽ ഒന്നും വിട്ടുപോയിട്ടില്ല, റൂട്ടർ വിലാസവും സൂചിപ്പിച്ചിട്ടില്ല.
താൽപ്പര്യമുള്ള ഭാഗം via ഇല്ലാത്തതാണ്. അടുത്ത ഹോപ്പ് ഇല്ലെങ്കിൽ, കർണൽ ലക്ഷ്യം നേരിട്ട് പേരിട്ട ഇന്റർഫേസിൽ പരിഹരിക്കുന്നു, ഇത് ഒരു ടണലിന് ഫ്രെയിം ടണൽ ഉപകരണത്തിന് കൈമാറി എൻക്യാപ്സുലേഷനെ അവിടെനിന്ന് ഏറ്റെടുക്കാൻ അനുവദിക്കുന്നു എന്നാണ് അർത്ഥം. വിലാസം അനുവദിക്കുമ്പോൾ എൻട്രി സ്വയമേവ ഇൻസ്റ്റാൾ ചെയ്യപ്പെട്ടു എന്ന് proto kernel രേഖപ്പെടുത്തുന്നു, അഡ്മിൻ ടൈപ്പ് ചെയ്തതല്ല. ആ ലിങ്കിൽ റൂട്ടർ വഴി പോകാതെ ലക്ഷ്യം എത്താമെന്ന് scope link പറയുന്നു, കൂടാതെ പൊരുത്തപ്പെടുന്ന ട്രാഫിക്കിന്റെ ഉറവിടമായി കർണൽ മുൻഗണന നൽകുന്ന വിലാസം src നാമകരണം ചെയ്യുന്നു.
ഇപ്പോൾ ഡിഫോൾട്ട് റൂട്ടും അതേ രീതിയിൽ വായിക്കുക: default via 192.0.2.254 dev eth0 proto static metric 100. ഇവിടെ via ഉണ്ട്, കാരണം പാക്കറ്റിന് യഥാർത്ഥത്തിൽ അടുത്ത ഹോപ്പ് ആവശ്യമാണ്, ആ ഹോപ്പ് തന്നെ eth0 ൽ എത്താവുന്നതായിരിക്കണം. ആ രണ്ട് വരികളും പരസ്പരം ഭേദഗതികളല്ല; ട്രാഫിക് എവിടേക്ക് പോകുന്നു എന്നതിനെക്കുറിച്ചുള്ള വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് അവ ഉത്തരം നൽകുന്നു.
പരസ്പരം കൂട്ടിക്കുഴയ്ക്കുന്ന രണ്ട് റൂട്ട് രൂപങ്ങൾ
ടണൽ സബ്നെറ്റ് റൂട്ടും ഡിഫോൾട്ട് റൂട്ടും സ്ക്രീൻഷോട്ടിൽ സമാനമായി കാണപ്പെടുന്നു, പക്ഷേ തികച്ചും വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു. ഫീൽഡുകൾ വായിക്കാനുള്ള സഹായമായി താഴെയുള്ള പട്ടിക ഉപയോഗിക്കുക, പിന്നീട് ഒരു ഗൈഡിലെ മാതൃക വിശ്വസിക്കുന്നതിനുപകരം നിങ്ങൾ ഡീബഗ് ചെയ്യുന്ന മെഷീനിൽ യഥാർത്ഥ സംഖ്യകൾ സ്ഥിരീകരിക്കുക.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
പട്ടിക പറയാൻ കഴിയാത്തത് ഉദ്ദേശ്യമാണ്. ടണലിലൂടെ സ്വകാര്യ ശ്രേണിയിലേക്കുള്ള നേരിട്ടുള്ള റൂട്ട് ബോധപൂർവമായ വിഭജിത ടണൽ രൂപകൽപ്പനയാണ്; എല്ലാം VPN വഴി അയക്കേണ്ട ഹോസ്റ്റിൽ അതേ രൂപം പ്രത്യക്ഷപ്പെടുന്നത് ലക്ഷണമാണ്. ഉദ്ദേശ്യം എൻട്രി സൃഷ്ടിച്ച കോൺഫിഗറേഷനിൽ ജീവിക്കുന്നു, അതിനാൽ കർണൽ എന്തെങ്കിലും തെറ്റ് ചെയ്തു എന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് അത് ഇൻസ്റ്റാൾ ചെയ്ത ഉപകരണം നോക്കുക.
അതുപോലെ, കാണാതായ ഗേറ്റ്വേ ഒന്ന് കെട്ടിച്ചമയ്ക്കാനുള്ള അനുമതിയല്ല. ഒരു റൂട്ടിന് യഥാർത്ഥത്തിൽ അടുത്ത ഹോപ്പ് ആവശ്യമുണ്ടെങ്കിൽ, ആ ഹോപ്പ് അത് വഹിക്കുന്ന ഇന്റർഫേസിൽ എത്താവുന്നതായിരിക്കണം, പോയിന്റ്-ടു-പോയിന്റ് ടണലിന് പങ്കാളിയുടെ വിലാസം പ്രാദേശിക വിലാസത്തിന്റെ അതേ വസ്തുവല്ല. പ്രാദേശിക ടണൽ വിലാസത്തെ ഇഥർനെറ്റ് റൂട്ടറായി കണക്കാക്കുന്നത് ശരിയായി തോന്നുന്നതും ഒന്നും കൈമാറാത്തതുമായ ഒരു റൂട്ട് സൃഷ്ടിക്കാനുള്ള സാധാരണ മാർഗമാണ്.
കർണലിനോട് യഥാർത്ഥത്തിൽ ഏത് വരി ഉപയോഗിക്കുമെന്ന് ചോദിക്കുക
പട്ടിക വായിക്കുന്നത് തിരയൽ നടത്തുന്നതിന് തുല്യമല്ല, കാരണം ഉത്തരം നൽകുന്നതിന് മുമ്പ് കർണൽ നയ നിയമങ്ങൾ, നിരവധി പട്ടികകൾ, കാഷ് ചെയ്ത എൻട്രികൾ എന്നിവയുമായി ആലോചിക്കുന്നു. യഥാർത്ഥ തിരയൽ നടത്തുന്ന ക്രിയ ip route get ആണ്, അത് ആ ഗുണങ്ങളുള്ള പാക്കറ്റ് സ്വീകരിക്കുന്ന റൂട്ട് അച്ചടിക്കുന്നു.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ പ്രധാനമായ ലക്ഷ്യം ഇട്ട്, പിന്നീട് ട്രാഫിക് ഉറവിടത്തിന്റെ അടിസ്ഥാനത്തിൽ തിരഞ്ഞെടുക്കുകയോ കൈമാറുകയോ ചെയ്യുമ്പോൾ from അല്ലെങ്കിൽ iif ചേർക്കുക, കാരണം സാധാരണ പ്രാദേശിക തിരയൽ കൈമാറുന്ന ക്ലയന്റിൽ നിന്ന് വ്യത്യസ്ത പാത തിരഞ്ഞെടുത്തേക്കാം. ഉത്തരം ഇന്റർഫേസ്, തിരഞ്ഞെടുത്ത ഉറവിട വിലാസം, ഏതെങ്കിലും അടുത്ത ഹോപ്പ് എന്നിവ നാമകരണം ചെയ്യുന്നു, അത് ആ നിമിഷം പാക്കറ്റ് റൂട്ട് ചെയ്യാൻ ഉപയോഗിക്കുന്ന അതേ വിവരമാണ്.
ഉത്തരം നിങ്ങളെ അത്ഭുതപ്പെടുത്തിയാൽ, എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് നിയമങ്ങൾ അച്ചടിക്കുക: ip -4 rule show അവ മുൻഗണനാ ക്രമത്തിൽ പട്ടികപ്പെടുത്തുന്നു, സ്വന്തം പട്ടികയോ അടയാളപ്പെടുത്തിയ പാക്കറ്റുകൾക്കുള്ള നിയമമോ ഇൻസ്റ്റാൾ ചെയ്യുന്ന VPN ക്ലയന്റ് പ്രധാന പട്ടികയിൽ ഒട്ടും പ്രത്യക്ഷപ്പെടുകയില്ല. എല്ലാ പട്ടികകളും പട്ടികപ്പെടുത്തുന്നത് ആ വിടവ് അടയ്ക്കുന്നു.
ip -4 route show table all | grep -E 'tun|default'ഡിഫോൾട്ട് മാറ്റുന്നതിന് മുമ്പ് അണ്ടർലേ പരിശോധിക്കുക
ടണലിന്റെ സ്വന്തം പാക്കറ്റുകൾ വിദൂര എൻഡ്പോയിന്റിൽ എത്തണം, VPN ഉയരുന്നതിന് മുമ്പ് ഉണ്ടായിരുന്ന റൂട്ട് ഉപയോഗിച്ച് ഭൗതിക ഇന്റർഫേസിലൂടെ അവ അത് ചെയ്യുന്നു. ആ എൻഡ്പോയിന്റ് പിൻ ചെയ്യാതെ മുഴുവൻ ഡിഫോൾട്ട് റൂട്ടും മാറ്റുന്നത് എൻക്യാപ്സുലേറ്റ് ചെയ്ത പാക്കറ്റുകളെ അവ നിർമ്മിക്കേണ്ട ടണലിലേക്ക് അയക്കുന്നു, കണക്ഷൻ തകരുന്നു. ആദ്യം എൻഡ്പോയിന്റ് വിലാസത്തിന് മാത്രമായി ഒരു തിരയലിലൂടെ എൻഡ്പോയിന്റ് പാത സ്ഥിരീകരിക്കുക.
മാറ്റം വരുത്തുമ്പോൾ മൂന്ന് കാര്യങ്ങൾ വേർതിരിച്ച് സൂക്ഷിക്കുക: ഭൗതിക ഇന്റർഫേസിൽ തുടരേണ്ട എൻഡ്പോയിന്റ് റൂട്ട്, ടണലിൽ പ്രവേശിക്കേണ്ട സ്വകാര്യ ശ്രേണികൾ, ബാക്കിയെല്ലാം തീരുമാനിക്കുന്ന ഡിഫോൾട്ട്. ആ ക്രമത്തിൽ അവ വേർതിരിക്കുക, ഒരിക്കൽ ഒന്ന് പ്രയോഗിക്കുക, ഓരോ ഘട്ടത്തിനും ശേഷം തിരയൽ വീണ്ടും പ്രവർത്തിപ്പിക്കുക. പിന്നീട് പരാജയപ്പെടുന്ന പിംഗ് അതിൽത്തന്നെ വളരെ കുറച്ച് മാത്രമേ തെളിയിക്കുന്നുള്ളൂ, കാരണം അനുമതികൾ, മറുപടി റൂട്ടിംഗ്, DNS, സേവനം എന്നിവയെല്ലാം ശരിയായ റൂട്ടിന്റെ താഴേക്കിടയിലാണ്.
എഡിറ്റിന് മുമ്പ് വരി നൽകിയ നാല് മൂല്യങ്ങൾ എഴുതിവയ്ക്കുക: ലക്ഷ്യം, അടുത്ത ഹോപ്പ് അല്ലെങ്കിൽ അതിന്റെ അഭാവം, ഉപകരണം, തിരഞ്ഞെടുത്ത ഉറവിടം. പിന്നീടുള്ള മാറ്റം അവയിലൊന്ന് നീക്കിയാൽ, ഏത് തീരുമാനമാണ് യഥാർത്ഥത്തിൽ മാറ്റിയതെന്ന് നിങ്ങൾക്കറിയാം, മുഴുവൻ പട്ടികയും ഊഹിക്കുന്നതിനുപകരം ഒരു എൻട്രി പുനഃസ്ഥാപിക്കാനും കഴിയും.