OpenVPN ക്ലയന്റിന് പിന്നിലെ സബ്നെറ്റ് എത്തിച്ചേരാൻ കഴിയാത്തത് എന്തുകൊണ്ട്?

സെർവറിന്റെ ടണൽ വിലാസത്തിലേക്കുള്ള ping വിജയിക്കുന്നു, ക്ലയന്റിന്റെ സ്വന്തം റൂട്ട് ടേബിൾ ശരിയായി തോന്നുന്നു, എന്നിട്ടും ആ ക്ലയന്റിന് പിന്നിലെ LAN എത്തിച്ചേരാൻ കഴിയാത്തതാണ്. ക്ലയന്റിന്റെ റൂട്ടിംഗ് ടേബിൾ ശരിയായി തോന്നുന്നു, സെർവറിൽ ടണലിലേക്ക് ചൂണ്ടുന്ന ഒരു റൂട്ട് ഉണ്ട്, എന്നിട്ടും പാക്കറ്റുകൾ അപ്രത്യക്ഷമാകുന്നു. ഇത് layer-3 ടണലിന്റെ ക്ലാസിക് ലക്ഷണമാണ്, അതിന്റെ ഒരു ക്ലയന്റും ഒരു ഗേറ്റ്‌വേയാണെന്ന് അതിനറിയില്ല.

tun ഇന്റർഫേസിന് ഓരോ ക്ലയന്റിനും അടുത്ത ഹോപ്പ് ഇല്ല. കർണ്ണലിന് പല പിയറുകളുള്ള ഒരു ഇന്റർഫേസ് മാത്രമാണ് കാണുന്നത്, അതിനാൽ ദൂരെയുള്ള LAN-നുള്ള പാക്കറ്റ് ഏത് ക്ലയന്റ് സ്വീകരിക്കണം എന്ന തീരുമാനം OpenVPN പ്രോസസ്സിനുള്ളിൽ എടുക്കണം. ആ തീരുമാനം iroute ഉപയോഗിച്ച് കോൺഫിഗർ ചെയ്യുന്നു, അതില്ലാതെ പാക്കറ്റിന് പോകാൻ ഇടമില്ല.

സെർവർ ഇന്റർഫേസ് പ്രകാരമല്ല, ക്ലയന്റ് പ്രകാരം റൂട്ട് ചെയ്യുന്നു

ഒരു ക്ലയന്റിന്റെ ടണൽ വിലാസത്തിലേക്ക് പാക്കറ്റ് അയയ്ക്കേണ്ടിവരുമ്പോൾ ഉത്തരം വ്യക്തമാണ്: ആ വിലാസം ആ ക്ലയന്റിന്റെ സെഷന്റേതാണ്. ലക്ഷ്യം ആ ക്ലയന്റിന് പിന്നിലെ മുഴുവൻ സബ്നെറ്റ് ആകുമ്പോൾ, വിലാസം സെർവറിന് അറിയാവുന്ന ആരുടേതുമല്ല, കൂടാതെ ടണലിലേക്കുള്ള കർണ്ണൽ റൂട്ട് "ഈ ഇന്റർഫേസിലൂടെ" എന്ന് മാത്രം പറയുന്നു, ഏത് പിയർ എന്ന് പറയുന്നില്ല.

OpenVPN ഇത് ലക്ഷ്യ പ്രിഫിക്സിനെ ഒരു നിർദ്ദിഷ്ട ക്ലയന്റുമായി ബന്ധിപ്പിക്കുന്ന ആന്തരിക റൂട്ടിംഗ് ടേബിൾ ഉപയോഗിച്ച് പരിഹരിക്കുന്നു. ആ ടേബിൾ iroute എൻട്രികളിൽ നിന്നാണ് നിർമ്മിക്കുന്നത്, അതിനാൽ സെർവർ ഹോസ്റ്റിലെ സാധാരണ റൂട്ട് മതിയാകില്ല. കർണ്ണൽ റൂട്ട് പാക്കറ്റിനെ ടണൽ ഇന്റർഫേസിലേക്ക് എത്തിക്കുന്നു; ഏത് സെഷൻ അത് സ്വീകരിക്കുമെന്ന് ആന്തരിക മാപ്പിംഗ് തീരുമാനിക്കുന്നു. അതുകൊണ്ടാണ് കർണ്ണലിന്റെ റൂട്ട് ഔട്ട്പുട്ടിൽ പരിഹാരം ഒരിക്കലും കാണാത്തത്.

മാപ്പിംഗ് ഇല്ലെങ്കിൽ, പാക്കറ്റ് സെർവറിൽ എത്തി, ടണൽ റൂട്ടുമായി യോജിക്കുന്നു, ഏതെങ്കിലും ക്ലയന്റ് ലക്ഷ്യത്തിന് അവകാശം ഉന്നയിക്കാത്തതിനാൽ ഉപേക്ഷിക്കപ്പെടുന്നു. ഒന്നും വ്യക്തമായ പിശക് രേഖപ്പെടുത്തുന്നില്ല, അതിനാൽ പരാജയം റൂട്ടിംഗ് ലൂപ്പിനെക്കാൾ നിശബ്ദ കറുത്ത ദ്വാരം പോലെ തോന്നുന്നു.

ക്ലയന്റിനെ പേരിടുന്ന iroute എൻട്രി എഴുതുക

iroute സെർവറിന്റെ പ്രധാന കോൺഫിഗറേഷനിലല്ല, ക്ലയന്റ്-നിർദ്ദിഷ്ട കോൺഫിഗറേഷൻ ഫയലിലാണ്. client-config-dir ഓപ്ഷൻ ഉപയോഗിച്ച് സെർവറിനെ ഒരു ഡയറക്ടറിയിലേക്ക് ചൂണ്ടിക്കാണിക്കുക, തുടർന്ന് ക്ലയന്റിന്റെ സർട്ടിഫിക്കറ്റിന്റെ പൊതുനാമം ഉള്ള ഒരു ഫയൽ സൃഷ്ടിച്ച് പ്രിഫിക്സ് അതിൽ ഇടുക.

LAN 10.20.0.0/24 ഉം സർട്ടിഫിക്കറ്റിന്റെ പൊതുനാമം branch-router ഉം ആയ ഒരു ബ്രാഞ്ചിന്, ആ പാതയിലെ ഫയലിൽ iroute 10.20.0.0 255.255.255.0 പോലെയുള്ള ഒരു വരി ഉണ്ടാകും. പ്രധാന കോൺഫിഗറേഷന് ഡയറക്ടറി ഓപ്ഷൻ മാത്രം വേണം; പ്രിഫിക്സ് ക്ലയന്റിന്റെ പക്കലാണ്.

പൊതുനാമമാണ് ദുർബലമായ ഭാഗം. മറ്റൊരു subject-നോടെ പുറപ്പെടുവിച്ച സർട്ടിഫിക്കറ്റ്, അല്ലെങ്കിൽ ഉപയോക്താക്കളെ ഉപയോക്തൃനാമം ഉപയോഗിച്ച് പ്രാമാണീകരിക്കുകയും ഫയൽ സർട്ടിഫിക്കറ്റിന്റെ പേരിലായിരിക്കുകയും ചെയ്യുന്ന ഒരു വിന്യാസം, ഒരിക്കലും വായിക്കപ്പെടാത്ത ഫയൽ ഉണ്ടാക്കുന്നു. സെർവർ സെഷനിൽ യഥാർത്ഥത്തിൽ റിപ്പോർട്ട് ചെയ്യുന്ന പേര് പരിശോധിക്കുക, ഒപ്പം പൊരുത്തപ്പെടാത്ത ക്ലയന്റ് അതിന്റെ റൂട്ടുകളില്ലാതെ നിശബ്ദമായി കണക്ട് ചെയ്യുന്നതിനുപകരം പരാജയപ്പെടാൻ അനുവദിക്കുന്ന ഓപ്ഷനും പരിഗണിക്കുക. സർട്ടിഫിക്കറ്റുമായി പൊരുത്തപ്പെടാൻ ഫയലിന്റെ പേര് മാറ്റുന്നത് വളരെ നീണ്ട ഒരു വൈകുന്നേരം ഒഴിവാക്കുന്ന അഞ്ചു മിനിറ്റ് പരിഹാരമാണ്.

ഒരു ക്ലയന്റിന് പല പ്രിഫിക്സുകൾ ഉണ്ടാകാം. ഓരോ നെറ്റ്വർക്കിനും ഒരു iroute വരി ചേർക്കുക, മാപ്പിംഗ് ഓഡിറ്റ് ചെയ്യാവുന്നതായി തുടരാൻ ആ ക്ലയന്റിന്റെ ബാക്കി ക്രമീകരണങ്ങൾക്കൊപ്പം ലിസ്റ്റ് സൂക്ഷിക്കുക.

ഇരുവശത്തും തിരിച്ചുള്ള പാത നിർമ്മിക്കുക

ദൂരെയുള്ള LAN-ലേക്ക് പാക്കറ്റുകൾ എത്തിക്കുന്നത് പകുതി ജോലിയാണ്. ആ LAN-ന്റെ ട്രാഫിക് ക്ലയന്റ് ടണലിലേക്കും അയയ്ക്കണം, ഇത് സാധാരണയായി ക്ലയന്റിലേക്ക് ഒരു റൂട്ട് പുഷ് ചെയ്താണ് ചെയ്യുന്നത്: push "route 10.8.0.0 255.255.255.0" പോലെയുള്ള ഒരു വരി സെർവർ വശത്തെ നെറ്റ്വർക്കിൽ എങ്ങനെ എത്താമെന്ന് ഓരോ ക്ലയന്റിനോടും പറയുന്നു. ബ്രാഞ്ചിന്, തത്തുല്യമായ റൂട്ട് സെർവർ വശത്ത് എത്തേണ്ട എല്ലാത്തിനെയും ടണലിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്നു.

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

സെർവർ ഹോസ്റ്റിൽ ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമായിരിക്കണം. അതില്ലാതെ കർണ്ണൽ ടണലിൽ നിന്നുള്ള പാക്കറ്റ് സ്വീകരിക്കുകയും അത് LAN ഇന്റർഫേസിലേക്ക് കൈമാറാൻ വിസമ്മതിക്കുകയും ചെയ്യുന്നു, ഇത് ക്ലയന്റിന്റെ കാഴ്ചപ്പാടിൽ നഷ്ടമായ iroute പോലെ തന്നെ തോന്നുന്നു.

ശരിയായ പ്രോബുകൾ ഉപയോഗിച്ച് എത്തിച്ചേരൽ പരിശോധിക്കുക

അകലെയുള്ള അറ്റത്തേക്ക് ping ചെയ്ത് ഊഹിക്കുന്നതിനുപകരം പാളികളായി പരിശോധിക്കുക. സെർവറിൽ നിന്ന് പ്രിഫിക്സിനുള്ള ആന്തരിക മാപ്പിംഗ് ഉണ്ടെന്നും കർണ്ണൽ റൂട്ട് ടണലിലേക്ക് ചൂണ്ടുന്നുവെന്നും പരിശോധിക്കുക. ക്ലയന്റിൽ നിന്ന് പുഷ് ചെയ്ത റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെന്നും LAN വിലാസത്തിനുള്ള അതിന്റെ സ്ഥിരസ്ഥിതി പാത ടണലാണെന്നും സ്ഥിരീകരിക്കുക.

തുടർന്ന് പാക്കറ്റുകൾ നിരീക്ഷിക്കുക. ടണൽ ഇന്റർഫേസിലെ ക്യാപ്ചർ സെർവർ ക്ലയന്റിലേക്ക് അയയ്ക്കുന്നുണ്ടോ എന്ന് കാണിക്കുന്നു, LAN ഇന്റർഫേസിലെ ക്യാപ്ചർ അത് ഫോർവേഡ് ചെയ്യുന്നുണ്ടോ എന്ന് കാണിക്കുന്നു. ആദ്യത്തേത് പാക്കറ്റുകൾ കാണിക്കുകയും രണ്ടാമത്തേത് ഒന്നും കാണിക്കാതിരിക്കുകയും ചെയ്താൽ, പ്രശ്നം ഫോർവേഡിംഗിലോ ഫിൽട്ടറിലോ ആണ്; രണ്ടും ഒന്നും കാണിക്കുന്നില്ലെങ്കിൽ, തിരച്ചിൽ നേരത്തേ പരാജയപ്പെട്ടു.

ടണൽ ഉപയോഗിച്ച് ബന്ധിപ്പിച്ച രണ്ട് സെർവറുകൾ ഇരുവശത്തും ഒരേ നിയമം ആവർത്തിക്കുന്നു: ഓരോന്നിനും മറ്റേതിന്റെ പൂളിന് iroute ആവശ്യമാണ്, ഒപ്പം പാതയെ സമമിതമാക്കുന്ന റൂട്ടും ഫോർവേഡിംഗും ആവശ്യമാണ്. ഇവിടെ റൂട്ടിംഗും നയവും വെവ്വേറെ വിഷയങ്ങളാണ്. പാക്കറ്റ് എവിടേക്ക് പോകാമെന്ന് റൂട്ടിംഗ് തീരുമാനിക്കുന്നു, അനുവദനീയമാണോ എന്ന് FORWARD നിയമം തീരുമാനിക്കുന്നു, അതിനാൽ രണ്ട് iroute വരികളുള്ള ക്ലയന്റ് ഫിൽട്ടർ വേറെ പറയുന്നില്ലെങ്കിൽ രണ്ട് പ്രിഫിക്സുകളിലും എത്തും.