OpenVPN-ൽ റൂട്ട് എവിടെയാണ് വേണ്ടത്: ക്ലയന്റിലോ സെർവറിലോ?
സെർവർ കോൺഫിഗിൽ നഗ്നമായ റൂട്ട് സെർവറിനെ മാറ്റുന്നു, ക്ലയന്റിനെയല്ല. ക്ലയന്റ് ഫയൽ, ആഗോള push അല്ലെങ്കിൽ ഒരു ക്ലയന്റിനുള്ള push തിരഞ്ഞെടുത്ത് എന്ത് എത്തി എന്ന് പരിശോധിക്കുക.
നിങ്ങൾ സെർവർ കോൺഫിഗറേഷനിൽ route 10.60.0.0 255.255.255.0 ചേർക്കുന്നു, പുനരാരംഭിക്കുന്നു, ലാപ്‌ടോപ്പ് വീണ്ടും ബന്ധിപ്പിക്കുന്നു, എന്നിട്ടും ആ ലാപ്‌ടോപ്പിൽ നിന്ന് സബ്‌നെറ്റ് ഇപ്പോഴും എത്താനാകുന്നില്ല. വരി സ്വീകരിച്ചു, സേവനം വൃത്തിയായി ആരംഭിച്ചു, ലോഗിൽ ഒന്നും തെറ്റായി കാണുന്നില്ല. സംഭവിച്ചത് നിങ്ങൾ എഡിറ്റ് ചെയ്ത യന്ത്രത്തിൽ തന്നെ റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്തു എന്നതാണ്: ഗേറ്റ്‌വേ ഇപ്പോൾ ആ പ്രിഫിക്‌സിൽ എത്താമെന്ന് കരുതുന്നു, എന്നാൽ ക്ലയന്റിനോട് ഒന്നും പറഞ്ഞില്ല. സ്ഥാനമാണ് മുഴുവൻ ചോദ്യം, ഒരേ വരി ജീവിക്കാവുന്ന നാല് സ്ഥലങ്ങളുണ്ട്.
നാല് സ്ഥലങ്ങളും ഓരോന്നും ആര് സ്വീകരിക്കുന്നു
ക്ലയന്റിന്റെ സ്വന്തം കോൺഫിഗറേഷൻ വഴി റൂട്ട് ചേർക്കാം, ആഗോള push വഴി എല്ലാ ക്ലയന്റിനും വാഗ്ദാനം ചെയ്യാം, ക്ലയന്റ്-നിർദ്ദിഷ്ട ഫയൽ വഴി ഒരു ക്ലയന്റിന് വാഗ്ദാനം ചെയ്യാം, അല്ലെങ്കിൽ സെർവറിന്റെ സ്വന്തം റൂട്ടിംഗ് സന്ദർഭത്തിൽ എഴുതാം.
ഈ നാല് കേസുകളും ഏതാണ്ട് സമാനമായ വാക്യഘടന ഉപയോഗിക്കുന്നു, എന്നാൽ തീർത്തും വ്യത്യസ്ത ഫലങ്ങൾ നൽകുന്നു. ആദ്യത്തെ മൂന്നും ക്ലയന്റ് ടണലിലേക്ക് അയക്കുന്നതിനെ സ്വാധീനിക്കുന്നു; നാലാമത്തേത് സെർവർ ഒരു നെറ്റ്‌വർക്കിലേക്ക് എങ്ങനെ എത്തുന്നു എന്നതിനെ സ്വാധീനിക്കുന്നു, ഇത് സെർവർക്ക് തന്നെ ഒരു പാത ആവശ്യമുള്ളപ്പോൾ ഉപകാരപ്രദവും വിതരണമായി തെറ്റിദ്ധരിക്കപ്പെട്ടാൽ ഹാനികരവുമാണ്.
വരി എഴുതുന്നതിന് മുൻപ് നാലിൽ ഏതാണ് വേണ്ടതെന്ന് തീരുമാനിച്ച് സ്വീകർത്താവിനെ സ്ഥിരീകരിക്കുക.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
നഗ്നമായ സെർവർ റൂട്ട് ആളുകളെ അമ്പരപ്പിക്കുന്നത് എന്തുകൊണ്ട്
സെർവർ കോൺഫിഗറേഷനാണ് അഡ്മിനിസ്ട്രേറ്റർമാർ ആദ്യം നോക്കുന്ന സ്ഥലം, അവിടത്തെ റൂട്ട് നിർദ്ദേശം VPN നെറ്റ്‌വർക്കിനെക്കുറിച്ചുള്ള ഒരു പ്രസ്താവനയായി വായിക്കപ്പെടുന്നു. അതല്ല. OpenVPN അതിനെ ഡീമൺ പ്രവർത്തിക്കുന്ന യന്ത്രത്തിലെ പ്രാദേശിക റൂട്ട് ഇൻസ്റ്റാളേഷനായി കണക്കാക്കുന്നു, ഇത് നിങ്ങൾ ip route ഉപയോഗിച്ച് ചെയ്ത് പിന്നീട് മറക്കുന്ന അതേ തരം മാറ്റമാണ്.
വിതരണത്തിന് റൂട്ട് push ചെയ്യേണ്ടതുണ്ട്, push-ന് ക്ലയന്റ് അത് വലിച്ചെടുക്കേണ്ടതുണ്ട്. വലിച്ചെടുത്ത ഓപ്ഷനുകൾ നിർജ്ജീവമാക്കി ആരംഭിച്ച ക്ലയന്റ് വാഗ്ദാനം പൂർണ്ണമായി അവഗണിക്കുന്നു. സെർവർ ഫയൽ വീണ്ടും എഴുതുന്നതിന് മുൻപ് ആ കൈകൊടുക്കലിന്റെ രണ്ട് അറ്റങ്ങളും പരിശോധിക്കുക, കാരണം സെർവർ ലോഗ് പരാതിപ്പെടില്ല: അതിന്റെ ഭാഗത്തുനിന്ന് വാഗ്ദാനം അയച്ചു. സ്വീകരിച്ച റൂട്ട് അടുത്ത കണക്ഷനിൽ മാത്രമേ പ്രാബല്യത്തിൽ വരികയുള്ളൂ, നിങ്ങൾ ഇപ്പോൾ ഉള്ള സെഷനിൽ ഒരിക്കലുമില്ല.
രണ്ടും വേറിട്ട പ്രവർത്തനങ്ങളായി കാണുമ്പോൾ പരാജയം നിഗൂഢമല്ലാതാകുന്നു: സെർവർ പ്രിഫിക്‌സിൽ എത്തുന്നു, ക്ലയന്റ് എത്തുന്നില്ല, രണ്ട് പ്രസ്താവനകളും ഒരേ സമയം ശരിയാണ്.
ഓരോ ക്ലയന്റിനുമുള്ള ഫയലുകളും അവ പൊരുത്തപ്പെടുന്ന ഐഡന്റിറ്റിയും
ക്ലയന്റ്-നിർദ്ദിഷ്ട ഫയലിന് സെർവർ ആധികാരികമാക്കിയ ഐഡന്റിറ്റിയുടെ പേര് നൽകുന്നു, അത് സ്വതവേ സർട്ടിഫിക്കറ്റിന്റെ പൊതുനാമമാണ്. ഡെസ്‌ക്ടോപ്പ് ക്ലയന്റിലെ സൗഹൃദ കണക്ഷൻ നാമം ആ മൂല്യമല്ല, പൊരുത്തക്കേട് ഒരിക്കലും വായിക്കാത്ത ഫയൽ സൃഷ്ടിക്കുന്നു.
സെർവർ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന ഡയറക്ടറി പരിശോധിച്ച്, ഫയൽനാമം ആധികാരികമാക്കിയ ഐഡന്റിറ്റിയുമായി കൃത്യമായി പൊരുത്തപ്പെടുന്നുവെന്ന് സ്ഥിരീകരിക്കുക, വലിയക്ഷരങ്ങളും ചെറിയക്ഷരങ്ങളും ഉൾപ്പെടെ.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/ആ ഫയലിനുള്ളിലും റൂട്ട് push ചെയ്യേണ്ടതുണ്ട്, കാരണം ക്ലയന്റ്-നിർദ്ദിഷ്ട സന്ദർഭം ആ ക്ലയന്റിന്റെ സെഷനിൽ പ്രയോഗിക്കുന്ന ഓപ്ഷനുകളുടെ കൂട്ടമാണ്, പ്രാദേശിക റൂട്ടിംഗ് പട്ടികയല്ല. അവിടത്തെ നഗ്നമായ റൂട്ടിന് ആഗോള ഫയലിലെ നഗ്നമായ റൂട്ടിന്റെ അതേ പ്രശ്നമുണ്ട്.
ക്ലയന്റിന്റെ സ്വന്തം ഫയലും അതിനുടമയായ ഉപകരണവും
ക്ലയന്റിന്റെ കോൺഫിഗിൽ സ്ഥാപിച്ച റൂട്ട് ആ ക്ലയന്റ് ബന്ധിപ്പിക്കുമ്പോൾ ഇൻസ്റ്റാൾ ചെയ്യപ്പെടുകയും വിച്ഛേദിക്കുമ്പോൾ നീക്കം ചെയ്യപ്പെടുകയും ചെയ്യുന്നു, ഇത് സ്ഥിരമായ ലക്ഷ്യത്തിന് ശരിയായ ജീവിതചക്രമാണ്.
നെറ്റ്വർക്ക് മാനേജർ പ്രൊഫൈലിന്റെ ഉടമയാണെങ്കിൽ, അത് ആ ഓപ്ഷനുകൾ ഒരിക്കൽ ഇറക്കുമതി ചെയ്ത് പിന്നീട് സ്വന്തം പകർപ്പ് സൂക്ഷിച്ചേക്കാം. പിന്നീട് ഡൗൺലോഡ് ചെയ്ത ഫയൽ എഡിറ്റ് ചെയ്യുന്നത് ഒന്നും മാറ്റുന്നില്ല, ഇത് "റൂട്ട് ഉണ്ട് പക്ഷേ ബാധകമല്ല" എന്നതിന്റെ സാധാരണ കാരണമാണ്.
നിങ്ങൾ ഡൗൺലോഡ് ചെയ്ത ഫയലിനുപകരം സജീവ പ്രൊഫൈൽ പരിശോധിക്കുക, മാനേജർ കാണിക്കുന്ന ഇറക്കുമതി ചെയ്ത ക്രമീകരണങ്ങളും പരിശോധിക്കുക. തുടർന്ന് ബന്ധിപ്പിച്ച് ഒരു നിർദ്ദിഷ്ട വിലാസം ഏത് പാത ഉപയോഗിക്കുന്നു എന്ന് സിസ്റ്റത്തോട് ചോദിക്കുക, ടെക്‌സ്‌റ്റ് ഫയലിൽ റൂട്ട് ഉണ്ടായിരുന്നതിനാൽ ടണൽ വിജയിച്ചു എന്ന് കരുതുന്നതിനുപകരം.
ക്ലയന്റിൽ പരിശോധിച്ച്, തുടർന്ന് മടക്കപ്പാത പരിശോധിക്കുക
ലക്ഷ്യത്തെക്കുറിച്ച് ക്ലയന്റിന്റെ സ്വന്തം റൂട്ടിംഗ് പട്ടികയോട് ചോദിക്കുക, സെർവറിന്റേതിനോടല്ല. പ്രിഫിക്‌സിനുള്ളിലെ ഒരു ഹോസ്റ്റിനായുള്ള തിരച്ചിൽ ഉപയോഗിക്കുന്ന ഇന്റർഫേസും അടുത്ത ഹോപ്പും കാണിക്കാൻ മതിയാകും.
ip route get 10.60.0.10തിരച്ചിൽ ടണലിലേക്ക് ചൂണ്ടുന്നുവെങ്കിൽ വിതരണം പ്രവർത്തിച്ചു, ബാക്കിയുള്ള പ്രശ്നം മറ്റെവിടെയോ ആണ്. അത് സ്വതവേയുള്ള ഗേറ്റ്‌വേയിലേക്ക് ചൂണ്ടുന്നുവെങ്കിൽ, റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്തിട്ടില്ല, ക്ലയന്റ്-സൈഡ് ഓപ്ഷൻ ഫിൽട്ടർ ചെയ്തു, അല്ലെങ്കിൽ ക്ലയന്റ് ഉപയോഗിക്കാത്ത പ്രൊഫൈലിന്റേതാണ്.
വിതരണം പ്രവർത്തിച്ചു എന്നും എന്നിട്ടും ഒന്നും പ്രതികരിക്കുന്നില്ല എന്നും കരുതുക: അപ്പോൾ ഗേറ്റ്‌വേയിലെ ഫോർവേഡിംഗ്, എതിർവശത്തിന്റെ മടക്കപ്പാത, അവയ്ക്കിടയിലെ ഏതെങ്കിലും ഫയർവാൾ എന്നിവ പരിശോധിക്കുക. റൂട്ട് ഒരു പാത തിരഞ്ഞെടുക്കുന്നു, അത് പ്രവേശനം നൽകുന്നില്ല.