Synology-യിൽ OpenVPN ഹാൻഡ്‌ഷേക്ക് പരാജയപ്പെടുന്നുണ്ടോ? LAN ഫോർവേഡ് പരിശോധിക്കുക

നിങ്ങളുടെ ലാപ്ടോപ്പ് TLS ഹാൻഡ്‌ഷേക്ക് പരാജയപ്പെട്ടു എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, അതിനാൽ സർട്ടിഫിക്കറ്റുകൾ വീണ്ടും നിർമ്മിക്കാനുള്ള പ്രലോഭനം ഉണ്ടാകും. അതിനു മുമ്പ് കൂടുതൽ വിരസമായ ഒരു ചോദ്യം ചോദിക്കുക: Synology യഥാർത്ഥത്തിൽ ഏത് Ethernet പോർട്ടിലാണ് കേൾക്കുന്നത്? രണ്ട് LAN പോർട്ടുള്ള NAS-ന് രണ്ട് വിലാസങ്ങളുണ്ട്, DSM-ലെ VPN Server പാക്കേജ് അതിന്റെ OpenVPN ശ്രോതാവിനെ അവയിലൊന്നുമായി ബന്ധിക്കുന്നു. റൗട്ടർ 1194 മറ്റൊരു വിലാസത്തിലേക്ക് ഫോർവേഡ് ചെയ്യുമ്പോൾ ഒരു പാക്കറ്റും സേവനത്തിലെത്തുന്നില്ല, ഒപ്പം ക്ലയന്റിന് ചർച്ച ചെയ്യാൻ ഒന്നുമില്ല.

പിശകിന്റെ വാചകം തെറ്റിദ്ധരിപ്പിക്കുന്നു, കാരണം അത് ക്ലയന്റ് ഒടുവിൽ പരീക്ഷിച്ചതിനെ വിവരിക്കുന്നു, ആദ്യം എന്താണ് തകർന്നതെന്നല്ല. പാക്കേജ് പേജും റൗട്ടർ നിയമവും താരതമ്യം ചെയ്യാൻ രണ്ട് മിനിറ്റ് മതി.

ശ്രോതാവ് ബന്ധിച്ചിരിക്കുന്ന വിലാസം കണ്ടെത്തുക

DSM തന്റെ പോർട്ടുകളെ LAN 1, LAN 2 എന്ന് വിളിക്കുന്നു, ഓരോന്നിനും പ്രത്യേക വിലാസവും സബ്നെറ്റും ഉണ്ട്. VPN Server തുറക്കുക, OpenVPN ടാബിൽ പേരിട്ട ഇന്റർഫേസ് വായിക്കുക, തുടർന്ന് Control Panel തുറന്ന് DSM അതേ ഇന്റർഫേസിൽ ഉള്ള IPv4 വിലാസം എഴുതി വയ്ക്കുക. NAS-ന്റെ ഹോസ്റ്റ്നെയിമല്ല, ഈ രണ്ട് മൂല്യങ്ങളാണ് ഫോർവേഡ് പേരിടേണ്ടത്.

രണ്ടാമത്തെ കേബിൾ ഘടിപ്പിച്ചാൽ രണ്ടാമത്തെ ശ്രോതാവ് ഉണ്ടാകുന്നില്ല. രണ്ട് ലിങ്കുകളും ബന്ധിപ്പിച്ചതായി കാണാം, എന്നാൽ ട്രാഫിക് സ്വീകരിക്കുന്നത് ഒരു വിലാസം മാത്രമാണ്, രണ്ട് ഇന്റർഫേസുകളും ഒരേ സബ്നെറ്റിലാണെങ്കിൽ രണ്ട് വിലാസങ്ങൾ നിയമം സംരക്ഷിക്കുന്നതിന് മുമ്പ് ആരും വീണ്ടും വായിക്കാത്ത ഒരു അക്കത്തിൽ മാത്രം വ്യത്യാസപ്പെടുന്നു.

SSH വഴി സോക്കറ്റ് തന്നെ നോക്കുക, കാരണം ഡീമൺ യഥാർത്ഥത്തിൽ എന്തിനോട് ബന്ധിച്ചു എന്ന് കാണിക്കുന്ന ഒരേയൊരു സ്ഥലം അതാണ്, സെറ്റിംഗ്സ് പേജിന്റെ ഉദ്ദേശ്യമല്ല.

sudo netstat -anp | grep 1194

പുതിയത് ചേർക്കുന്നതിനുപകരം നിലവിലുള്ള ഫോർവേഡ് തിരുത്തുക

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

external 1194/udp  ->  192.0.2.20:1194/udp

ആന്തരിക പോർട്ട് കേൾക്കുന്ന പോർട്ടിന് തുല്യമായി നിർത്തുക, പ്രോട്ടോക്കോൾ സ്ഥിരതയോടെ നിർത്തുക. UDP 1194 ആണ് സ്ഥിരസ്ഥിതി ശ്രോതാവ്, TCP പ്രൊഫൈലിന് പാക്കേജ് വശത്ത് സ്വന്തം ശ്രോതാവും റൗട്ടറിൽ യോജിക്കുന്ന ഫോർവേഡും വേണം. UDP-ൽ മാത്രം കേൾക്കുന്ന സേവനത്തിലേക്ക് TCP ഫോർവേഡ് ചെയ്താൽ പിശകല്ല, നിശ്ശബ്ദതയാണ് ലഭിക്കുന്നത്.

NAS-ന്റെ വിലാസം DHCP-ൽ നിന്നാണ് വരുന്നതെങ്കിൽ, നിയമം സംരക്ഷിക്കുന്നതിന് മുമ്പ് അത് സംവരണം ചെയ്യുക. ലീസ് കാലഹരണപ്പെടുമ്പോൾ വിലാസം വീണ്ടും അനുവദിക്കപ്പെടും, ഫോർവേഡ് പഴയ മൂല്യത്തിലേക്ക് തന്നെ ചൂണ്ടിക്കൊണ്ടിരിക്കും, ആരും NAS-നെ തൊടാത്ത ഒരു ദിവസം ഹാൻഡ്‌ഷേക്ക് പരാജയപ്പെടാൻ തുടങ്ങും. NAS വശത്തെ സ്ഥിരമായ കോൺഫിഗറേഷൻ അതേ പ്രശ്നം പരിഹരിക്കും, വിലാസം റൗട്ടറിന്റെ DHCP ശ്രേണിക്ക് പുറത്താണെങ്കിൽ.

പാക്കറ്റുകൾ എങ്കിലും എത്തുന്നുണ്ടോ എന്ന് തെളിയിക്കുക

ആദ്യം NAS-ൽ ക്യാപ്ചർ ആരംഭിക്കുക, പിന്നീട് ക്ലയന്റിൽ നിന്ന് ബന്ധിപ്പിക്കുക, ഔട്ട്പുട്ടിലെ ഉറവിട വിലാസം വായിക്കുക. പരാജയത്തിന് ശേഷം ആരംഭിച്ച ക്യാപ്ചർ ഒന്നും കാണിക്കുന്നില്ല, ഒന്നും തെളിയിക്കുന്നുമില്ല.

sudo tcpdump -i any -n udp port 1194

നിശ്ശബ്ദത എന്നാൽ ട്രാഫിക് സേവനത്തിൽ എത്തുന്നതിന് മുമ്പ് മരിച്ചു എന്നാണ്: തെറ്റായ ആന്തരിക വിലാസം, DSM ഫയർവാളിൽ അടച്ച പോർട്ട്, അല്ലെങ്കിൽ ഭരണപരമായി ഓഫ് ചെയ്ത ഇന്റർഫേസ്. ഔട്ട്പുട്ടിൽ പാക്കറ്റുകൾ ഉണ്ടെങ്കിൽ ഫോർവേഡ് പ്രവർത്തിക്കുന്നു, ബാക്കിയുള്ള തകരാർ നെറ്റ്വർക്ക് പാളിക്ക് മുകളിലാണ്, അത് വളരെ ചെറിയ തിരച്ചിൽ മേഖലയാണ്.

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

പാക്കറ്റുകൾ എത്തുമ്പോൾ ഫോർവേഡിനെ കുറ്റപ്പെടുത്തുന്നത് നിർത്തുക

അടുത്ത സംശയിക്കുന്നത് പ്രൊഫൈലാണ്, സാധാരണ കാരണം പഴക്കമാണ്. കയറ്റുമതി ചെയ്ത .ovpn ഫയലിൽ കയറ്റുമതിയുടെ നിമിഷത്തിലെ അധികാരവും വസ്തുവും അടങ്ങിയിരിക്കുന്നു, അതിനാൽ സർട്ടിഫിക്കറ്റ് പിന്നീട് മാറ്റിയ പാക്കേജ് പഴയ പകർപ്പ് കൊണ്ടുനടക്കുന്ന ക്ലയന്റിനെ നിരസിക്കും.

വാഹനം വ്യക്തമായി പരിശോധിക്കേണ്ട മറ്റൊരു പൊരുത്തക്കേടാണ്, കാരണം പ്രൊഫൈലും പാക്കേജും വ്യത്യസ്ത സ്ഥലങ്ങളിൽ തിരുത്തുന്നു. പാക്കേജ് മാറ്റാതെ പ്രൊഫൈൽ UDP-ൽ നിന്ന് TCP-ലേക്ക് മാറ്റിയാൽ ക്ലയന്റ് നിലവിലില്ലാത്ത ശ്രോതാവിനായി കാത്തിരിക്കും, മറ്റെല്ലാത്തിനും ക്ലയന്റ് പറയുന്ന അതേ പൊതുവായ ഹാൻഡ്‌ഷേക്ക് വാചകം തന്നെ പറയും. ഫയലിലെ proto വരി വായിക്കുക, പിന്നീട് സെർവർ പേജിൽ തിരഞ്ഞെടുത്ത പ്രോട്ടോക്കോൾ നോക്കുക, അതിനുശേഷം മാത്രം അവ യോജിക്കുന്നു എന്ന് തീരുമാനിക്കുക. DSM ഫയർവാൾ നിയമങ്ങൾ വായിക്കുന്നത് മൂന്നാമത്തെ പരിശോധനയാണ്: പ്രാദേശിക സബ്നെറ്റിൽ നിന്ന് പോർട്ട് അനുവദിച്ച് ഇന്റർനെറ്റിൽ നിന്ന് അനുവദിക്കാത്ത നിയമം പരിശോധനയ്ക്ക് ശേഷം വിട്ടേക്കാൻ എളുപ്പമാണ്, അത് അടുക്കളയിൽ നിന്ന് പ്രവർത്തിക്കുകയും മറ്റെല്ലായിടത്തുനിന്നും പരാജയപ്പെടുകയും ചെയ്യുന്ന ബന്ധം സൃഷ്ടിക്കുന്നു.

വിദൂര ഉപയോക്താവ് യഥാർത്ഥത്തിൽ പോകുന്ന പാത പരീക്ഷിക്കുക

അതേ LAN-നുള്ളിലെ ക്ലയന്റ് ഫോർവേഡ് തൊടാതെ തന്നെ NAS-ൽ എത്താം, അതിനാൽ അത് വിദൂര പ്രവേശനത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. Wi-Fi ഓഫ് ചെയ്ത ഫോൺ ഉപയോഗിക്കുക, അല്ലെങ്കിൽ നെറ്റ്വർക്കിന് പുറത്തുള്ള ഒരാളോട് ചോദിക്കുക, ആ ശ്രമത്തിനിടയിൽ റൗട്ടർ കൗണ്ടർ നിരീക്ഷിക്കുക. വിദൂര ശ്രമം പരാജയപ്പെടുകയും പ്രാദേശികമായത് വിജയിക്കുകയും ചെയ്താൽ, ഫോർവേഡോ ഫയർവാളോ ഇപ്പോഴും ചിത്രത്തിലുണ്ട്.

പ്രവർത്തിക്കുന്ന സ്ഥിതി പ്രവർത്തിക്കുന്ന സമയത്ത് രേഖപ്പെടുത്തുക: ബാഹ്യ പോർട്ട്, ആന്തരിക വിലാസം, പ്രോട്ടോക്കോൾ, പാക്കേജ് ഇന്റർഫേസ്, കൂടാതെ പ്രൊഫൈലിന്റെ പേരും കയറ്റുമതി തീയതിയും. ഹാൻഡ്‌ഷേക്ക് വീണ്ടും പരാജയപ്പെടുമ്പോൾ, ആ കുറിപ്പും നിലവിലെ കോൺഫിഗറേഷനും തമ്മിലുള്ള വ്യത്യാസമാണ് തകരാർ, സേവനം രണ്ട് പോർട്ടുകളിൽ ഏതാണ് ഉപയോഗിക്കുന്നതെന്ന് ആരും വീണ്ടും കണ്ടെത്തേണ്ടതില്ല.