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

ആദ്യം കൊല്ലേണ്ട മിത്ത് ഇതാണ്: പ്രവർത്തിക്കുന്ന ടണൽ അകത്തേക്ക് തിരികെയുള്ള വഴിയല്ല. അത് സ്വന്തം വിശ്വാസ ചോദ്യങ്ങളുള്ള പുതിയ നെറ്റ്വർക്ക് ബന്ധമാണ്, ആരും പരിശോധിക്കാത്ത പുതിയ പാത തുറക്കുമ്പോൾ പഴയ മാനേജ്മെന്റ് പാത നിശബ്ദമായി നീക്കം ചെയ്യാനും കഴിയും.

ടണൽ ഒരിക്കലും മാനേജ്മെന്റ് പാത ആയിരുന്നില്ല

ഫോർവേഡിംഗും ഇൻപുട്ടും വ്യത്യസ്ത ജോലികളാണ്. "ക്ലയന്റിന് ടണലിലൂടെ NAS-ൽ എത്താമോ?" എന്നത് റൗട്ടറിലൂടെ കടന്നുപോകുന്ന പാക്കറ്റുകളെക്കുറിച്ചുള്ള ഫോർവേഡിംഗ് ചോദ്യമാണ്. "എനിക്ക് റൗട്ടറിന്റെ SSH പോർട്ട് തുറക്കാമോ?" എന്നത് റൗട്ടറിനുതന്നെ അഭിസംബോധന ചെയ്ത പാക്കറ്റുകളെക്കുറിച്ചുള്ള ഇൻപുട്ട് ചോദ്യമാണ്. ഫോർവേഡ് ചെയ്ത ട്രാഫിക്കിനായി എഴുതിയ അനുമതി നിയമം രണ്ടാമത്തെ ചോദ്യത്തിന് ഒന്നും ചെയ്യുന്നില്ല, ട്രാഫിക് മികച്ച രീതിയിൽ വഹിക്കുന്ന ടണലും നിങ്ങളുടെ അഡ്മിൻ സെഷൻ നിരസിക്കുന്നതിന്റെ ഏറ്റവും സാധാരണ കാരണം അതാണ്.

വിപരീത തെറ്റ് ഇന്റർഫേസ് പേര് വിശ്വസിക്കുന്നതാണ്. ടണൽ പിയറിലേക്ക് എൻക്രിപ്റ്റ് ചെയ്യുന്നു, അതിന് പിന്നിലെ ഓരോ സേവനത്തിലേക്കുമല്ല, ഇന്റർഫേസ് ലേബലിലെ VPN എന്ന വാക്ക് ഏത് ഉറവിടങ്ങൾക്ക് ലോഗിൻ അനുമതി നൽകണം എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

ആദ്യ പാളി: റൗട്ടറിന്റെ സ്വന്തം വിലാസത്തിലേക്ക് റൂട്ട് ഉണ്ടോ?

ക്ലയന്റിൽ തുടങ്ങി പാക്കറ്റ് എവിടെ പോകുമെന്ന് കേർണലിനോട് ചോദിക്കുക. Linux-ൽ ip route get 10.6.0.1 തിരഞ്ഞെടുത്ത റൂട്ട്, പുറത്തേക്കുള്ള ഇന്റർഫേസ്, ഉറവിട വിലാസം എന്നിവ പ്രിന്റ് ചെയ്യുന്നു. നിങ്ങളുടെ ദാതാവിന് നേരെയുള്ള ഡിഫോൾട്ട് റൂട്ട് റിപ്പോർട്ട് ചെയ്താൽ, പാക്കറ്റ് ഒരിക്കലും ടണലിൽ പ്രവേശിക്കുന്നില്ല, റൗട്ടറിലെ ഒരു നിയമത്തിനും അതിനെ രക്ഷിക്കാനാവില്ല.

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

നയം ഡീബഗ് ചെയ്യുന്നതിന് മുമ്പ് നിങ്ങൾ എത്താൻ ആഗ്രഹിക്കുന്ന കൃത്യമായ വിലാസം സ്ഥിരീകരിക്കുക. പഴയ DNS റെക്കോർഡോ മാറ്റത്തിന് മുമ്പുള്ള കാഷ് ചെയ്ത അയൽവാസി എൻട്രിയോ റൗട്ടർ ഒരിക്കലും കൈവശം വച്ചിട്ടില്ലാത്ത വിലാസത്തിലേക്ക് നിങ്ങളെ അയക്കുന്നു.

രണ്ടാം പാളി: ഫോർവേഡിംഗ് നയമല്ല, ഇൻപുട്ട് നയം

ഫയർവാളുകൾ പാക്കറ്റ് എത്തുന്ന ഇന്റർഫേസിൽ നിയമങ്ങൾ വിലയിരുത്തുന്നു. pfSense-ലും OPNsense-ലും ഇന്റർഫേസ് ടാബും നിയമങ്ങളുടെ ക്രമവും ഫയർവാളിന്റെ സ്വന്തം സേവനങ്ങളിലേക്കുള്ള ട്രാഫിക് അനുവദനീയമാണോ എന്ന് തീരുമാനിക്കുന്നു; LAN ക്ലയന്റുകളെ ഇന്റർനെറ്റിലേക്ക് പുറത്തുവിടുന്ന നിയമം ടണൽ പിയറിന് വെബ് GUI തുറക്കാൻ അനുവദിക്കുന്ന നിയമമല്ല. firewall4 ഉള്ള OpenWrt-ൽ ഓരോ സോണും ഒരു ഇൻപുട്ട് നയം വഹിക്കുന്നു, option input 'ACCEPT' അല്ലെങ്കിൽ 'REJECT', ഇൻപുട്ട് REJECT ഉള്ള സോണിലെ ടണൽ ഇന്റർഫേസ് മാനേജ്മെന്റ് കണക്ഷനുകൾ നിരസിക്കും, എന്നാൽ ഫോർവേഡിംഗ് അനുവദിച്ചാൽ ട്രാഫിക് ഇപ്പോഴും ഫോർവേഡ് ചെയ്യും.

പുതിയ പാത പ്രവർത്തിക്കാൻ ആന്റി-ലോക്ക്ഔട്ട് നിയമം പ്രവർത്തനരഹിതമാക്കരുത്. ആ നിയമം മോശം നിയമത്തിന് LAN മാനേജ്മെന്റ് വിലാസം ലോക്ക് ചെയ്യുന്നത് തടയുന്നു; അത് LAN സബ്നെറ്റ് സംരക്ഷിക്കുന്നു, നിങ്ങൾ ഇപ്പോൾ സൃഷ്ടിച്ച ടണൽ സബ്നെറ്റ് അല്ല. അഡ്മിനിസ്ട്രേറ്ററുടെ ഉറവിടത്തിനായി ഒരു ഇടുങ്ങിയ നിയമം ചേർത്ത് സുരക്ഷാ വല വെറുതെ വിടുക. pfSense-ന്റെ അഡ്മിൻ ആക്സസ് ഡോക്യുമെന്റേഷൻ ആ നിയന്ത്രണങ്ങൾ എവിടെയാണെന്ന് വിശദീകരിക്കുന്നു.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

മൂന്നാം പാളി: ആ വിലാസത്തിൽ എന്തെങ്കിലും ശ്രവിക്കുന്നുണ്ടോ?

ഒരു സേവനം പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും ഒരു വിലാസത്തിൽ മാത്രം ബന്ധിച്ചിരിക്കുന്നതിനാൽ എത്താനാകാതെയിരിക്കാം. OpenWrt-ന്റെ uhttpd /etc/config/uhttpd-ൽ വ്യക്തമായ ശ്രവണ എൻട്രികൾ സൂക്ഷിക്കുന്നു, ഉദാഹരണത്തിന് list listen_http '0.0.0.0:80'; LAN വിലാസത്തിൽ മാത്രം ബന്ധിക്കുന്ന ബിൽഡ് ടണൽ വിലാസത്തിൽ ഒന്നും സ്വീകരിക്കുന്നില്ല, ശ്രവണ ഇന്റർഫേസ് ക്രമീകരണം കാണിക്കുന്ന ഉൽപ്പന്നങ്ങളും അതുപോലെ പെരുമാറുന്നു. മുകളിലെ ശ്രവണ കമാൻഡുകൾ ഇതിന് നേരിട്ട് ഉത്തരം നൽകുന്നു.

പിന്നീട് നിരസിക്കലിനെ നിശബ്ദതയിൽ നിന്ന് വേർതിരിക്കുക. nc -vz 10.6.0.1 443 നിരസിച്ച കണക്ഷൻ തിരികെ നൽകിയാൽ പാക്കറ്റ് റൗട്ടറിൽ എത്തി എന്തോ അതിനെ നിരസിച്ചു, അടച്ച പോർട്ടോ വ്യക്തമായ നിരസിക്കൽ നിയമമോ. ടൈംഔട്ട് വരെ തൂങ്ങിക്കിടക്കുന്നത് പാക്കറ്റ് ഉപേക്ഷിക്കപ്പെട്ടു അല്ലെങ്കിൽ ഒരിക്കലും റൂട്ട് ചെയ്യപ്പെട്ടില്ല എന്നാണ്. ഈ വ്യത്യാസം അടുത്തതായി ഏത് പാളി പരിശോധിക്കണം എന്ന് പറയുന്നു, അതിന് അഞ്ച് സെക്കൻഡ് മതി.

VPN ഇന്റർഫേസ് ഒരു അതിർത്തിയാണ്, വീണ്ടെടുപ്പ് പാതയല്ല

എൻക്രിപ്ഷൻ വയർ സംരക്ഷിക്കുന്നു; അഡ്മിൻ പേജ് ആർക്ക് തുറക്കാം എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല. ടണൽ പ്രവർത്തിച്ചുതുടങ്ങിയാൽ, ടണൽ ഇന്റർഫേസിൽ എല്ലാം അനുവദിച്ച് എത്തിച്ചേരൽ പരിഹരിക്കാനുള്ള പ്രേരണയെ ചെറുക്കുക. അഡ്മിനിസ്ട്രേറ്റർമാർക്ക് അവരുടെ സ്വന്തം ടണൽ വിലാസത്തിൽ ബന്ധിച്ച നിയമമോ പ്രത്യേക അഡ്മിൻ-മാത്രം ടണലോ നൽകുക, സാധാരണ ഉപയോക്താക്കൾ, NAS, ക്യാമറകൾ, കുടുംബ ലാപ്ടോപ്പുകൾ എന്നിവയെ മാനേജ്മെന്റ് പോർട്ടിൽ നിന്ന് അകറ്റി നിർത്തുക. ഫയൽ പങ്കിടൽ ആവശ്യമുള്ള പിയർ റൗട്ടർ ലോഗിനിൽ നിന്ന് ഒരു നിയമം അകലെയായിരിക്കരുത്.

റൗട്ടറിന്റെ പങ്ക് ഉത്തരം മാറ്റുന്നു. ടണൽ അവസാനിപ്പിക്കുന്ന റൗട്ടറിന് അതിൽ നിന്ന് അഡ്മിനിസ്ട്രേറ്റർമാരെ നിയമപരമായി സ്വീകരിക്കാം, എന്നാൽ ടണൽ ഇന്റർനെറ്റ് എക്സിറ്റായി മാത്രം ഉപയോഗിക്കുന്ന റൗട്ടർ സാധാരണയായി അങ്ങനെ ചെയ്യരുത്. രണ്ട് സന്ദർഭങ്ങളിലും സബ്നെറ്റ് അനുമതി ലോഗിൻ അല്ല, അതിനാൽ അക്കൗണ്ട് പ്രാമാണീകരണവും ഗതാഗത സുരക്ഷയും ഓൺ ആക്കി വയ്ക്കുക.

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

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

നയം തൊടുന്നതിന് മുമ്പ് തിരികെയുള്ള വഴി തയ്യാറാക്കുക

ആദ്യ മാറ്റത്തിന് മുമ്പ് നാല് കാര്യങ്ങൾ എഴുതുക: ടണൽ മരിച്ചാൽ നിങ്ങൾ ഉപകരണത്തിൽ എങ്ങനെ എത്തും, ഉദാഹരണത്തിന് സീരിയൽ കൺസോൾ, ദാതാവിന്റെ കൺസോൾ അല്ലെങ്കിൽ LAN-ലെ ഒരു മെഷീൻ; നിലവിലെ കോൺഫിഗറേഷൻ എവിടേക്ക് കയറ്റുമതി ചെയ്യുന്നു; ഏത് ഒരു നിയമമോ റൂട്ടോ നിങ്ങൾ മാറ്റാൻ പോകുന്നു; ആ ഇനം കൃത്യമായി എങ്ങനെ തിരികെ കൊണ്ടുവരും. OpenWrt-ൽ sysupgrade -b /tmp/backup.tar.gz കോൺഫിഗറേഷൻ പിടിച്ചെടുക്കുന്നു, എഡിറ്റുകൾ uci commit വരെ കാത്തിരിക്കുന്നു, സമയത്ത് ശ്രദ്ധിച്ചാൽ അത് വിലകുറഞ്ഞ പഴയപടിയാക്കൽ നൽകുന്നു. pfSense കോൺഫിഗറേഷൻ ചരിത്രം സൂക്ഷിക്കുന്നു, AutoConfigBackup മുമ്പേ പ്രവർത്തനക്ഷമമായിരുന്നെങ്കിൽ മാത്രം സഹായിക്കുന്നു. റൗട്ടർ fail-closed നിയമക്കൂട്ടം പ്രവർത്തിപ്പിക്കുന്നുവെങ്കിൽ, നിങ്ങൾ ആസൂത്രണം ചെയ്ത അറ്റകുറ്റപ്പണി പാത ആ നിയമം തടയുന്ന ട്രാഫിക്കിനുള്ളിൽ അല്ലെന്ന് ഉറപ്പാക്കുക, റീബൂട്ട് സ്ഥിര നിയമങ്ങൾ മായ്ക്കുന്നതിന് പകരം വീണ്ടും പ്രയോഗിക്കുന്നു എന്ന് ഓർക്കുക.

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

പുറപ്പെടുന്നതിന് മുമ്പുള്ള പെട്ടെന്നുള്ള പരിശോധന:

  • നിങ്ങൾ ഇപ്പോൾ തിരുത്തിയ നിയമത്തെ ആശ്രയിക്കാത്ത ഒരു ഉറവിടത്തിൽ നിന്ന് റൗട്ടറിൽ എത്താമോ?
  • ടണൽ ഇന്റർഫേസിലെ ഇൻപുട്ട് നയം അഡ്മിനിസ്ട്രേറ്ററുടെ ഉറവിടത്തിന് മാത്രം അനുമതി നൽകുന്നുണ്ടോ?
  • മാനേജ്മെന്റ് സേവനം ടണലിൽ നിലവിലുള്ള ഒരു വിലാസത്തിൽ ബന്ധിച്ചിട്ടുണ്ടോ?
  • നിരസിക്കപ്പെട്ട ഒരു പിയറും ഒരു പുതിയ സെഷനും പരിശോധിച്ചിട്ടുണ്ടോ?
  • WAN മാനേജ്മെന്റ് ഉപരിതലം ഇപ്പോഴും അടച്ചിരിക്കുന്നുവോ?

അനുബന്ധ ലേഖനങ്ങൾ