OpenVPN ക്ലൈന്റ് സെർവറിൽ എത്തുന്നു, പക്ഷേ LAN ഹോസ്റ്റുകളിൽ എത്തുന്നില്ല: ചെക്ക് ലിസ്റ്റ്

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

ആദ്യ ഘട്ടം: ക്ലൈന്റിന്റെ റൂട്ടിംഗ് തീരുമാനം നിരീക്ഷിക്കുക

സെർവറിൽ തൊടുന്നതിന് മുമ്പ്, ക്ലൈന്റ് പാക്കറ്റ് ടണലിലേക്ക് അയക്കുന്നു എന്ന് തെളിയിക്കുക. മുഴുവൻ പട്ടികയും വായിക്കുന്നതിന് പകരം ഒരു നിർദ്ദിഷ്ട LAN ഹോസ്റ്റിനായി കെർണൽ ഏത് ഇന്റർഫേസ് ഉപയോഗിക്കും എന്ന് ചോദിക്കുക:

ip route get 192.168.50.10

ഉത്തരം നിങ്ങളുടെ ഭൗതിക അഡാപ്റ്ററും ഓഫീസ് ഗേറ്റ്വേയും പേരെടുത്ത് പറഞ്ഞാൽ, സെർവർ വശത്തെ ഒരു മാറ്റവും സഹായിക്കില്ല. സെർവർ അവ തള്ളുമ്പോൾ മാത്രമാണ് OpenVPN റൂട്ടുകൾ വിതരണം ചെയ്യുന്നത്, അതിനാൽ സെർവർ കോൺഫിഗറേഷനിൽ push "route 192.168.50.0 255.255.255.0" തിരയുക, പിന്നീട് ക്ലൈന്റ് വീണ്ടും ബന്ധിപ്പിക്കുക. മിക്ക ക്ലൈന്റുകളും തള്ളിയ റൂട്ടുകൾ കണക്ട് ചെയ്യുന്ന സമയത്ത് പ്രയോഗിക്കുന്നു, പ്രൊഫൈൽ വീണ്ടും ലോഡ് ചെയ്യുമ്പോഴല്ല.

Windows-ൽ അതേ ചോദ്യത്തിന് മറ്റൊരു കമാൻഡ് ഉണ്ട്. Find-NetRoute -RemoteIPAddress 192.168.50.10 സ്റ്റാക്ക് തിരഞ്ഞെടുക്കുന്ന ഇന്റർഫേസും അടുത്ത ഹോപ്പും പ്രിന്റ് ചെയ്യുന്നു, route print -4 തള്ളിയ പ്രിഫിക്സ് ഉണ്ടോ ഇല്ലയോ എന്ന് കാണിക്കുന്നു.

രണ്ടാം ഘട്ടം: സെർവർ പാക്കറ്റ് ഫോർവേഡ് ചെയ്യുമെന്ന് ഉറപ്പാക്കുക

ക്ലൈന്റ് റൂട്ട് ശരിയാണെങ്കിൽ, പാക്കറ്റ് സെർവറിൽ എത്തുന്നു, സെർവർ അത് ഫോർവേഡ് ചെയ്യാൻ സമ്മതിക്കണം. കെർണൽ സ്വിച്ചാണ് ആദ്യ ഗേറ്റ്, sysctl net.ipv4.ip_forward 1 തിരികെ നൽകണം. echo 1 > /proc/sys/net/ipv4/ip_forward ഉപയോഗിച്ച് അത് സെറ്റ് ചെയ്യുന്നത് അടുത്ത റീബൂട്ട് വരെ പ്രവർത്തിക്കും, അതുകൊണ്ടാണ് അതേ പരാതി ആഴ്ചകൾക്ക് ശേഷം തിരികെ വരുന്നത്.

റീസ്റ്റാർട്ടിനെ അതിജീവിക്കുന്ന ഒരിടത്ത് അത് എഴുതിവെക്കുക:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

രണ്ടാം ഗേറ്റ് ഫിൽട്ടർ പട്ടികയാണ്. Docker ഇൻസ്റ്റാൾ ചെയ്ത ഹോസ്റ്റിൽ പലപ്പോഴും FORWARD നയം DROP ആണ്, ടണൽ ആ തീരുമാനം പിന്തുടരുന്നു. iptables -L FORWARD -v -n നയവും പാക്കറ്റ് കൗണ്ടറുകളും കാണിക്കുന്നു; നയം DROP ആണെങ്കിൽ, ഫോർവേഡിംഗിന് ടണലിൽ നിന്ന് LAN ദിശയിലേക്ക് ഒരു വ്യക്തമായ അനുമതിയും ഉത്തരത്തിന് മറ്റൊന്നും വേണം.

മൂന്നാം ഘട്ടം: പാക്കറ്റ് LAN വരെ പിന്തുടർന്ന് ഉത്തരം തിരയുക

സെർവറിന്റെ ഇരു വശങ്ങളും ഒരേ സമയം നിരീക്ഷിക്കുക. ടണലിലും LAN ഇന്റർഫേസിലും ക്യാപ്ചർ ചെയ്യുക, ഒരു ക്ലൈന്റിലേക്കും ഒരു ഹോസ്റ്റിലേക്കും ഫിൽട്ടർ ചെയ്ത് ഔട്ട്പുട്ട് വായനാക്ഷമമായി നിലനിർത്തുക:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

tun0-ൽ പ്രത്യക്ഷപ്പെട്ട്, പിന്നെ വീണ്ടും eth0-ൽ 10.8.0.x ഉറവിടത്തോടെ പ്രത്യക്ഷപ്പെട്ട്, തുടർന്ന് നിശ്ശബ്ദതയുണ്ടാകുന്ന അഭ്യർത്ഥനകൾ അർത്ഥമാക്കുന്നത് പാക്കറ്റ് എത്തി, ഉത്തരം മറ്റെവിടെയോ പോയി എന്നാണ്. LAN ഹോസ്റ്റ് അതിന്റെ ഡിഫോൾട്ട് ഗേറ്റ്വേയ്ക്ക് ഉത്തരം നൽകുന്നു, ആ ഗേറ്റ്വേയ്ക്ക് VPN പൂളിന് റൂട്ട് ഇല്ല, ഉത്തരം LAN റൗട്ടറിൽ മരിക്കുന്നു. സെർവറിൽ നിന്ന് LAN ഹോസ്റ്റിന് ping ചെയ്യുന്നത് ഈ വഴിയെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, കാരണം ആ ട്രാഫിക് ഒരിക്കലും ടണൽ കടക്കുന്നില്ല.

നാലാം ഘട്ടം: വിവർത്തനത്തിനും മടക്ക റൂട്ടിനും ഇടയിൽ തിരഞ്ഞെടുക്കുക

രണ്ട് അറ്റകുറ്റപ്പണികൾ ദ്വാരം അടയ്ക്കുന്നു, ping പ്രവർത്തിക്കുന്നുണ്ടോ എന്നതിനപ്പുറം ഈ തിരഞ്ഞെടുപ്പിന് അനന്തരഫലങ്ങളുണ്ട്. സോഴ്സ് വിവർത്തനം സെർവറിനെ കാണുന്ന അയച്ചയാളാക്കുന്നു:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

നിയമം പൂളിലേക്കും LAN ഇന്റർഫേസിലേക്കും പരിമിതപ്പെടുത്തി, പിന്നീട് അത് സ്ഥിരമാക്കുക, അല്ലെങ്കിൽ അടുത്ത ഫയർവാൾ റീലോഡ് നിങ്ങളുടെ അറ്റകുറ്റപ്പണി നിശ്ശബ്ദമായി നീക്കും. വില അടയാളമാണ്: LAN ലോഗുകളിലും ആക്സസ് നിയമങ്ങളിലും ഓരോ ക്ലൈന്റും VPN സെർവറിനെപ്പോലെ കാണപ്പെടുന്നു, per-client policy becomes guesswork.

LAN റൗട്ടറിൽ VPN സെർവറിലേക്ക് ചൂണ്ടുന്ന 10.8.0.0/24-നുള്ള സ്റ്റാറ്റിക് റൂട്ട് ക്ലൈന്റ് വിലാസങ്ങൾ കാണാവുന്നതായി നിലനിർത്തുന്നു, ആ റൗട്ടർ നിങ്ങളുടേതാണെങ്കിൽ ഇതാണ് മികച്ച ദീർഘകാല ഉത്തരം. പല സൈറ്റുകളും കുറച്ച് കാലം രണ്ടും പ്രവർത്തിപ്പിക്കുന്നു, തൽക്ഷണ അറ്റകുറ്റപ്പണിക്ക് NAT, ഫയർവാൾ നയം എഴുതിയ ശേഷം റൂട്ട്. സെർവർ പൂളല്ല, സൈറ്റ്-ടു-സൈറ്റ് പിയർ ആണെങ്കിൽ, സെർവർ വശത്തിനും ദൂരസ്ഥ സബ്നെറ്റിനായി iroute വേണം, അല്ലെങ്കിൽ പിയർ റൂട്ട് നിലവിലുണ്ട്, പക്ഷേ ക്ലൈന്റ് ട്രാഫിക് അതുമായി ഒരിക്കലും ബന്ധിപ്പിക്കപ്പെടുന്നില്ല.

അഞ്ചാം ഘട്ടം: ക്ലൈന്റിൽ നിന്ന് പരിശോധിച്ച് എന്ത് മാറി എന്ന് രേഖപ്പെടുത്തുക

ലൂപ്പ് സെർവറിൽ നിന്നല്ല, ക്ലൈന്റിൽ നിന്ന് അടയ്ക്കുക. LAN ഹോസ്റ്റിലെ യഥാർത്ഥ സേവനത്തിലേക്ക് കണക്ട് ചെയ്യുക, പിന്നീട് iptables -t nat -L POSTROUTING -v -n ഉപയോഗിച്ച് വിവർത്തന കൗണ്ടറുകൾ നീങ്ങിയെന്ന് ഉറപ്പാക്കുക, കാരണം പൂജ്യം പാക്കറ്റുള്ള നിയമം ഒരിക്കലും പൊരുത്തപ്പെടാത്ത നിയമമാണ്. മടക്ക ദിശ ട്രാക്ക് ചെയ്യുന്നു എന്ന തെളിവ് വേണ്ടിവരുമ്പോൾ conntrack -L -s 10.8.0.5 ഫ്ലോയും അതിന്റെ അവസ്ഥയും കാണിക്കുന്നു.

സെർവർ കോൺഫിഗിൽ ഒരു കുറിപ്പ് വിടുക: ഏത് സബ്നെറ്റ്, ഏത് ഇന്റർഫേസ്, ഏത് നിയമം, LAN റൗട്ടറിൽ മടക്ക റൂട്ട് ഉണ്ടോ എന്നിവ. അടുത്ത തവണ ഒരു ക്ലൈന്റ് അപ്ഗ്രേഡ് തള്ളിയ റൂട്ട് മായ്ക്കുമ്പോൾ, ആ കുറിപ്പ് തീയണയ്ക്കൽ സെഷനെ ഒരു വരിയുടെ അറ്റകുറ്റപ്പണിയാക്കി മാറ്റുന്നു.