ഒരു OpenVPN ക്ലയന്റിൽ രണ്ട് സേവന വിലാസങ്ങൾ: iroute ഉം lo ഉം

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

അലിയാസ് പ്രാദേശികം, ഉടമസ്ഥത ദൂരെ

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

ക്ലയന്റിൽ വിലാസം ഹോസ്റ്റിന്റേതാണ്, ഭൗതിക ലിങ്കിൽ ഒരിക്കലും പ്രത്യക്ഷപ്പെടരുതാത്ത സേവന ഐഡന്റിറ്റിക്ക് ലൂപ്ബാക്ക് സ്വാഭാവിക വീടാണ്. ഹബ്ബിൽ പിയർ-ടു-പ്രിഫിക്സ് മാപ്പിംഗ് സർവർ മാത്രം വായിക്കുന്ന വേറിട്ട പ്രഖ്യാപനമാണ്. രണ്ട് റെക്കോർഡുകളിൽ ഒന്നും മറ്റൊന്നിനെ സൂചിപ്പിക്കുന്നില്ല.

നിങ്ങളുടെ കുറിപ്പുകളിലും രണ്ട് ശ്രേണികൾ വേറിട്ട് സൂക്ഷിക്കുക. ഉദാഹരണത്തിലെ വിലാസങ്ങൾ ഡോക്യുമെന്റേഷൻ മൂല്യങ്ങളാണ്, അവ യഥാർത്ഥ LAN-മായി ഓവർലാപ്പ് ചെയ്യുന്നത് പ്രവർത്തിക്കുന്ന ക്രമീകരണത്തെ തകർന്നതായി കാണിക്കാനുള്ള ഏറ്റവും വേഗതയുള്ള വഴിയാണ്.

ക്ലയന്റിൽ വിലാസം സ്ഥിരമായി ചേർക്കുക

സേവന വിലാസം ഹോസ്റ്റ് പ്രിഫിക്സിനൊപ്പം ലൂപ്ബാക്കിൽ വയ്ക്കുക, ഹോസ്റ്റ് അതിനെ എത്തിച്ചേരേണ്ട സബ്നെറ്റായി അല്ല, പ്രാദേശിക ഇൻപുട്ടായി കണക്കാക്കാൻ. ip address add 10.66.0.10/32 dev lo ഒരു വിലാസത്തിന് അത് ചെയ്യുന്നു, രണ്ടാമത്തെ വിലാസത്തിന് കമാൻഡ് ആവർത്തിക്കുന്നത് രണ്ട് സേവനങ്ങളെ മാതൃകയാക്കുന്നു.

ഇത് ഒരു തവണത്തെ പരിശോധനയായി പ്രവർത്തിപ്പിക്കുക, തുടർന്ന് ഹോസ്റ്റിന്റെ നെറ്റ്വർക്ക് കോൺഫിഗറേഷൻ ഉള്ളതിലേക്ക് മാറ്റുക, കാരണം റൺടൈം കൂട്ടിച്ചേർക്കൽ റീബൂട്ടിൽ അപ്രത്യക്ഷമാകും, വീണ്ടും ബന്ധിപ്പിക്കുമ്പോൾ പകർപ്പുകൾ കൂടും. നെറ്റ്വർക്കിന് ശേഷം ക്രമീകരിച്ച systemd യൂണിറ്റ് ഒരു ഓപ്ഷനാണ്, വിതരണത്തിന്റെ നെറ്റ്വർക്ക് മാനേജർ മറ്റൊന്നാണ്. ഏത് തിരഞ്ഞെടുത്താലും, ആപ്ലിക്കേഷൻ ബൈൻഡ് ചെയ്യുന്നതിന് മുമ്പ് വിലാസം ഉണ്ടായിരിക്കണം, അല്ലെങ്കിൽ സേവനം തെറ്റായ സോക്കറ്റിൽ ഉയരും. മാനുവൽ കമാൻഡിന് ശേഷമല്ല, റീബൂട്ടിന് ശേഷം ip address show dev lo ഉപയോഗിച്ച് പരിശോധിക്കുക.

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

ഹബ് യഥാർത്ഥത്തിൽ വായിക്കുന്ന CCD ഫയലിൽ അത് ആവശ്യപ്പെടുക

സർവറിൽ ഉടമസ്ഥതാ പ്രഖ്യാപനം പ്രാമാണീകരിച്ച പൊതുനാമം തിരഞ്ഞെടുക്കുന്ന ഓരോ ക്ലയന്റ് ഫയലിലേക്ക് പോകുന്നു, client-config-dir പേരിട്ട ഡയറക്ടറിക്കുള്ളിൽ. വരി iroute 10.66.0.10 255.255.255.255 ആണ്, ഓരോ വിലാസത്തിനും ഒന്ന്, ആ ലക്ഷ്യസ്ഥാനത്തേക്കുള്ള ട്രാഫിക് ഏത് പിയർ സ്വീകരിക്കണം എന്ന് അത് സർവറിനോട് പറയുന്നു.

രണ്ട് വിശദാംശങ്ങൾ ഇതിനെ നിശബ്ദമായി തകർക്കുന്നു. ഫയലിന്റെ പേര് സർവർ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന പേരുമായി പൊരുത്തപ്പെടണം, username-as-common-name രംഗത്തുള്ളപ്പോൾ അത് വ്യത്യസ്തമാണ്. iroute ക്ലയന്റ് കോൺഫിഗറേഷൻ ഡയറക്ടറി ക്രമീകരിച്ച TUN മോഡിൽ മാത്രമേ പ്രാബല്യത്തിൽ വരൂ, അതിനാൽ ബ്രിഡ്ജ് വിന്യാസത്തിൽ അതേ വരി ഒന്നും ചെയ്യുന്നില്ല. നിലവിലുള്ള ഫയലിൽ വരികൾ ചേർക്കുക, അത് മാറ്റിസ്ഥാപിക്കരുത്, കാരണം അതിൽ ഇതിനകം സ്ഥിര വിലാസമോ push ഓപ്ഷനുകളോ ഉണ്ടാകാം. OpenVPN 2.6 റഫറൻസ് ഡയറക്ടറിയും ഉടമസ്ഥതാ നിർദ്ദേശവും രേഖപ്പെടുത്തുന്നു.

ഹബ്ബിന്റെ സ്വന്തം കേർണലിനും ആ ലക്ഷ്യസ്ഥാനങ്ങളിലേക്ക് പാത വേണം, പ്രാദേശികമായി ഉത്പാദിപ്പിക്കുന്ന ട്രാഫിക് ടണൽ പ്രക്രിയയിൽ പ്രവേശിക്കാൻ. സർവർ കോൺഫിഗറേഷനിലെ route 10.66.0.10 255.255.255.255 സർവർ സ്വയം സൃഷ്ടിക്കുന്ന ട്രാഫിക് ഉൾക്കൊള്ളുന്നു, മറ്റ് ക്ലയന്റുകൾക്ക് ലക്ഷ്യസ്ഥാനം സ്വയം പഠിക്കാൻ push "route 10.66.0.10 255.255.255.255" വേണം.

റൂട്ടിംഗും അനുമതിയും വേറിട്ട് നിൽക്കുന്നു. പുഷ് ചെയ്ത റൂട്ട് ക്ലയന്റിനോട് പാക്കറ്റുകൾ എവിടേക്ക് അയക്കണം എന്ന് പറയുന്നു, ഒന്നും അനുവദിക്കുന്നില്ല; സേവനം ഇപ്പോഴും വിളിക്കുന്നയാളെ സ്വന്തം നിബന്ധനകളിൽ സ്വീകരിക്കണം.

ഇൻപുട്ട് നയവും മറുപടി പാതയും പരിശോധിക്കുക

അലിയാസിന് അയച്ച പാക്കറ്റ് ഉടമയായ ഹോസ്റ്റിൽ പ്രാദേശിക ഇൻപുട്ടായി എത്തുന്നു, അതിനാൽ ചോദ്യം പ്രാദേശിക ഫയർവാൾ ആ ഉറവിടവും പോർട്ടും അനുവദിക്കുന്നുണ്ടോ എന്നതാണ്. മുഴുവൻ വിലാസം തുറക്കുന്നതിന് പകരം VPN ഉറവിട ശ്രേണിയിൽ നിന്ന് നിർദ്ദിഷ്ട സേവന പോർട്ട് അനുവദിക്കുക.

മറുപടികൾക്ക് വിളിക്കുന്നയാളിലേക്ക് തിരികെയുള്ള പാത വേണം. സാധാരണ ടണൽ പൂളിനുള്ളിലെ വിളിക്കുന്നയാൾക്ക് ആ പാത ഇതിനകം ഉണ്ട്, കാരണം ടണൽ ഉപകരണം അത് വഹിക്കുന്നു. മറ്റൊരു റൂട്ട് ചെയ്ത നെറ്റ്വർക്കിന് പിന്നിലുള്ള വിളിക്കുന്നയാൾക്ക് ആ നെറ്റ്വർക്കിന്റെ തിരിച്ചുവരവ് റൂട്ടും വേണം, ഇവിടെയാണ് അസമമായ ക്രമീകരണങ്ങൾ പാക്കറ്റുകൾ നഷ്ടപ്പെടുത്തുന്നത്.

അതേ പോർട്ടിൽ മറ്റൊരു വിലാസത്തിലേക്ക് ബന്ധിച്ച രണ്ടാമത്തെ ശ്രോതാവിനെ ശ്രദ്ധിക്കുക, കാരണം കേർണൽ പൊരുത്തപ്പെടുന്ന സോക്കറ്റിലേക്ക് നൽകുന്നു, ഫലങ്ങൾ ക്രമരഹിതമായി തോന്നുന്നു. ss -lntp ഉപയോഗിച്ച് പരിശോധിക്കുക, ബന്ധിച്ച വിലാസം സേവന അലിയാസാണെന്ന് ഉറപ്പാക്കുക. ഇവിടെ ഉറവിട NAT ആവശ്യമില്ല, അത് ചേർക്കുന്നത് നിങ്ങളുടെ ലോഗുകൾ ആശ്രയിക്കുന്ന വിളിക്കുന്നയാളുടെ ഐഡന്റിറ്റി മറയ്ക്കുന്നു.

വിലാസങ്ങളും ഉടമസ്ഥതയും വേറിട്ട് പരിശോധിക്കുക

രണ്ട് ഘട്ടങ്ങളായി പരിശോധിക്കുക. ആദ്യം ഉടമയായ ഹോസ്റ്റിന് അതിന്റെ അലിയാസിലുള്ള സേവനത്തിൽ സ്വയം എത്താൻ കഴിയുമെന്ന് ഉറപ്പാക്കുക, ഇത് ബൈൻഡിംഗ്, ഫയർവാൾ പ്രശ്നങ്ങളെ റൂട്ടിംഗിൽ നിന്ന് വേർതിരിക്കുന്നു. തുടർന്ന് ആപ്ലിക്കേഷന്റെ സ്വന്തം പ്രാമാണീകരണം ഉപയോഗിച്ച് യഥാർത്ഥ VPN വിളിക്കുന്നയാളിൽ നിന്ന് പരിശോധിക്കുക. ആദ്യത്തേത് വിജയിക്കുകയും രണ്ടാമത്തേത് പരാജയപ്പെടുകയും ചെയ്യുമ്പോൾ, കാണാത്ത ഭാഗം ഹബ്ബിന്റെ വശത്താണ്.

ബന്ധിപ്പിച്ചതിന് ശേഷവും നിലനിൽക്കുന്ന പരാജയ മോഡുകളും പരിശോധിക്കുക: ടണൽ താഴെയായിരിക്കുമ്പോഴും അലിയാസ് അനുവദിച്ചിരിക്കും, പിയർ ഇല്ലാതിരിക്കുമ്പോഴും ഹബ് അതിന്റെ റൂട്ട് സൂക്ഷിക്കും. ഒരു വസ്തുവും ഒറ്റയ്ക്ക് സേവനം എത്താവുന്നതാണെന്ന് തെളിയിക്കുന്നില്ല, അതിനാൽ രണ്ട് ഘട്ട പരിശോധന ലാപ്ടോപ്പിൽ നിന്നുള്ള ഒരു പിംഗിനെക്കാൾ മികച്ചതാണ്.