OpenVPN iroute vs കേർണൽ റൂട്ട്: ഏതാണ് കാണാത്തത്?

10.77.20.0/24-നുള്ള ഒരു പാക്കറ്റ് OpenVPN സെർവറിൽ രണ്ട് വ്യത്യസ്ത തീരുമാനങ്ങൾ എടുക്കുന്നു: ഓപ്പറേറ്റിംഗ് സിസ്റ്റം അത് VPN ഇന്റർഫേസിന് കൈമാറണം, OpenVPN ആ പ്രിഫിക്സ് ഏത് ബന്ധിപ്പിച്ച ക്ലൈന്റിനാണ് എന്ന് അറിയണം. കേർണൽ റൂട്ട് ഇല്ലെങ്കിൽ പാക്കറ്റ് ടണലിന് മുമ്പ് വീഴുന്നു, പീയർ റൂട്ട് ഇല്ലെങ്കിൽ അതിന് ശേഷം വീഴുന്നു. രണ്ട് പരാജയങ്ങളും വിദൂര LAN-ൽ നിന്ന് ഒരേപോലെ കാണപ്പെടുന്നു, നിങ്ങൾക്ക് ഏതാണ് ഉള്ളതെന്ന് കണ്ടെത്താൻ ഓരോ വശത്തും ഒരു കമാൻഡ് വേണം.

പരമ്പരാഗത ഉപയോക്തൃ സ്ഥല ഡാറ്റാ പാതയിൽ കേർണൽ റൂട്ട് പാക്കറ്റിനെ ടണൽ പ്രോസസ്സിലേക്ക് എത്തിക്കുന്നു, iroute ആ പ്രോസസ്സിനോട് ഏത് പീയർ അത് സ്വീകരിക്കണം എന്ന് പറയുന്നു. ഒന്നും മറ്റൊന്നിന് പകരമാകുന്നില്ല, ഒരെണ്ണം മാത്രം അടങ്ങിയ കോൺഫിഗറേഷൻ ആദ്യ ping വരെ ന്യായമായി തോന്നും.

രണ്ട് തീരുമാനങ്ങൾ, ഒരു റൂട്ട് അല്ല

10.77.20.0/24 ഒരു ക്ലൈന്റിന് പിന്നിലുള്ള സൈറ്റ്-ടു-സൈറ്റ് ലിങ്ക് സങ്കൽപ്പിക്കുക. സെർവറിന്റെ കേർണൽ റൂട്ട്, ഉദാഹരണത്തിന് ip route add 10.77.20.0/24 dev tun0, പൊരുത്തപ്പെടുന്ന പാക്കറ്റുകൾ ടണൽ ഉപകരണത്തിലേക്ക് അയക്കുന്നു. തുടർന്ന് OpenVPN ക്ലൈന്റ് കോൺഫിഗറേഷൻ ഡയറക്ടറിയിലെ iroute എൻട്രികളിൽ നിന്ന് നിർമ്മിച്ച അതിന്റെ ആന്തരിക പട്ടിക പരിശോധിച്ച് ഏത് പീയർ കണക്ഷൻ അവ സ്വീകരിക്കും എന്ന് തീരുമാനിക്കുന്നു. കേർണൽ റൂട്ട് ഇല്ലെങ്കിൽ പാക്കറ്റ് ഒരിക്കലും പ്രോസസ്സിലെത്തുന്നില്ല, പീയർ റൂട്ട് ഇല്ലെങ്കിൽ അത് പ്രോസസ്സിലെത്തി എങ്ങോട്ടും പോകുന്നില്ല.

ആ വിഭജനം മറക്കാൻ എളുപ്പമാണ്, കാരണം ക്ലൈന്റ് പ്രൊഫൈലിലെ ഒരു റൂട്ട് വരി രണ്ട് ജോലികളും ചെയ്യുന്നതായി തോന്നാം. അത് ചെയ്യുന്നില്ല: റൂട്ട് തള്ളുന്നത് ടണലിലൂടെ എന്ത് അയക്കണം എന്ന് ക്ലൈന്റുകളോട് പറയുന്നു, iroute ക്ലൈന്റിന് പിന്നിലെ വിലാസ ശ്രേണി ആരുടേതാണ് എന്ന് സെർവറിനോട് പറയുന്നു. അവ വ്യത്യസ്ത ഫയലുകളിൽ ജീവിക്കുന്നു, വ്യത്യസ്ത വശങ്ങൾ വായിക്കുന്നു, വിപരീത ദിശകളിൽ പരാജയപ്പെടുന്നു.

iroute എവിടെയാണ്, എന്താണ് പറയുന്നത്

എൻട്രി ക്ലൈന്റിന്റെ common_name അനുസരിച്ച് പേരിട്ട ഓരോ ക്ലൈന്റ് ഫയലിലേക്ക്, client-config-dir കീഴിൽ, iroute 10.77.20.0/24 എന്ന രൂപത്തിൽ പോകുന്നു. ഫയൽനാമ പൊരുത്തം അലങ്കാരമല്ല: OpenVPN പ്രാമാണീകരിച്ച ഐഡന്റിറ്റി തിരഞ്ഞ് കൃത്യമായ ആ പേരിലുള്ള ഫയൽ വായിക്കുന്നു, അതിനാൽ site-a എന്ന ഫയൽ പൊതുനാമം site-a ആയ ക്ലൈന്റിന് മാത്രം പ്രാബല്യത്തിൽ വരും. അത്തരം ഫയൽ ഇല്ലാത്ത ക്ലൈന്റുകളെ പൂർണ്ണമായി നിരസിക്കേണ്ടതുണ്ടെങ്കിൽ ccd-exclusive ചേർക്കുക, ഓരോ ക്ലൈന്റും ഒരു സൈറ്റ് ഗേറ്റ്വേ ആകുമ്പോൾ അതാണ് ശരിയായ ക്രമീകരണം. ഓരോ ഗേറ്റ്വേയ്ക്കും ഒരു ഫയൽ സൂക്ഷിച്ച് നിങ്ങൾ യഥാർത്ഥത്തിൽ നൽകുന്ന സർട്ടിഫിക്കറ്റ് വിഷയത്തിന്റെ പേര് നൽകുക.

വിദൂര LAN-നെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് സെർവറിൽ നിന്ന് എൻട്രി പരിശോധിക്കുക. സ്റ്റാറ്റസ് ഫയൽ ബന്ധിപ്പിച്ച ക്ലൈന്റുകളെ അവരുടെ പൊതുനാമങ്ങളോടെ പട്ടികപ്പെടുത്തുന്നു, --verb 4-ൽ പ്രവർത്തിക്കുന്ന സെർവർ പീയർ ബന്ധിപ്പിക്കുമ്പോൾ iroute ഇൻസ്റ്റാൾ ചെയ്യുന്നത് ലോഗ് ചെയ്യുന്നു. ബന്ധിപ്പിക്കുമ്പോൾ ഒന്നും പ്രത്യക്ഷപ്പെടുന്നില്ലെങ്കിൽ ഫയൽ തെറ്റായ ഡയറക്ടറിയിലാണ് അല്ലെങ്കിൽ തെറ്റായ ഐഡന്റിറ്റി പറയുന്നു.

കെണി: ഫയൽ ഉണ്ട്, ഐഡന്റിറ്റി തെറ്റ്

ശരിയായി തോന്നുന്ന iroute തെറ്റായ പീയറിൽ ഘടിപ്പിച്ചാൽ ഡിസ്കിൽ എല്ലാം ശരിയായി തോന്നുന്നതിനാൽ കാണാത്ത ഫയലിനേക്കാൾ കൂടുതൽ സമയം നഷ്ടപ്പെടുന്നു. സർട്ടിഫിക്കറ്റ് പുനർനാമകരണം, തനിപ്പകർപ്പ് പൊതുനാമങ്ങൾ, ഫലപ്രദമായ ഐഡന്റിറ്റി മാറ്റുന്ന username-as-common-name എന്നിവയെല്ലാം ഇത് സൃഷ്ടിക്കുന്നു. സെർവർ ഏത് ഐഡന്റിറ്റി പ്രാമാണീകരിച്ചു എന്ന് പരിശോധിക്കുക, നിങ്ങൾ പ്രതീക്ഷിച്ചത് അല്ല: സ്റ്റാറ്റസ് ഔട്ട്പുട്ടാണ് അധികാരികം, ഫയൽനാമം ഒരു തിരയൽ കീ മാത്രമാണ്.

ഒരു റൂട്ട് അതിന്റെ ഉടമയെ അതിജീവിക്കാം. സ്റ്റാറ്റിക് റൂട്ടുകളും iroute എൻട്രികളും ലഭ്യതാ ഉറപ്പല്ല, ഒരു പ്രിഫിക്സ് വിവരിക്കുന്നു, അതിനാൽ നിലവിൽ വിച്ഛേദിക്കപ്പെട്ട ഒരു പീയറിലേക്ക് ട്രാഫിക് തുടർന്നും റൂട്ട് ചെയ്യപ്പെടാം.

പീയറിനപ്പുറമുള്ള പാത പൂർത്തിയാക്കുക

പീയർ ഉടമസ്ഥത പാതയുടെ മധ്യത്തിലാണ്, അവസാനത്തിലല്ല. ക്ലൈന്റ് ടണലിൽ നിന്ന് തന്റെ LAN-ലേക്ക് പാക്കറ്റുകൾ കൈമാറണം, അതായത് ആ ഹോസ്റ്റിൽ IP ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമാണ്, കടന്നുപോകാൻ അനുവദിക്കുന്ന ഫയർവാൾ നിയമമുണ്ട്. വിദൂര LAN-ലെ ഹോസ്റ്റുകൾക്ക് ടണൽ വിലാസത്തിന് ഒരു മടക്കപ്പാത വേണം: ഗേറ്റ്വേയിലേക്ക് തിരികെ ചൂണ്ടുന്ന റൂട്ട്, അല്ലെങ്കിൽ ക്ലൈന്റ് വശത്ത് ബോധപൂർവം രൂപകൽപ്പന ചെയ്ത NAT. വിതരണത്തിന്റെ സ്വതേയുള്ള മൂല്യം അനുമാനിക്കാതെ sysctl net.ipv4.ip_forward ഉപയോഗിച്ച് ക്ലൈന്റിലെ ഫോർവേഡിംഗ് ക്രമീകരണം സ്ഥിരീകരിക്കുക.

മറ്റ് VPN ക്ലൈന്റുകൾ ആ സബ്നെറ്റിൽ എത്തേണ്ടതുണ്ടെങ്കിൽ ക്രമീകരണം വീണ്ടും വളരുന്നു: സെർവറിന് client-to-client വേണം, ആ ക്ലൈന്റുകൾ പ്രിഫിക്സ് ടണലിലൂടെ റൂട്ട് ചെയ്യണം. ഇവയൊന്നും സെർവറിന്റെ സ്വന്തം റൂട്ട് പട്ടികയിൽ നിന്ന് വരുന്നതല്ല.

സെർവറിൽ നിന്നല്ല, യഥാർത്ഥ ഉറവിടത്തിൽ നിന്ന് ഒരു ലക്ഷ്യം പരിശോധിക്കുക. ബന്ധമില്ലാത്ത ഒരു LAN ഹോസ്റ്റിൽ നിന്ന് ക്ലൈന്റിന് പിന്നിലുള്ള ഹോസ്റ്റിലേക്കുള്ള ping ഒരൊറ്റ നീക്കത്തിൽ മടക്കപ്പാത, ഫോർവേഡിംഗ് നിയമം, പീയർ ഉടമസ്ഥത എന്നിവ പരിശോധിക്കുന്നു, വിജയകരമായ handshake ഐഡന്റിറ്റി മാത്രം തെളിയിക്കുന്നു. തുടർന്ന് ഉടമയായ പീയർ വിച്ഛേദിച്ച് റൂട്ട് എന്ത് ചെയ്യുന്നു എന്ന് രേഖപ്പെടുത്തുക, കാരണം ആ ഉത്തരമാണ് നിങ്ങളുടെ പരാജയ മോഡ്.