അതേ ഹോസ്റ്റിൽ അതിന്റെ സർവർ പ്രവർത്തിക്കുമ്പോൾ OpenVPN ക്ലയന്റ് നിലയ്ക്കുന്നു

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

പരാജയം ക്രമരഹിതമല്ല, അത് ഓതന്റിക്കേഷൻ പ്രശ്നവുമല്ല. ഒരു മെഷീനിലെ രണ്ട് ഡീമണുകൾ ഒരേ ലോക്കൽ സോക്കറ്റിനും ഒരേ റൂട്ടിംഗ് ടേബിളിനും വേണ്ടി മത്സരിക്കുന്നു, അവസാനം ആരംഭിക്കുന്നതോ വീണ്ടും കണക്ട് ചെയ്യുന്നതോ സാധാരണയായി വിജയിക്കുന്നു. ഈ രണ്ട് കൂട്ടിയിടികളിൽ ഏതാണ് നിങ്ങൾക്കുള്ളതെന്ന് അറിയുന്നത് ആദ്യം എവിടെ നോക്കണമെന്ന് തീരുമാനിക്കുന്നു.

ലക്ഷണം വിപരീതമായി വായിക്കുക

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

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

ഓരോ ഇൻസ്റ്റൻസിനും ഒരു സോക്കറ്റും ഒരു ഉപകരണവും

കേൾക്കുന്ന സർവർ അതിന്റെ പോർട്ട് ബൈൻഡ് ചെയ്യുന്നു; ഔട്ട്ബൗണ്ട് ക്ലയന്റിനും അതിന്റെ എൻകാപ്സുലേറ്റഡ് ട്രാഫിക്കിനായി ഒരു ലോക്കൽ പോർട്ട് ആവശ്യമാണ്. രണ്ടും ഒരേ ഹോസ്റ്റിൽ ജീവിക്കുമ്പോൾ, ക്ലയന്റിന്റെ സ്ഥിരസ്ഥിതി സ്വഭാവം സർവറിന്റെ പോർട്ടുമായി കൂട്ടിയിടിച്ചേക്കാം. ക്ലയന്റിന്റെ ലോക്കൽ പോർട്ട് പിൻ ചെയ്യാം, കൂടാതെ ഇണയ്ക്ക് നിശ്ചിത സ്രോതസ്സ് പോർട്ട് ആവശ്യമില്ലാത്തിടത്ത് ബൈൻഡിംഗ് ഒഴിവാക്കാം:

lport 1195
nobind
dev tun1

ആ സംഖ്യകൾ ഉദാഹരണങ്ങളാണ്, ആവശ്യകതയല്ല. പ്രധാനം, ക്ലയന്റ് സർവറിന്റെ പോർട്ടിനായുള്ള മത്സരം നിർത്തുന്നു എന്നതും ഓരോ ഇൻസ്റ്റൻസിനും വേറിട്ട ടണൽ ഉപകരണം ലഭിക്കുന്നു എന്നതുമാണ്. tun0 പങ്കിടുന്ന രണ്ട് ഡീമണുകൾ, അവയുടെ പോർട്ടുകൾ വ്യത്യസ്തമായാലും, പരസ്പരം ഉപകരണ അവസ്ഥ മേലെഴുതുന്നു, അതിനാൽ ഓരോ ടണലിനും ഒരു ഉപകരണം ഓപ്ഷണലല്ല.

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

സ്ഥിരസ്ഥിതി റൂട്ടിന് ഒരു ഉടമയെ തിരഞ്ഞെടുക്കുക

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

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

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

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

സ്റ്റാറ്റസ് ലൈൻ കൊണ്ടല്ല, ടേബിൾ കൊണ്ട് പരിശോധിക്കുക

കണക്ട് ചെയ്തുവെന്ന് റിപ്പോർട്ട് ചെയ്യുന്ന ക്ലയന്റ് അതിന്റെ കൺട്രോൾ ചാനൽ മാത്രമാണ് തെളിയിക്കുന്നത്. ഓരോ കണക്ഷനും മുമ്പും ശേഷവും റൂട്ടിംഗ് അവസ്ഥ രേഖപ്പെടുത്തുക, തുടർന്ന് ഒരു യഥാർത്ഥ ലക്ഷ്യസ്ഥാനം ഏത് ഉപകരണം ഉപയോഗിക്കുമെന്ന് കെർണലിനോട് ചോദിക്കുക:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

രണ്ടാമത്തെ ടണൽ ആരംഭിക്കുമ്പോൾ വെണ്ടർ വിലാസത്തിനായി തിരഞ്ഞെടുത്ത ഉപകരണം മാറുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് റൂട്ട് കൂട്ടിയിടിയുണ്ട്. രണ്ട് പ്രോസസുകളും ഒരേ ലോക്കൽ പോർട്ടിൽ പ്രത്യക്ഷപ്പെടുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് സോക്കറ്റ് കൂട്ടിയിടിയുണ്ട്. രണ്ടാമത്തേതില്ലാതെ ഒന്നാമത്തേത് ശരിയാക്കുന്നത് പരാജയം അടുത്ത റീകണക്ടിലേക്ക് മാറ്റുന്നു മാത്രം.

പോർട്ടുകൾ, ഉപകരണങ്ങൾ, ടേബിളുകൾ, റൂട്ട് ഉടമ എന്നിവ ഹോസ്റ്റിന്റെ റൺബുക്കിൽ എഴുതുക. അല്ലെങ്കിൽ മൂന്നാമത്തെ ടണൽ ചേർക്കുന്ന അടുത്ത വ്യക്തി അതേ കൂട്ടിയിടി വീണ്ടും കണ്ടെത്തും, കാണാവുന്ന ഏക തെളിവ് മറ്റൊരാളുടെ ഡീമൺ റീസ്റ്റാർട്ട് ചെയ്യുന്നതുവരെ പ്രവർത്തിക്കുന്ന ഒരു കണക്ഷൻ മാത്രമായിരിക്കും.