നിങ്ങളുടെ LAN-ന് ഒരു VPN ക്ലൈന്റിലെ സേവനത്തിലേക്ക് എത്താൻ കഴിയാത്തത് എന്തുകൊണ്ട്

നിങ്ങളുടെ ടണൽ ഉയർന്നിരിക്കുന്നു, സേവനം കേൾക്കുന്നു, എന്നിട്ടും ഓഫീസ് LAN-ന് തിരികെ ഒന്നും ലഭിക്കുന്നില്ല. ആരും VPN തകർത്തിട്ടില്ല. LAN-ന്റെ വശത്തുനിന്ന്, എങ്ങനെ എത്തിച്ചേരണം എന്ന് എന്തെങ്കിലും LAN-നോട് പറയുന്നതുവരെ ലാപ്ടോപ്പിന്റെ ടണൽ വിലാസം നിലവിലില്ല, കൂടാതെ അഭ്യർത്ഥന പുറത്തുപോയ അതേ വഴിയിലൂടെ മറുപടി തിരികെ വരണം. ആരും തിരിച്ചുവരുന്ന പാത നോക്കുന്നതിന് മുമ്പ് തികച്ചും ആരോഗ്യകരമായ ഒരു ടണൽ മൂന്ന് തവണ വീണ്ടും നിർമ്മിക്കുന്നത് ഞാൻ കണ്ടിട്ടുണ്ട്.

തകർന്നത് ടണൽ അല്ല

രണ്ടറ്റവും സ്വകാര്യ ശ്രേണികളിലാണ് ഇരിക്കുന്നത്, അത് സാധാരണ സാഹചര്യമാണ്, തെറ്റായ കോൺഫിഗറേഷനല്ല. 10.8.0.6 പോലുള്ള ഒരു വിലാസം ടണലിനുള്ളിൽ യഥാർത്ഥമാണ്, മറ്റെവിടെയും നിലവിലില്ല, അതിനാൽ അങ്ങോട്ട് എന്തെങ്കിലും അയക്കാൻ LAN-ന് കാരണമില്ല. റൂട്ടിംഗ് തൊടുന്നതിന് മുമ്പ് സേവനം ടണലിനുള്ളിൽ എങ്ങനെയെങ്കിലും ലഭ്യമാണോ എന്ന് സ്ഥിരീകരിക്കുക: ക്ലൈന്റിൽ ss -ltn, ലിസണർ 127.0.0.1, LAN ഇന്റർഫേസ് അല്ലെങ്കിൽ ടണൽ വിലാസത്തിലേക്ക് ബന്ധിപ്പിച്ചിട്ടുണ്ടോ എന്ന് കാണിക്കുന്നു. loopback-ലേക്ക് മാത്രം ബന്ധിപ്പിച്ച ഡീമോൺ സ്വയം ഒഴികെ ആർക്കും മറുപടി നൽകുന്നില്ല, ഏതെങ്കിലും റൂട്ടോ DNAT-ഓ പോർട്ട് ഫോർവേഡിംഗോ അത് മാറ്റുന്നില്ല.

പോർട്ട് 80 അല്ലെങ്കിൽ 443-ലെ പ്രോക്സി വേറെ കാഴ്ചയുള്ള മറ്റൊരു ഉപകരണമാണ്. ഇത് പാക്കറ്റുകളല്ല, അഭ്യർത്ഥനകളാണ് നീക്കുന്നത്, അതിനാൽ അസംസ്കൃത ഡാറ്റാബേസ് കണക്ഷന് ഇത് തെറ്റായ പാളിയാണ്, ആരും എന്തെങ്കിലും അളക്കുന്നതിന് മുമ്പ് ഈ പ്രശ്നം മൂന്ന് ഉപകരണങ്ങൾ ആഴത്തിൽ എത്തുന്നത് അതിലേക്ക് കൈ നീട്ടുന്നതിലൂടെയാണ്.

റൂട്ടിന്റെ രൂപം: കുളം എവിടെയാണെന്ന് LAN-നോട് പറയുക

LAN-ഉം ടണൽ കുളവും ഒന്നിനുമേൽ ഒന്ന് വരാത്തപ്പോൾ ഏറ്റവും വ്യക്തമായ മറുപടി LAN ഗേറ്റ്വേയിലെ സ്റ്റാറ്റിക് റൂട്ടാണ്. കുളത്തെ ടണൽ അവസാനിപ്പിക്കുന്ന യന്ത്രത്തിലേക്ക് തിരിച്ചുവിടുക:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

അത് ഒരു ദിശ മാത്രം ശരിയാക്കുന്നു, അതുകൊണ്ടാണ് ഈ മാറ്റത്തിന്റെ പകുതി പൂർത്തിയായ പതിപ്പുകൾ പുരോഗതിയായി തോന്നുന്നത്. ടണലിന്റെ വശത്തിനും ചേരുന്ന പകുതി വേണം, അല്ലെങ്കിൽ മറുപടി ക്ലൈന്റിനെ അതിന്റെ സ്വന്തം ഡിഫോൾട്ട് റൂട്ടിലൂടെ വിട്ട് വഴിയിൽ മരിക്കുന്നു:

push "route 192.168.1.0 255.255.255.0"

സെർവറിന് പിന്നിലല്ല, ഒരു ക്ലൈന്റിന് പിന്നിൽ ഉള്ള ഒരു സബ്നെറ്റിന്, സെർവറിന് സിസ്റ്റം റൂട്ടും, ആ ക്ലൈന്റിന്റെ ഫയലിൽ iroute എൻട്രിയും (client-config-dir-ന് കീഴിൽ) വേണം. iroute ഇല്ലാതെ, OpenVPN-ന് പ്രിഫിക്സ് ഉണ്ടെന്ന് അറിയാം, ഏത് ക്ലൈന്റാണ് അതിന്റെ ഉടമ എന്ന് അറിയില്ല: പാക്കറ്റുകൾ വരുന്നു, ഡീമോണിന് അവ ചേർത്തുവയ്ക്കാൻ ഒന്നുമില്ല.

ഇവിടെ പേര് നൽകാൻ അർഹതയുള്ള ഐതിഹ്യമുണ്ട്. ഒരു റൂട്ട് വിലാസത്തെ എത്താവുന്നതാക്കുന്നു; അത് എതിർവശത്തെ മറുപടി നൽകാൻ തയ്യാറാക്കുന്നില്ല. സൈറ്റ്-ടു-സൈറ്റ് പങ്കാളികൾ മുകളിൽ മറ്റൊരു പാളി ചേർക്കുന്നു, കാരണം ദൂരെയുള്ള ഗേറ്റ്വേ തന്റെ നയത്തിൽ പട്ടികപ്പെടുത്തിയ പ്രിഫിക്സുകൾക്കുള്ളിലെ ഉറവിടങ്ങൾ മാത്രമേ സ്വീകരിക്കുന്നുള്ളൂ, വീട്ടിലെ കുളത്തിൽ നിന്ന് വരുന്ന ലാപ്ടോപ്പ് അവയ്ക്കുള്ളിലില്ല.

NAT-ന്റെ രൂപം: അകത്തേക്ക് DNAT, എല്ലാവരും ഒഴിവാക്കുന്ന SNAT വരി

LAN ഗേറ്റ്വേ തൊടാൻ കഴിയാത്തപ്പോൾ, അല്ലെങ്കിൽ കൃത്യമായി ഒരു പോർട്ട് പ്രസിദ്ധീകരിക്കാൻ ആഗ്രഹിക്കുമ്പോൾ, VPN ഹോസ്റ്റിലെ വിവർത്തനം LAN-ൽ ഒരു റൂട്ടും ഇല്ലാതെ പ്രവർത്തിക്കുന്നു. പോർട്ട് പ്രസിദ്ധീകരിക്കുക, ഫോർവേഡ് ചെയ്യുക, ടണലിലേക്കുള്ള വഴിയിൽ ഉറവിടം വിവർത്തനം ചെയ്യുക:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

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

ഉപഭോക്തൃ ഫേംവെയർ സ്വന്തം ചെയിൻ നാമങ്ങൾ ഉപയോഗിക്കുന്നു, ആ വിവർത്തനം നിങ്ങൾക്കായി സൃഷ്ടിക്കുന്നില്ല. Tomato-യിൽ ഇൻബൗണ്ട് നിയമം WANPREROUTING-ലേക്ക് വീഴുന്നു, പിന്നീട് wanin പോലുള്ള ഫിൽട്ടർ ചെയിനിലേക്ക്, പൂർണ്ണമായി തോന്നുന്ന ഒരു നിയമക്കൂട്ടത്തിനും ഇപ്പോഴും കൈയിൽ എഴുതിയ POSTROUTING വരി വേണം. അത് ഫേംവെയർ ബഗ് അല്ല; ഇൻബൗണ്ട് ട്രാഫിക്കിന് മാത്രമായി എഴുതിയ ഒരു നിയമക്കൂട്ടമാണ്.

ശരിയായി തോന്നുന്ന നിയമം പാക്കറ്റ് ഇപ്പോഴും വീഴ്ത്തുന്നത് എന്തുകൊണ്ട്

ഈ പരാജയങ്ങളിൽ ഭൂരിഭാഗവും നിങ്ങൾ നോക്കുന്ന നിയമത്തിലല്ല. ഈ ക്രമത്തിൽ നാല് കാര്യങ്ങൾ പരിശോധിക്കുക, ശരിയാകാത്ത ആദ്യത്തേതിൽ നിർത്തുക:

• ചെയിൻ ക്രമം. iptables -I മുകളിൽ ചേർക്കുന്നു, -A അവസാനത്തിൽ ചേർക്കുന്നു, അതിനാൽ മുൻപത്തെ അനുവദിക്കുന്നതോ തടയുന്നതോ ആയ നിയമമാണ് ആദ്യം തീരുമാനിക്കുന്നത്.
• തെറ്റായ ചെയിൻ. റൂട്ടറിലേക്ക് തന്നെ അഭിസംബോധന ചെയ്ത ട്രാഫിക് INPUT കടക്കുന്നു, ഫോർവേഡ് ചെയ്യുന്ന ട്രാഫിക് അത് ഒരിക്കലും തൊടുന്നില്ല. ഒരു സേവനം പ്രസിദ്ധീകരിക്കാൻ രണ്ടിലും നിയമങ്ങൾ വേണ്ടിവരാം.
• ദിശാ ഫ്ലാഗുകൾ. -i tun0 ക്ലൈന്റുകളിൽ നിന്ന് വരുന്ന ട്രാഫിക്കിനോട് ചേരുന്നു, -o tun0 അവരിലേക്ക് പോകുന്ന ട്രാഫിക്കിനോട്. തെറ്റായ ഫ്ലാഗുള്ള REJECT നിങ്ങൾ ഉദ്ദേശിക്കാത്ത എന്തെങ്കിലും തടയുന്നു.
• ഉറവിട നിയന്ത്രണം. ഒരു ക്ലൈന്റ് വിലാസം സ്വീകരിക്കുന്ന ഫോർവേഡിംഗ് ആ ക്ലൈന്റിൽ നിന്ന് പ്രവർത്തിക്കുന്നു, മറ്റേതെങ്കിലും ഉറവിടത്തെ ഒരു വാക്കുപോലും പറയാതെ വീഴ്ത്തുന്നു.

പൂജ്യം പാക്കറ്റ് കൗണ്ടറുള്ള ഒരു നിയമം പാതയിൽ തന്നെയില്ല, കൗണ്ടറുകൾ വായിക്കുന്നതാണ് തെറ്റായ ചെയിന്റെ പ്രശ്നത്തെ തെറ്റായ നിയമത്തിന്റെ പ്രശ്നത്തിൽ നിന്ന് വേർതിരിക്കാനുള്ള വേഗതയേറിയ വഴി.

LAN-ൽ ഒന്നും മാറ്റാൻ കഴിയാത്തപ്പോൾ ലോക്കൽ ഫോർവേഡിംഗ്

SSH ലോക്കൽ ഫോർവേഡിംഗ് മുഴുവൻ ചോദ്യവും ഒഴിവാക്കുന്നു. അതിന് LAN-ൽ റൂട്ടോ, ക്ലൈന്റിന്റെ ഫയർവാളിന്റെ സഹകരണമോ, എവിടെയെങ്കിലും പ്രസിദ്ധീകരിച്ച ഒരു പോർട്ടോ ആവശ്യമില്ല:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

പിന്നീട് ടണൽ കൈവശം വയ്ക്കുന്ന യന്ത്രത്തിന്റെ localhost:3000-ൽ സേവനം പ്രത്യക്ഷപ്പെടുന്നു, മറ്റെവിടെയും ഇല്ല. അതാണ് അതിർത്തി: ഒരു വർക്ക്സ്റ്റേഷൻ, ഒരു പോർട്ട്, എന്തെങ്കിലും അത് പുനരാരംഭിക്കാത്തപക്ഷം സെഷനോടൊപ്പം ഫോർവേഡിംഗ് മരിക്കുന്നു. സ്റ്റേജിംഗ് ഡാറ്റാബേസ് പരിശോധിക്കുന്ന അഡ്മിനിന് ഇത് ശരിയായ ഉപകരണമാണ്. മറ്റ് ആളുകൾ എത്തിച്ചേരേണ്ട ക്യാമറയ്ക്കോ സ്കാനറിനോ അല്ല, കാരണം ഓരോ ഉപയോക്താവിനും സ്വന്തം ഫോർവേഡിംഗ് വേണ്ടിവരും.

ഇനിയൊരു നിയമം ചേർക്കുന്നതിന് മുമ്പ് രണ്ട് ദിശകളും പരിശോധിക്കുക

വിവർത്തനം അടയാളങ്ങൾ അവശേഷിപ്പിക്കുന്നു, അവ വായിക്കുന്നത് ഊഹിക്കുന്നതിനേക്കാൾ നല്ലതാണ്. VPN ഹോസ്റ്റിൽ, conntrack -L വിവർത്തനം ഉണ്ടായോ എന്ന് കാണിക്കുന്നു, iptables -t nat -L -n -v കൗണ്ടറുകൾ നീങ്ങിയോ എന്ന് കാണിക്കുന്നു, tcpdump -ni any port 3000 ഏത് ഉറവിട വിലാസമാണ് യഥാർത്ഥത്തിൽ വന്നത് എന്ന് കാണിക്കുന്നു. ക്ലൈന്റിൽ, ss -ltn ലിസണർ ടണലിന് എത്താൻ കഴിയുന്ന വിലാസത്തിലാണെന്ന് സ്ഥിരീകരിക്കുന്നു.

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