LAN റൗട്ടറും VPN ക്ലയന്റും: രണ്ട് ഉപകരണങ്ങൾ, രണ്ട് റൂട്ട് പട്ടികകൾ

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

ഒരു റൂട്ടിൽ തൊടുന്നതിന് മുൻപ് രണ്ട് ഹോപ്പുകൾ വരയ്ക്കുക

ഒരു ഉദാഹരണ ക്രമീകരണം എടുക്കുക: LAN ഹോസ്റ്റുകൾ 192.168.50.0/24, സാധാരണ റൗട്ടർ 192.168.50.1, സമർപ്പിത ക്ലയന്റ് 192.168.50.15, കൂടാതെ ദൂരെയുള്ള LAN 10.60.0.0/24, അത് ആ ക്ലയന്റ് സൂക്ഷിക്കുന്ന ടണൽ വഴി മാത്രം ലഭ്യമാണ്. രണ്ട് സ്വകാര്യ ശ്രേണികളിൽ ഒന്നും മറ്റൊന്നിനെ ആവരണം ചെയ്യുന്നില്ല, കൂടാതെ ടണലിന് സ്വന്തം വിലാസ പദ്ധതിയുണ്ട്.

രണ്ട് സ്വകാര്യ ശ്രേണികളും പ്രധാനമാണ്, ഏത് ഉപകരണത്തിന് മറുപടി നൽകാം എന്ന് അവയാണ് തീരുമാനിക്കുന്നത്. ദൂരെയുള്ള വശം പാക്കറ്റ് ക്ലയന്റിന്റെ ടണൽ വിലാസത്തിൽ നിന്ന് വരുന്നതായി കാണും, അതിന്റെ മറുപടി 192.168.50.0/24 ലേക്ക് തിരികെയുള്ള വഴി കണ്ടെത്തണം. പുറത്തേക്കുള്ള ദിശ മാത്രം കോൺഫിഗർ ചെയ്താൽ, അഭ്യർത്ഥന പ്രവർത്തിച്ചേക്കാം, മറുപടി അപ്രത്യക്ഷമാകുമ്പോൾ.

ഘട്ടം 1: റൗട്ടറിനെ ടണലിലേക്കല്ല, ക്ലയന്റിലേക്ക് തിരിച്ചുവിടുക

LAN റൗട്ടറിൽ, അടുത്ത ഹോപ്പ് ക്ലയന്റിന്റെ LAN വിലാസമായ ഒരു ലക്ഷ്യ റൂട്ട് ചേർക്കുക:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

ആ റെക്കോർഡ് “ടണൽ നിർമ്മിക്കാൻ കഴിയുന്ന യന്ത്രത്തിലേക്ക് അത് എത്തിക്കുക” എന്ന് പറയുന്നു. ടണൽ എങ്ങനെ നിർമ്മിക്കുന്നു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ക്ലയന്റിന്റെ സ്വന്തം റൂട്ടിന് പകരമാകുന്നുമില്ല. മാനേജുചെയ്ത റൗട്ടറിൽ തുല്യമായത് ഉപകരണത്തിന്റെ സ്റ്റാറ്റിക് റൂട്ട് പേജിലാണ്; Linux റൗട്ടറിൽ അത് LAN കൈവശമുള്ള ഇന്റർഫേസ് കോൺഫിഗറേഷനിൽ പെടുന്നു, നിങ്ങൾ അടയ്ക്കുന്ന ഷെല്ലിലല്ല.

രണ്ടാമത്തെ കമാൻഡിന്റെ ഉത്തരം പരിശോധിക്കുക. ക്ലയന്റിനെ gateway ആയും LAN ഇന്റർഫേസിനെ device ആയും റിപ്പോർട്ട് ചെയ്താൽ, ആദ്യ ഹോപ്പ് ശരിയാണ്, ബാക്കി ജോലി മറ്റേ യന്ത്രത്തിലാണ്.

ഘട്ടം 2: ടണൽ വശത്ത് ക്ലയന്റിന് സ്വന്തം റൂട്ട് നൽകുക

ഇപ്പോൾ ക്ലയന്റ് 10.60.0.0/24 നുള്ള പാക്കറ്റ് സ്വീകരിച്ച് സ്വന്തം പട്ടിക നോക്കുന്നു. അതിന്റെ ടണൽ കോൺഫിഗറേഷൻ ആ പ്രിഫിക്സിന് റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെങ്കിൽ, പാക്കറ്റ് എൻക്രിപ്റ്റ് ചെയ്ത് തുടരുന്നു. ഇല്ലെങ്കിൽ, പാക്കറ്റ് സാധാരണ ഡിഫോൾട്ടുമായി പൊരുത്തപ്പെട്ട് 192.168.50.1 ലേക്ക് തിരികെ പോകുന്നു, അത് അതിനെ വീണ്ടും ക്ലയന്റിലേക്ക് അയയ്ക്കുന്നു.

എന്തെങ്കിലും ചേർക്കുന്നതിന് മുൻപ് നോക്കുക:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

എല്ലാ പട്ടികകളിലും പ്രിഫിക്സ് റൂട്ട് ഇല്ലാതിരിക്കുന്നതാണ് നിങ്ങൾ തിരയുന്ന കണ്ടെത്തൽ. ടണലിന്റെ സ്വന്തം കോൺഫിഗറേഷൻ വഴി അത് ചേർക്കുക, അടുത്ത പുനർബന്ധനം അത് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യും; കൈകൊണ്ടുള്ള ip route add സെഷനൊപ്പം അപ്രത്യക്ഷമാകുകയും ഏറ്റവും അസൗകര്യകരമായ സമയത്ത് തകരാർ തിരികെ കൊണ്ടുവരികയും ചെയ്യുന്നു. അടുത്ത ഹോപ്പ് ടണൽ ഇന്റർഫേസോ VPN അതിന്റെ പിയർ ആയി നൽകുന്ന വിലാസമോ ആണ്, ക്ലയന്റിനെ ആശ്രയിച്ച്, പിയർ വിലാസം പഴയ കുറിപ്പിൽ നിന്നല്ല, നിലവിലെ പ്രൊഫൈലിൽ നിന്ന് വരണം.

ലൂപ്പ് സംഭവിക്കുമ്പോൾ പ്രായോഗികമായി അനന്തമല്ല: ഓരോ കടന്നുപോക്കിലും TTL കുറയുന്നു, സമയം കവിഞ്ഞു എന്ന സന്ദേശത്തോടെ പാക്കറ്റ് മരിക്കുന്നു. അതുകൊണ്ട് ആവർത്തിച്ചുള്ള traceroute ഒരു ചക്രം സൂചിപ്പിച്ചേക്കാം, എന്നാൽ ഫോർവേഡ് ചെയ്യാത്ത ക്ലയന്റ് അതേ പാക്കറ്റ് നിശബ്ദമായി വീഴ്ത്തുന്നു.

ഘട്ടം 3: ഫോർവേഡിംഗ് അനുവദിക്കുകയും മടക്കവഴി തിരഞ്ഞെടുക്കുകയും ചെയ്യുക

സ്വീകരിക്കുന്നതും ഫോർവേഡ് ചെയ്യുന്നതും വ്യത്യസ്ത അനുമതികളാണ്. ക്ലയന്റിലെ net.ipv4.ip_forward=1 കേർണൽ തലത്തിൽ ട്രാൻസിറ്റ് അനുവദിക്കുന്നു, ഫയർവാൾ നിയമം ഇപ്പോഴും അത് LAN ഇന്റർഫേസിനും ടണലിനും ഇടയിൽ അനുവദിക്കണം. ക്ലയന്റിന്റെ സ്വന്തം മാനേജ്മെന്റ് പേജിലേക്കുള്ള പ്രവേശനം അനുവദിക്കുന്ന നിയമം ദൂരെയുള്ള LAN ലേക്കുള്ള ട്രാൻസിറ്റ് അനുവദിക്കില്ല, അതേ ഹോസ്റ്റ് പ്രാദേശികമായി ping ന് ഉത്തരം നൽകുമ്പോൾ ഈ വ്യത്യാസം വഴിമാറിപ്പോകാൻ സാധ്യതയുണ്ട്.

ദൂരെയുള്ള വശത്തിന് കണ്ണാടി പ്രശ്നമുണ്ട്. ഈ പ്രാമാണീകരിച്ച ക്ലയന്റിലൂടെ 192.168.50.0/24 ലഭ്യമാണെന്ന് അത് അറിയണം. OpenVPN ഉപയോഗിക്കുമ്പോൾ സാധാരണയായി സർവർ കോൺഫിഗറേഷൻ തള്ളുന്ന ഓരോ ക്ലയന്റിനുമുള്ള റൂട്ട്, അല്ലെങ്കിൽ സർവറിൽ ക്ലയന്റിന് പിന്നിലെ LAN പ്രഖ്യാപിക്കുന്ന ക്ലയന്റ്-നിർദ്ദിഷ്ട ഫയൽ എന്നാണ് അർത്ഥം. അതില്ലാതെ, ദൂരെയുള്ള LAN മറുപടി വീഴ്ത്തുന്നു അല്ലെങ്കിൽ അതിനെ സ്വന്തം ഡിഫോൾട്ട് ഗേറ്റ്വേയിലേക്ക്, അതായത് ഇന്റർനെറ്റിലേക്ക് അയയ്ക്കുന്നു.

LAN പ്രിഫിക്സ് പ്രഖ്യാപിക്കാൻ കഴിയാത്തപ്പോൾ സ്രോതസ്സ് വിവർത്തനമാണ് പകരം. ക്ലയന്റിലെ പരിമിത masquerade നിയമം സ്രോതസ്സ് ടണൽ വിലാസത്തിലേക്ക് പുനരെഴുതുന്നു, മറുപടികൾ പിന്നീട് സ്വാഭാവികമായി തിരികെ വരുന്നു. ഏത് LAN ഹോസ്റ്റ് അഭ്യർത്ഥിച്ചു എന്നതും അത് മറയ്ക്കുന്നു, സ്വയം ദൂരെയുള്ള വശത്തിന് അകത്തേക്ക് കണക്ഷനുകൾ തുടങ്ങാൻ അനുവദിക്കുന്നുമില്ല. എല്ലായിടത്തും ബാധകമായ masquerade ചേർത്ത് പിന്നീട് പാർശ്വഫലം കണ്ടെത്തുന്നതിന് പകരം ഈ വിട്ടുവീഴ്ച ബോധപൂർവം തിരഞ്ഞെടുക്കുക.

ഘട്ടം 4: രണ്ട് തീരുമാനങ്ങളും സ്ഥിരമാക്കുക, പിന്നീട് യഥാർത്ഥ വഴി പരിശോധിക്കുക

ഓരോ റൂട്ടിനും ഒരു ഉടമയുണ്ട്, ബൂട്ടിലോ പുനർബന്ധനത്തിലോ വീണ്ടും സൃഷ്ടിക്കപ്പെടുന്ന കോൺഫിഗറേഷനാണ് ഉടമ. റൗട്ടറിൽ അത് ഒരു സ്റ്റാറ്റിക് റൂട്ട് എൻട്രി ആകാം; ക്ലയന്റിൽ അത് VPN പ്രൊഫൈൽ, NetworkManager അല്ലെങ്കിൽ systemd-networkd ആകാം. ടണൽ വീണ്ടും ബന്ധിപ്പിച്ച് ക്ലയന്റ് റീബൂട്ട് ചെയ്ത് പരിശോധിക്കുക, പിന്നീട് മാറ്റത്തെ വിശ്വസിക്കുന്നതിന് പകരം പട്ടിക വീണ്ടും വായിക്കുക.

ടണലിന്റെ പുറം ബന്ധം വഹിക്കുന്ന ഡിഫോൾട്ട് റൂട്ട് അസ്പൃശ്യമായി സൂക്ഷിക്കുക. സെറ്റപ്പ് “ലളിതമാക്കാൻ” അത് മാറ്റുന്നത് ഏതെങ്കിലും ആന്തരിക ട്രാഫിക് അത് ഉപയോഗിക്കുന്നതിന് മുൻപ് എൻക്രിപ്റ്റ് ചെയ്ത വഴി തകർക്കുന്നു, മാറ്റത്തിന് ശേഷം ഒരിക്കലും വീണ്ടും സ്ഥാപിക്കപ്പെടാത്ത ടണലാണ് ലക്ഷണം.

സാധാരണ LAN ഹോസ്റ്റിൽ നിന്ന് പരിശോധിക്കുക, ക്ലയന്റിൽ നിന്നല്ല, കാരണം ക്ലയന്റിൽ ഉത്ഭവിക്കുന്ന അഭ്യർത്ഥന ഒരിക്കലും റൗട്ടറിന്റെ ആദ്യ ഹോപ്പ് ഉപയോഗിക്കുന്നില്ല. ദൂരെയുള്ള LAN ൽ മാത്രം നിലനിൽക്കുന്ന ഒരു സേവനം കൊണ്ടുവന്ന് മറുപടിയുടെ ഉള്ളടക്കം സ്ഥിരീകരിക്കുക, പിന്നീട് ട്രാൻസിറ്റ് നടക്കുന്നത് കാണാൻ ക്ലയന്റിന്റെ കൗണ്ടറുകളോ ലോഗുകളോ നോക്കുക. സ്വകാര്യ ഹോപ്പുകൾ കാണിക്കുന്ന ആന്തരിക traceroute ഫോർവേഡിംഗ് തെളിയിക്കുന്നു, എൻക്രിപ്ഷനല്ല: പുറം വഴി വേറിട്ട നിരീക്ഷണമാണ്, ടണലിന്റെ സ്വന്തം ഇന്റർഫേസ് കൗണ്ടറുകൾ മാത്രമാണ് അതിലൂടെ എന്ത് പുറത്തുപോയി എന്ന് കാണിക്കുന്നത്.