OpenVPN വഴി LAN ആക്സസ് തകർന്നോ? സോണുകൾ, റൂട്ടുകൾ, മടക്കവഴി പരിശോധിക്കുക

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

LAN ലേക്ക് പോകുന്ന പാക്കറ്റ് ഏത് ഫിൽട്ടർ കാണുന്നു

റൗട്ടറിലേക്ക് വിലാസമിട്ട പാക്കറ്റ് പ്രാദേശികമായി ഉപയോഗിക്കപ്പെടുന്നു; അതിനു പിന്നിലെ ഹോസ്റ്റിലേക്ക് വിലാസമിട്ട പാക്കറ്റ് ഫോർവേഡ് ചെയ്യണം, ഫയർവാളുകൾ ഈ രണ്ട് സാഹചര്യങ്ങളെ വെവ്വേറെ വിലയിരുത്തുന്നു. അതിനാൽ റൗട്ടറിൽ എത്താനുള്ള അനുമതി അത് കടക്കാനുള്ള അനുമതിയെപ്പറ്റി ഒന്നും പറയുന്നില്ല. സ്വന്തം നിയമക്കൂട്ടങ്ങൾ മറയ്ക്കുന്ന ഫേംവെയർ രണ്ടും നടപ്പാക്കുന്നു, സാധാരണയായി LAN, ഇന്റർനെറ്റ് അല്ലെങ്കിൽ രണ്ടും വാഗ്ദാനം ചെയ്യുന്ന തിരഞ്ഞെടുക്കലായി. തിരഞ്ഞെടുക്കൽ LAN ഒഴിവാക്കിയാൽ പിന്നീടുള്ള ഏത് പരിശോധനയും പ്രസക്തമല്ല.

OpenWrt ഈ വിഭജനം പരിശോധിക്കാവുന്നതാക്കുന്നു, വ്യത്യാസം ഒരിക്കൽ വായിക്കാൻ യോഗ്യമാണ്. ടണൽ അവസാനിപ്പിക്കുന്ന സോണിന് LAN സോണിലേക്ക് ചൂണ്ടുന്ന ഫോർവേഡ് നിയമം വേണം, അതേസമയം ഇൻപുട്ട് നിയമം റൗട്ടറിലെ സേവനങ്ങളെ മാത്രം നിയന്ത്രിക്കുന്നു. പ്രവർത്തിക്കുന്ന അഡ്മിൻ പേജിനൊപ്പം മരിച്ച LAN ഉണ്ടാകുന്നത് ആ കാണാത്ത ഫോർവേഡ് നിയമത്തിന്റെ സാധാരണ ഫലമാണ്.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

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

വിഭജിത ടണലിന് പുഷ് ചെയ്ത പ്രിഫിക്സ് എന്തിന് വേണം

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

push "route 192.168.50.0 255.255.255.0"

ഉൾക്കൊള്ളുന്ന പ്രൊഫൈലുകൾ route-nopull പുഷ് ചെയ്ത റൂട്ടുകൾ അവഗണിക്കുന്നു, അതിനാൽ അതേ പ്രിഫിക്സ് ക്ലയന്റ് ഫയലിൽ ആയിരിക്കണം. ഏതായാലും എൻട്രി എത്തിയെന്ന് ഉറപ്പാക്കുക, അനുമാനിക്കരുത്, കാരണം നിശബ്ദമായ മാറ്റിസ്ഥാപിക്കൽ ഫയർവാൾ പ്രശ്നത്തിന് തുല്യമായി കാണപ്പെടുന്നു.

ip route show | grep 192.168.50

സൈറ്റ്-ടു-സൈറ്റ് പങ്കാളി പുഷ് ചെയ്യുന്നതിലും കൂടുതൽ ആവശ്യപ്പെടുന്നു. ആ പങ്കാളിക്ക് പിന്നിൽ ഏത് പ്രിഫിക്സുകൾ ഉണ്ടെന്ന് സെർവർ പഠിക്കണം, അത് അതിന്റെ client-config-dir ഫയലിലെ iroute വരി ചെയ്യുന്നു, അതിന്റെ സ്വന്തം പട്ടികയ്ക്ക് ടണലിലേക്ക് ചേരുന്ന റൂട്ടും വേണം.

മറുപടിക്ക് എത്താവുന്ന ഒരു വിലാസം വേണം

അഭ്യർത്ഥന ഫോർവേഡ് ചെയ്യുന്നത് കൈമാറ്റത്തിന്റെ പകുതി മാത്രമാണ്, കാരണം LAN ഹോസ്റ്റ് ടണൽ പൂളിലെ വിലാസത്തിന് മറുപടി നൽകണം. ചെറിയ റൗട്ടറുകൾ സാധാരണയായി അത് ടണൽ സോണിൽ ഉറവിടം വിവർത്തനം ചെയ്ത് ക്രമീകരിക്കുന്നു, അതിനാൽ മറുപടി റൗട്ടറിലേക്ക് വിലാസമിടപ്പെടുന്നു, മറ്റെവിടെയും കോൺഫിഗറേഷൻ വേണ്ട. ആ വിവർത്തനം നീക്കിയാൽ ഹോസ്റ്റിന് പൂളിലേക്ക് സ്വന്തം റൂട്ട് വേണം, റൗട്ടർ അതിന്റെ ഡിഫോൾട്ട് ഗേറ്റ്വേ ആകുമ്പോൾ അത് സൗജന്യമായി ലഭിക്കുന്നു. കൈകൊണ്ട് സജ്ജീകരിച്ച വിലാസവും മറ്റൊരു ഗേറ്റ്വേയും ഉള്ള ഹോസ്റ്റ് ആ ഗേറ്റ്വേ വഴി മറുപടി നൽകുന്നു, ക്ലയന്റ് സെഷൻ തുറന്ന് പിന്നീട് തടഞ്ഞുനിൽക്കുന്നത് കാണുന്നു.

tcpdump -ni tun0 host 192.168.50.20

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

ശരിയായ സ്ഥലത്ത് അവസാനിക്കുന്ന ഗോവണി

നാല് പരിശോധനകൾ പാളി കണ്ടെത്തുന്നു, ഓരോന്നും വിധിയല്ല, ഒരു കമാൻഡ് മാത്രം. അവ ക്രമത്തിൽ പ്രവർത്തിപ്പിച്ച് ആദ്യ പരാജയത്തിൽ നിർത്തുക. ക്രമം കമാൻഡുകളെക്കാൾ പ്രധാനമാണ്, കാരണം പിന്നീടുള്ള ഘട്ടം കടക്കുമ്പോൾ മുൻപത്തേത് എന്തുകൊണ്ട് പരാജയപ്പെട്ടു എന്ന കാരണം മറയുന്നു.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

പേരുകൾ ഗോവണിയുടെ അവസാനത്തിലാണ്, ഒരിക്കലും തുടക്കത്തിലല്ല. 192.168.50.20 ആയി മറുപടി നൽകുകയും nas.local ആയി നൽകാതിരിക്കുകയും ചെയ്യുന്ന പങ്കിടൽ പേര് നിർണ്ണയത്തിലേക്കോ തിരച്ചിൽ പ്രത്യയത്തിലേക്കോ വിരൽ ചൂണ്ടുന്നു, ഫയർവാൾ എഡിറ്റുകൾക്ക് ഇവയൊന്നും മാറ്റാൻ കഴിയില്ല.

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