VPN റൂട്ടിലെ അടുത്ത ഹോപ്പ്: ഗേറ്റ്‌വേ ലോക്കലായി എത്തിച്ചേരാവുന്നതായിരിക്കണം എന്തുകൊണ്ട്

VPN നെറ്റ്‌വർക്കിലേക്കുള്ള ഒരു റൂട്ട് ആശയക്കുഴപ്പമുണ്ടാക്കുന്ന രണ്ട് വിലാസങ്ങൾ വഹിക്കുന്നു: പാക്കറ്റ് എത്താൻ ശ്രമിക്കുന്ന ലക്ഷ്യ പ്രിഫിക്സും അതിനെ ഒരു ചുവട് അടുപ്പിക്കുന്ന അടുത്ത ഹോപ്പും. ഒരു LAN ഹോസ്റ്റിൽ, ആ അടുത്ത ഹോപ്പ് അതേ ലിങ്കിൽ നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ എത്താവുന്ന ഒരു റൂട്ടർ ആയിരിക്കണം. വിദൂര VPN വിലാസം അടുത്ത ഹോപ്പ് അല്ല, നിങ്ങളുടെ മനസ്സിലുള്ള ലക്ഷ്യവുമായി അത് എത്ര ഭംഗിയായി യോജിച്ചാലും.

ഈ റൺബുക്ക് സാധാരണ കേസ് ഉൾക്കൊള്ളുന്നു: 192.168.20.0/24 ലെ ഒരു ലാപ്‌ടോപ്പ്, LAN വിലാസം 192.168.20.5 ഉള്ള ഒരു VPN ഗേറ്റ്‌വേ, അതിന് പിന്നിലുള്ള വിദൂര നെറ്റ്‌വർക്ക് 10.70.0.0/24. താഴെയുള്ള എല്ലാ കമാൻഡുകളും നിങ്ങൾ ലാപ്‌ടോപ്പിലാണെന്ന് അനുമാനിക്കുന്നു, വേറെ രീതിയിൽ പറഞ്ഞിട്ടില്ലെങ്കിൽ.

രണ്ട് വിലാസങ്ങൾ, ഒരു റൂട്ട്

ഉദ്ദേശിക്കുന്ന എൻട്രി 10.70.0.0/24 via 192.168.20.5 ആണ്. പ്രിഫിക്സ് പാക്കറ്റ് എവിടെ പോകുന്നു എന്ന് പറയുന്നു; via വിലാസം അത് അവിടേക്ക് ആര് കൊണ്ടുപോകുന്നു എന്ന് പറയുന്നു. നിങ്ങൾ നൽകുന്ന ഇന്റർഫേസിലൂടെ ഗേറ്റ്‌വേയിൽ എത്താൻ കഴിയാത്ത ഒരു റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യാൻ കേർണൽ വിസമ്മതിക്കുന്നു, ആ വിസമ്മതമാണ് മുഴുവൻ കാര്യം: എത്തിച്ചേരാനാകാൻ ടണൽ ആവശ്യമുള്ള അടുത്ത ഹോപ്പ്, ടണൽ നിർമ്മിക്കുന്ന അടുത്ത ഹോപ്പ് ആകാൻ കഴിയില്ല.

അതിനാൽ ആദ്യ പരിശോധന «ഗേറ്റ്‌വേ പ്രവർത്തിക്കുന്നുണ്ടോ» എന്നല്ല, «ഗേറ്റ്‌വേ ഈ ലിങ്കിലുണ്ടോ» എന്നാണ്. ലാപ്‌ടോപ്പിന്റെ സ്വന്തം സബ്‌നെറ്റ്, അതിന്റെ ARP അല്ലെങ്കിൽ അയൽ എൻട്രി, റൂട്ടിലെ ഇന്റർഫേസ് — എല്ലാം യോജിക്കണം. 10.70.0.0/24 നുള്ളിൽ മാത്രം നിലനിൽക്കുന്ന ഒരു വിലാസം രണ്ടാം റൂട്ടിന്റെ ലക്ഷ്യമാകാം, എന്നാൽ ഒന്നാമത്തേതിന്റെ via ഒരിക്കലും ആകാൻ കഴിയില്ല.

അടുത്ത ഹോപ്പ് ഗേറ്റ്‌വേയിൽ നിർബന്ധിക്കുന്നത്

ലാപ്‌ടോപ്പിൽ റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുന്നത് ആദ്യ കൈമാറ്റം മാത്രം തീരുമാനിക്കുന്നു. പിന്നീട് ഗേറ്റ്‌വേയ്ക്ക് സ്വന്തം വഴി വേണം: പ്രവർത്തനക്ഷമമാക്കിയ ഫോർവേഡിംഗ്, 10.70.0.0/24 ലേക്കുള്ള ടണൽ റൂട്ട്, ആര് ഇത് ഉപയോഗിക്കാം എന്ന് നിർണ്ണയിക്കുന്ന ഏതെങ്കിലും ആക്സസ് പോളിസി. Linux ൽ അത് net.ipv4.ip_forward=1 ഉം ഒരു ടണൽ റൂട്ടും ആണ്; അതിന് മുന്നിലുള്ള ഫയർവാളിന് ഫോർവേഡ് ചെയ്യുന്ന പ്രവാഹം അനുവദിക്കുന്ന ഒരു നിയമം വേണം.

തിരികെയുള്ള ദിശയാണ് ആളുകൾ മറക്കുന്ന ഭാഗം. വിദൂര വശത്ത് 192.168.20.0/24 ലേക്ക് തിരികെയുള്ള ഒരു റൂട്ട് ഉണ്ടായിരിക്കണം, അല്ലെങ്കിൽ ഡിസൈൻ ലാപ്‌ടോപ്പിന്റെ ഉറവിടത്തെ വിദൂര വശം അറിയുന്ന എന്തോ ആക്കി മാറ്റണം. ഗേറ്റ്‌വേയിൽ നിന്ന് പ്രവർത്തിക്കുന്ന ഒരു ping, ഗേറ്റ്‌വേയ്ക്ക് വിദൂര നെറ്റ്‌വർക്കിൽ എത്താമെന്ന് തെളിയിക്കുന്നു; ലാപ്‌ടോപ്പിന്റെ പാക്കറ്റുകൾ തിരികെയുള്ള യാത്രയിൽ അതിജീവിക്കുമോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.

അയയ്ക്കുന്ന ഹോസ്റ്റിൽ നിന്ന് ലുക്കപ്പ് പരിശോധിക്കുക

ഏത് അടുത്ത ഹോപ്പ് തിരഞ്ഞെടുക്കുമെന്ന് കേർണലിനോട് ചോദിക്കുക, ഉത്തരത്തിലെ ഇന്റർഫേസ് വായിക്കുക:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

ലുക്കപ്പ് ഗേറ്റ്‌വേയും LAN ഇന്റർഫേസും റിപ്പോർട്ട് ചെയ്താൽ, ആദ്യ ഘട്ടം ഉദ്ദേശിച്ചതുപോലെ കോൺഫിഗർ ചെയ്തിരിക്കുന്നു. അത് ടണൽ ഉപകരണം റിപ്പോർട്ട് ചെയ്താൽ, പട്ടികയിൽ മുൻപുള്ള എന്തോ കൂടുതൽ നിർദ്ദിഷ്ടമാണ്, അത് വിജയിക്കുന്നു. റൂട്ട് ഒട്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ലെങ്കിൽ, ഗേറ്റ്‌വേ എത്തിച്ചേരാനാകില്ലെന്ന് കേർണൽ നിങ്ങളോട് പറയുന്നു, ആ സന്ദേശം ഏതൊരു പാക്കറ്റ് ക്യാപ്ചറിനേക്കാളും ഉപയോഗപ്രദമാണ്.

തുടർന്ന് ശരിയായ സ്ഥലത്തുനിന്ന് പരിശോധന ആവർത്തിക്കുക. ഗേറ്റ്‌വേയിൽ സൃഷ്ടിക്കുന്ന ഒരു അഭ്യർത്ഥനം ഗേറ്റ്‌വേയുടെ സ്വന്തം ഉറവിട വിലാസം ഉപയോഗിക്കുന്നു, ഇത് കാണാതായ ഒരു തിരിച്ചുവരവ് റൂട്ട് അല്ലെങ്കിൽ ചില ഉറവിടങ്ങൾ മാത്രം അനുവദിക്കുന്ന ഒരു പോളിസി മറയ്ക്കാം. ip-route കൈപ്പുസ്തകം ലക്ഷ്യവും ഗേറ്റ്‌വേയും onlink ഓവർറൈഡും വേർതിരിക്കുന്നു, ഓവർറൈഡ് ഉപയോഗിക്കുന്നതിന് മുൻപ് അത് മനസ്സിലാക്കുന്നത് മൂല്യവത്താണ്.

എത്തിച്ചേരാനുള്ള കഴിവ് വ്യാജമാക്കാൻ onlink ഉപയോഗിക്കരുത്

onlink കേർണലിനോട് ഗേറ്റ്‌വേയുടെ എത്തിച്ചേരൽ പരിശോധന ഒഴിവാക്കി എന്നിട്ടും അവിടേക്ക് അയയ്ക്കാൻ പറയുന്നു. അത് ഒരു വഴി സൃഷ്ടിക്കുന്നില്ല, അവിടെയില്ലാത്ത ഒരു വിലാസത്തിന് ARP പരിഹരിക്കുന്നില്ല, നിങ്ങളുടെ Ethernet സെഗ്‌മെന്റിൽ ഒരു വിദൂര റൂട്ടറിനെ ഉത്തരം നൽകാൻ നിർബന്ധിക്കുന്നുമില്ല. ഉത്തരം നൽകുന്നുവെങ്കിലും ബന്ധിപ്പിച്ച സബ്‌നെറ്റിൽ ഇല്ലാത്ത ഗേറ്റ്‌വേകൾക്ക് അത് ന്യായമാണ്, നിങ്ങൾ വിശദീകരിക്കാത്ത ഒരു പിശക് നിശ്ശബ്ദമാക്കാൻ ഉപയോഗിക്കുമ്പോൾ അത് ഒരു കെണിയാണ്.

റൂട്ട് onlink കൊണ്ട് മാത്രം ഇൻസ്റ്റാൾ ചെയ്യുന്നുവെങ്കിൽ, അടുത്ത ചോദ്യം ഗേറ്റ്‌വേ നിങ്ങൾ കരുതുന്നിടത്ത് എന്തുകൊണ്ട് ഇല്ല എന്നതാണ്. തെറ്റായ VLAN, തെറ്റായ ഇന്റർഫേസിലെ രണ്ടാം വിലാസം, അല്ലെങ്കിൽ അവസാന ഓക്ടെറ്റിലെ ടൈപ്പോ — ഇവയെല്ലാം ഇത് ഉണ്ടാക്കുന്നു, അവയിൽ ഓരോന്നും ട്രാഫിക് ഒഴുകാൻ തുടങ്ങുമ്പോൾ തിരിച്ചുവരവ് വഴിയും തകർക്കുന്നു.

പോയിന്റ്-ടു-പോയിന്റ് ടണലുകൾ Ethernet അല്ല

ഒരു ടണൽ ഉപകരണം ARP ചെയ്യുന്നില്ല, പലപ്പോഴും അയൽക്കാരുടെ അർത്ഥവത്തായ ഒരു സബ്‌നെറ്റ് അതിനില്ല. അതിന്റെ റൂട്ടുകൾ പലപ്പോഴും 10.70.0.0/24 dev tun0 പോലെ കാണപ്പെടുന്നു, via ഒട്ടുമില്ലാതെ, കാരണം പിയർ മാത്രമാണ് മറ്റേ അറ്റം. ആ പട്ടികയിലേക്ക് LAN ശൈലിയിലുള്ള via പകർത്തുന്നത് കേർണൽ നിരസിച്ചേക്കാവുന്ന ഒരു റൂട്ടോ, അതിലും മോശമായി, പിയർ ഒരിക്കലും ഉത്തരം നൽകാത്ത ഒരു വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന ഒരു റൂട്ടോ ഉണ്ടാക്കുന്നു.

റൺബുക്കിൽ രണ്ട് മാതൃകകളും വേർതിരിച്ച് വയ്ക്കുക: LAN റൂട്ടിന് എത്തിച്ചേരാവുന്ന ഒരു ഗേറ്റ്‌വേ ഉണ്ട്, ടണൽ റൂട്ടിന് ഒരു ഇന്റർഫേസും ഒരു പിയറും ഉണ്ട്. WireGuard, OpenVPN, IPsec എന്നിവയെല്ലാം അൽപ്പം വ്യത്യസ്ത രൂപങ്ങൾ കാണിക്കുന്നു, അതിനാൽ ഒരു ഹോസ്റ്റിൽ നിന്ന് പൊതുവൽക്കരിക്കുന്നതിന് പകരം നിങ്ങൾ യഥാർത്ഥത്തിൽ ഉപയോഗിച്ച രൂപം രേഖപ്പെടുത്തുക.

ചേർക്കുക, സ്ഥിരീകരിക്കുക, പിന്നോട്ട് തിരിക്കുക

മുഴുവൻ മാറ്റവും മൂന്ന് കമാൻഡുകളും ഒരു പരിശോധനയുമാണ്, അത് അതേ ക്രമത്തിൽ എഴുതിവയ്ക്കണം:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

പാത സ്ഥിരീകരിക്കുക, ഒരു ലക്ഷ്യം സ്ഥിരീകരിക്കുക, എന്നിട്ട് മാറ്റം ഹോസ്റ്റിനെ നിങ്ങൾ പ്രതീക്ഷിക്കാത്ത രീതിയിൽ എത്താനാകാത്തതാക്കിയാൽ ഡിലീറ്റ് വരി തയ്യാറായി സൂക്ഷിക്കുക. റൂട്ട് റീബൂട്ടിനെ അതിജീവിക്കേണ്ടതുണ്ടെങ്കിൽ, അത് shell പ്രൊഫൈലിൽ അല്ല, ഹോസ്റ്റിന്റെ നെറ്റ്‌വർക്ക് കോൺഫിഗറേഷനിൽ ഇടുക, അതിനെ ആശ്രയിക്കുന്നതിന് മുൻപ് റീബൂട്ട് പരിശോധിക്കുക. അത് ചേർത്ത shell ൽ മാത്രം നിലനിൽക്കുന്ന റൂട്ട് നിങ്ങൾ രണ്ടുതവണ ഡീബഗ് ചെയ്യുന്ന റൂട്ടാണ്.