ഒരേ റൗട്ടറിന് പിന്നിൽ എന്തുകൊണ്ട് ഒരു VPN ക്ലയന്റ് മാത്രം കണക്റ്റ് ചെയ്യുന്നു

രണ്ട് ലാപ്ടോപ്പുകൾ ഒരേ വീട്ടിലെ നെറ്റ്വർക്കിലുണ്ട്, ഒപ്പം ഓഫീസിലെ VPN അവയിൽ കൃത്യമായി ഒന്നിനെ മാത്രം സ്വീകരിക്കുന്നു. രണ്ടാമത്തേത് സമയപരിധി കഴിയുന്നു അല്ലെങ്കിൽ ആദ്യത്തേത് വിച്ഛേദിക്കുന്നതുവരെ കാത്തിരിക്കുന്നു, രണ്ട് ശ്രമങ്ങൾക്കിടയിൽ ആരും ക്ലയന്റ് ക്രമീകരണം തൊട്ടിട്ടില്ല. ലോഗിൻ വിവരങ്ങൾ ഒരു മിനിറ്റ് മുൻപ് പ്രവർത്തിച്ചവ തന്നെയാണ്, ഇതാണ് പ്രാമാണീകരണം പരാജയം അല്ലെന്ന സൂചന. ഈ മാതൃക സൃഷ്ടിക്കുന്നത് മൂന്ന് സംവിധാനങ്ങളാണ്, ഏതിനെ നേരിടുന്നു എന്ന് സർവറിന്റെ സ്വന്തം ലോഗ് പറയുന്നു.

ക്ലയന്റിനെ തൊടുന്നതിന് മുൻപ് ഗേറ്റ്വേ ലോഗ് വായിക്കുക

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

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

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ഫലം എഴുതിവയ്ക്കുക, കാരണം ലോഗിന്റെ മൂന്ന് ഫലങ്ങൾ മൂന്ന് ബന്ധമില്ലാത്ത അറ്റകുറ്റപ്പണികളിലേക്ക് നയിക്കുന്നു. മൂന്നിൽ ഏതാണ് കണ്ടതെന്ന് പറയുന്ന കുറിപ്പ് ക്ലയന്റ് പിശകിന്റെ സ്ക്രീൻഷോട്ടിനേക്കാൾ മൂല്യമുള്ളതാണ്.

റൗട്ടർ GRE, NAT-T എന്നിവയുമായി എന്ത് ചെയ്യുന്നു

PPTP ആണ് പതിവ് കുറ്റവാളി: നിയന്ത്രണ ചാനൽ TCP 1723 ആണ്, ഡാറ്റ പാത GRE, അതായത് IP പ്രോട്ടോക്കോൾ 47. പല ഉപഭോക്തൃ റൗട്ടറുകളും ഒരു നിയന്ത്രണ കണക്ഷൻ മാത്രം പിന്തുടരുന്ന PPTP സഹായിയോടെ വരുന്നു, അതിനാൽ അതേ NAT-ന് പിന്നിലെ രണ്ടാമത്തെ ക്ലയന്റ് അതിന്റെ നിയന്ത്രണ ചാനൽ തുറന്നിട്ടും ഡാറ്റ പാത ലഭിക്കുന്നില്ല. 47 നമ്പർ TCP പോർട്ട് ഫോർവേഡ് ചെയ്യുന്നത് GRE-യ്ക്ക് ഒന്നും ചെയ്യുന്നില്ല, കാരണം GRE ഒരു പ്രോട്ടോക്കോൾ നമ്പറാണ്, പോർട്ടല്ല.

L2TP IPsec-ന് മുകളിൽ രൂപകൽപ്പനയാൽ തന്നെ വ്യത്യസ്തമായി പെരുമാറുന്നു: IKE UDP 500 ഉപയോഗിക്കുന്നു, NAT കടന്നുപോകൽ സംരക്ഷിത പേലോഡിനെ UDP 4500-ലേക്ക് മാറ്റുന്നു, ഒരു വിലാസത്തിന് പിന്നിലെ പല ക്ലയന്റുകൾക്കും ഒരേ ഗേറ്റ്വേയിൽ എത്താൻ എൻകാപ്സുലേഷൻ ഉണ്ട്. ആ രൂപകൽപ്പന ഗേറ്റ്വേയോ ഇടയിലുള്ള ഉപകരണമോ ഓരോ വിലാസത്തിനും സെഷൻ പരിധി ചുമത്തുന്നത് തടയുന്നില്ല, സോഫയിൽ നിന്ന് രണ്ട് പരാജയങ്ങളും ഒരേപോലെ തോന്നുന്നു. SoftEther-ന്റെ സ്വന്തം പ്രോട്ടോക്കോളിനും ഇതേ വിഭാഗത്തിലെ പ്രശ്നമുണ്ട്: പ്രവർത്തിക്കുന്ന പാസ്-ത്രൂ ഇല്ലാത്ത റൗട്ടർ LAN-ൽ നിന്നുള്ള ആദ്യ ക്ലയന്റിനെ അകത്തേക്ക് വിട്ട് രണ്ടാമത്തേതിനെ ഉപേക്ഷിക്കുന്നു. റൗട്ടറിന്റെ ALG അല്ലെങ്കിൽ പാസ്-ത്രൂ സ്വിച്ച് രണ്ട് സ്ഥാനങ്ങളിലും പരീക്ഷിക്കുക, കാരണം പഴയ ക്ലയന്റിനായി എഴുതിയ സഹായി ഇന്നത്തെ ക്ലയന്റ് അയയ്ക്കുന്ന പാക്കറ്റുകൾ കേടാക്കാം.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

ട്രാൻസ്പോർട്ട് പരിധികളെപ്പോലെ തോന്നുന്ന ഐഡന്റിറ്റി പരിധികൾ

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

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

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

അറ്റകുറ്റപ്പണി ലോഗ് എൻട്രിയുമായി ചേർക്കുക

ലോഗിലെ നിരസിക്കൽ ഓരോ ഉപകരണത്തിനും വെവ്വേറെ ലോഗിൻ വിവരങ്ങൾ, സേവനം നടത്തുന്നയാളിൽ നിന്ന് ഉയർന്ന പരിധി, അല്ലെങ്കിൽ ഒരു മെഷീന് രണ്ടാമത്തെ ഗേറ്റ്വേ എൻഡ്പോയിന്റ് ആവശ്യപ്പെടുന്നു. ഒരു രണ്ടാമത്തെ ശ്രമവും സർവറിൽ എത്തുന്നില്ലെങ്കിൽ, ശാശ്വത പരിഹാരം പ്രോട്ടോക്കോൾ ഫോർവേഡ് ചെയ്യുന്നതും ഒന്നിൽ കൂടുതൽ സെഷൻ നിലനിർത്തുന്നതുമായ റൗട്ടർ, അല്ലെങ്കിൽ റൗട്ടർ നന്നായി കൈകാര്യം ചെയ്യുന്ന ഒരു ട്രാൻസ്പോർട്ട്, ഉദാഹരണത്തിന് ഒരു TCP അല്ലെങ്കിൽ UDP പ്രവാഹം. അവയിൽ നിന്ന് തിരഞ്ഞെടുക്കുന്നത് ഹാർഡ്വെയറിന്റെ ആയുസ്സിനെക്കുറിച്ചുള്ള തീരുമാനമാണ്, ക്ലയന്റ് ക്രമീകരണത്തെക്കുറിച്ചല്ല.

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

രണ്ട് ജീവനുള്ള സെഷനുകൾ പരിശോധിക്കൽ

രണ്ട് ഉപകരണങ്ങളും ഒരേ സമയം കണക്റ്റ് ചെയ്യുക, ഓരോന്നിലും ഉദ്ദേശിച്ച ആപ്പ് പ്രവർത്തിപ്പിക്കുക, പിന്നീട് അവയിലൊന്ന് വീണ്ടും കണക്റ്റ് ചെയ്ത് ആവർത്തിക്കുക. ക്ഷണനേരം കാണുന്ന രണ്ടാമത്തെ ഐക്കൺ ട്രാഫിക്കിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, പത്ത് മിനിറ്റ് കഴിഞ്ഞ് വീഴുന്ന സെഷൻ മറ്റൊരു ഉടമയുടെ മറ്റൊരു തകരാറാണ്. സർവർ അവസാനം റിപ്പോർട്ട് ചെയ്യുന്നത് ഉപയോക്താക്കൾ കണ്ടതുമായി താരതമ്യം ചെയ്യുക, കാരണം ഈ രണ്ട് വിവരണങ്ങളും പലപ്പോഴും ഒത്തുപോകുന്നില്ല.

രണ്ട് സെഷനുകളും അതിജീവിച്ച് ട്രാഫിക് വഹിച്ചാൽ, പരിഹാരം നിലനിൽക്കുന്നു, തുടക്കത്തിൽ എഴുതിയ കുറിപ്പ് എന്താണ് തെറ്റായിരുന്നത് എന്നതിന്റെ രേഖയാകുന്നു. ഒന്ന് മാത്രം അതിജീവിച്ചാൽ, ആദ്യ ഘട്ടത്തിലേക്ക് മടങ്ങി ഇപ്പോൾ മൂന്ന് ലോഗ് ഫലങ്ങളിൽ ഏതാണ് നിങ്ങൾക്കുള്ളതെന്ന് പരിശോധിക്കുക, കാരണം ഉത്തരം മാറിയിരിക്കാം. റൗട്ടർ സഹായികൾ മറ്റൊരു നെറ്റ്വർക്കിൽ വീണ്ടും പ്രത്യക്ഷപ്പെടുന്ന പ്രശ്നം മറയ്ക്കാം, എന്നാൽ ഓരോ വിലാസത്തിനുമുള്ള പരിധി ഉപകരണത്തെയല്ല, ഉപയോക്താവിനെ പിന്തുടരുന്നു. രണ്ടാമത്തെ നെറ്റ്വർക്കിൽ നിന്ന് പരീക്ഷിക്കുന്നതാണ് ഇവയിൽ യഥാർത്ഥത്തിൽ എന്താണ് നിങ്ങൾ ശരിയാക്കിയത് എന്ന് അറിയാനുള്ള ഏറ്റവും വിലകുറഞ്ഞ വഴി.