റിമോട്ട് ഉപയോക്താക്കൾ VPN ഹബ് വഴി രണ്ടാമത്തെ സൈറ്റിൽ എത്തുന്നില്ല

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

ട്രാൻസിറ്റിന് മൂന്ന് ലുക്കപ്പുകൾ വേണം, ഒരു ടണൽ മതിയാകില്ല

ഓരോ ഉപകരണവും സ്വന്തം നീളമേറിയ പ്രിഫിക്സ് പൊരുത്തം നടത്തി അത് മറക്കുന്നു. ലാപ്ടോപ്പ് 10.20.0.50 അതിന്റെ പ്രാദേശിക റൗട്ടറിലേക്കല്ല, ടണലിലേക്ക് അയക്കണം. ഹബ് റിമോട്ട്-ആക്സസ് ഇന്റർഫേസിൽ വന്ന പാക്കറ്റ് എടുത്ത് സൈറ്റ്-ടു-സൈറ്റ് ഇന്റർഫേസിന് കൈമാറണം. ആസ്ഥാനം ഉപയോക്താവിന്റെ വിലാസത്തിനുള്ള മറുപടി ടണലിലൂടെ തിരികെ അയക്കണം. ഈ മൂന്നിൽ ഏതെങ്കിലും ഒന്ന് പരാജയപ്പെട്ടാൽ ബ്രൗസറിൽ ഒരേപോലെ കാണാം: നിശ്ശബ്ദത.

അതുകൊണ്ടാണ് ഓരോ ടണലും വെവ്വേറെ പരീക്ഷിക്കുന്നത് വളരെ കുറച്ചേ തെളിയിക്കുന്നത്. ഹബ്ബിന്റെ LAN വിലാസത്തിലേക്ക് പിംഗ് ചെയ്യുന്നത് ആദ്യ തീരുമാനം പരീക്ഷിക്കുന്നു, ആസ്ഥാനത്തുനിന്ന് ഹബ്ബിലേക്ക് പിംഗ് ചെയ്യുന്നത് മൂന്നാമത്തേത് പരീക്ഷിക്കുന്നു. പരാജയപ്പെടുന്ന പാക്കറ്റിന്റെ ഉറവിടം ഉപയോക്തൃ പൂൾ, ലക്ഷ്യം രണ്ടാമത്തെ സൈറ്റ്, അതിനാൽ ആദ്യം ആ പ്രിഫിക്സുകൾ എഴുതിവയ്ക്കുക. ഇവിടെ പൂൾ 10.80.0.0/24, ഹബ്ബിന്റെ LAN 10.10.0.0/24, ആസ്ഥാനം 10.20.0.0/24.

അകലെയുള്ള പ്രിഫിക്സ് റിമോട്ട് ക്ലയന്റിലേക്ക് തള്ളുക

ഒരു OpenVPN റിമോട്ട്-ആക്സസ് സെർവറിൽ ക്ലയന്റ് കണക്ട് ചെയ്യുമ്പോൾ റൂട്ടുകൾ പഠിക്കുന്നു. push ഇല്ലെങ്കിൽ, സ്പ്ലിറ്റ്-ടണൽ ക്ലയന്റ് 10.20.0.50 സ്വന്തം ഗേറ്റ്വേയിലേക്ക് അയക്കുന്നു, പാക്കറ്റ് ഒരിക്കലും ടണലിൽ പ്രവേശിക്കുന്നില്ല.

push "route 10.20.0.0 255.255.255.0"

തള്ളിയ റൂട്ട് ക്ലയന്റ് കണക്ട് ചെയ്യുമ്പോൾ പ്രാബല്യത്തിൽ വരുന്നു, അതിനാൽ ഓൺലൈനിൽ തുടരുന്ന ഉപയോക്താവ് വീണ്ടും കണക്ട് ചെയ്യുന്നതുവരെ ഒന്നും കാണുന്നില്ല. ക്ലയന്റിൽ പരിശോധിക്കുക: Linux-ൽ ip route get 10.20.0.50, Windows-ൽ route print. ഔട്ട്പുട്ട് ടണൽ ഇന്റർഫേസിന്റെ പേര് പറയണം.

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

ഹബ്ബിന് യഥാർത്ഥ എഗ്രസ് റൂട്ട് നൽകുക

ആസ്ഥാനത്തിന്റെ പ്രിഫിക്സിന് ഹബ്ബിന് സ്വന്തം അടുത്ത ഹോപ്പ് വേണം. റൂട്ട് ചെയ്ത ടണലിൽ അത് സൈറ്റ്-ടു-സൈറ്റ് ഇന്റർഫേസിലൂടെയുള്ള സാധാരണ റൂട്ടാണ്, ഒരു കമാൻഡ് തിരഞ്ഞെടുത്ത റൂട്ടും തിരഞ്ഞെടുത്ത ഉറവിടവും ഒരുമിച്ച് കാണിക്കുന്നു:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

സൈറ്റ്-ടു-സൈറ്റ് കാല് തന്നെ OpenVPN ആണെങ്കിൽ, റൂട്ട് ആ കോൺഫിഗറേഷനിൽ പിയറിന്റെ ടണൽ വിലാസം ഗേറ്റ്വേയായി വച്ച് ജീവിക്കാം: route 10.20.0.0 255.255.255.0 172.30.0.2. ഗേറ്റ്വേ നിർബന്ധമാണ്. അത് ഒഴിവാക്കിയാൽ അടുത്ത ഹോപ്പ് ഇംപ്ലിമെന്റേഷന്റെ ഡിഫോൾട്ടിലേക്ക് വീഴുന്നു, അത് ഒരു റിമോട്ട് ക്ലയന്റും ഒന്നിലധികം പിയറുകളുള്ള ഹബ്ബും തമ്മിൽ വ്യത്യസ്തമാണ്.

നയാധിഷ്ഠിത IPsec വ്യത്യസ്തമാണ്: ഹബ്ബിന്റെ കെർണൽ പാക്കറ്റ് സാധാരണ LAN ഗേറ്റ്വേയിലേക്ക് അയക്കുന്നു, നയം പുറത്തുപോകുന്ന വഴിയിൽ അത് പിടിക്കുന്നു, അതിനാൽ ടണൽ റൂട്ട് ഒന്നുകിൽ ഒന്നും ചെയ്യുന്നില്ല, അല്ലെങ്കിൽ ട്രാഫിക്കിനെ നയം ഒഴിവാക്കി കൊണ്ടുപോകുന്നു. മുകളിലെ കമാൻഡിലെ ഉറവിടം ശ്രദ്ധിക്കുക, കാരണം പൂളിന്റെ വിലാസത്തിനുപകരം 10.10.0.1 എന്നാൽ കെർണൽ അകലെയുള്ള വശം നിരസിക്കുന്ന വിലാസം തിരഞ്ഞെടുത്തു എന്നാണ്. iroute ഉം ഉത്തരമല്ല; അത് സെർവറിനോട് ഏത് ക്ലയന്റ് തന്റെ ടണലിന് പിന്നിലെ സബ്നെറ്റ് സ്വന്തമാക്കുന്നു എന്ന് പറയുന്നു, മൂന്നാമത്തെ സൈറ്റിനുള്ള ട്രാഫിക്ക് എവിടേക്ക് അയക്കണം എന്നല്ല.

അകലെയുള്ള വശം ഉപയോക്തൃ പൂൾ വരെ വിപുലീകരിക്കുക

ആസ്ഥാനം ഇതിനകം ഹബ്ബിന്റെ LAN, 10.10.0.0/24 ഉൾക്കൊള്ളുന്നു. ഉപയോക്തൃ പൂൾ രണ്ടാമത്തെ പ്രിഫിക്സാണ്, അത് സെലക്ടറുകളിലും ഉണ്ടായിരിക്കണം, അല്ലെങ്കിൽ 10.80.0.25-ലേക്ക് അയക്കുന്ന മറുപടി ഒരു നയവും ഉൾക്കൊള്ളുന്നില്ല. ഓരോ പിയറും സ്വന്തം വശത്തുനിന്ന് അതേ ജോടി പ്രിഫിക്സ് സെറ്റുകൾ പേരിടുന്നു:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

ഒരു ഉപകരണത്തിന്റെ local_ts മറ്റൊന്നിന്റെ remote_ts ആണ്. ഹബ്ബിന്റെ ബ്ലോക്ക് ആസ്ഥാനത്തേക്ക് പകർത്തുക, ജോടി തിരിഞ്ഞുപോകുന്നു, അതിനാൽ ചൈൽഡ് SA ഒരിക്കലും ഉയരുന്നില്ല.

പഴയ ipsec.conf സിന്റാക്സ് കോമ കൊണ്ട് വേർതിരിച്ച leftsubnet ഉപയോഗിക്കുന്നു. പ്രവർത്തിക്കുന്ന സെക്യൂരിറ്റി അസോസിയേഷൻ ചർച്ച ചെയ്ത സെലക്ടറുകൾ സൂക്ഷിക്കുന്നു, അതിനാൽ എഡിറ്റിന് ശേഷം ടണൽ വീണ്ടും സ്ഥാപിക്കുക. 10:00-ന് മാറ്റിയ സെലക്ടർ 09:40-ന് ഉയർന്ന SA-യ്ക്കെതിരെ പരീക്ഷിച്ചാലും പരാജയപ്പെടുന്നു, അതേസമയം കോൺഫിഗ് ഫയൽ മുഴുവൻ സമയവും ശരിയായി കാണുന്നു.

പിന്നീട് അവസാന ഹോപ്പ് പരിശോധിക്കുക. അകലെയുള്ള എൻഡ്പോയിന്റിൽ ip route get 10.80.0.25 ടണലിലേക്ക് ചൂണ്ടണം. സേവനം LAN റൗട്ടറിനെ അതിന്റെ ഡിഫോൾട്ട് ഗേറ്റ്വേയായി ഉപയോഗിക്കുന്നുവെങ്കിൽ, ആ റൗട്ടറിനും റിട്ടേൺ റൂട്ട് വേണം, അല്ലെങ്കിൽ മറുപടി അവിടെ മരിക്കുന്നു. ആ സെഗ്മെന്റിൽ tcpdump -ni eth1 host 10.80.0.25 പ്രവർത്തിപ്പിക്കുന്നത് മറുപടി എൻഡ്പോയിന്റിൽ നിന്ന് പുറത്തുപോയോ എന്ന് കാണിക്കുന്നു.

ഹബ്ബിൽ ഫ്ലോ അനുവദിക്കുക

ഫോർവേഡിംഗ് സജീവമായിരിക്കണം, പാത അനുവദിക്കപ്പെടണം. ഇന്റർഫേസുകൾക്കിടയിൽ എല്ലാം സ്വീകരിക്കുന്നതിനുപകരം നിയമങ്ങൾ രണ്ട് പ്രിഫിക്സുകളിൽ പരിമിതപ്പെടുത്തുക.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

റിവേഴ്സ്-പാത്ത് ഫിൽട്ടറിംഗ് അതിന്റെ അടുത്തുള്ള നിശ്ശബ്ദ പരാജയമാണ്: രണ്ട് കാലുകളും വ്യത്യസ്ത ഇന്റർഫേസുകളിലാണെങ്കിൽ, rp_filter=1 മറുപടി ഉപേക്ഷിച്ചേക്കാം, അതേസമയം സ്വീകരണ നിയമത്തിന്റെ കൗണ്ടർ ഒട്ടും അനങ്ങുന്നില്ല. ഒരു ശ്രമത്തിന് മുമ്പും ശേഷവും iptables -vnL FORWARD താരതമ്യം ചെയ്യുക. ഒരിക്കലും വർദ്ധിക്കാത്ത നിയമത്തിൽ എത്തുന്നില്ല, അതിനാൽ അത് വീണ്ടും എഴുതുന്നതിനുപകരം ഒരു പാളി താഴെ നോക്കുക.

ഒരു ഗ്രൂപ്പിന് മാത്രം ട്രാൻസിറ്റ് വേണമെങ്കിൽ, ആഗോള push വിപുലീകരിക്കുന്നതിനുപകരം client-config-dir-ന് കീഴിലുള്ള ഓരോ ക്ലയന്റ് ഫയലിലും റൂട്ട് വയ്ക്കുക. ഹബ്ബിലെ Source NAT അകലെയുള്ള വശത്തിന്റെ റിട്ടേൺ റൂട്ടിന്റെ ആവശ്യകതയും ഒഴിവാക്കുന്നു, പക്ഷേ അത് ഉപയോക്താവിന്റെ വിലാസം മറയ്ക്കുന്നു, അതിനാൽ അകലെയുള്ള സൈറ്റിന്റെ ലോഗുകളും വിലാസാധിഷ്ഠിത നിയമങ്ങളും ഉപയോക്താക്കളെ തിരിച്ചറിയുന്നത് നിർത്തുന്നു.

ക്ലയന്റിൽ നിന്ന് പരിശോധിച്ച്, പിന്നീട് വിപരീത ക്രമത്തിൽ റോൾബാക്ക് ചെയ്യുക

ICMP മാത്രമല്ല, TCP പോർട്ട് പരീക്ഷിക്കുക, കാരണം സേവനം തടഞ്ഞിരിക്കുമ്പോൾ പിംഗ് കടന്നുപോകാം. ക്ലയന്റിൽ നിന്ന് nc -vz 10.20.0.50 445, traceroute -n 10.20.0.50 എന്നിവ രണ്ടാമത്തെ ഹോപ്പ് ഹബ്ബിന്റെ ടണൽ വിലാസമാണോ എന്ന് കാണിക്കുന്നു. ഹബ്ബിൽ, tcpdump -ni tun0 host 10.20.0.50, സൈറ്റ്-ടു-സൈറ്റ് ഇന്റർഫേസിലെ അതേ ഫിൽട്ടർ: രണ്ടിലും അഭ്യർത്ഥനയുണ്ടെങ്കിലും ഒന്നിലും മറുപടിയില്ലെങ്കിൽ പ്രശ്നം അകലെയുള്ള വശത്തേക്ക് നീങ്ങുന്നു.

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

റോൾബാക്ക് പട്ടിക സൂക്ഷിക്കുക, കാരണം നാല് വസ്തുക്കൾ മാറി, മൂന്നെണ്ണം മറക്കാൻ എളുപ്പമാണ്: തള്ളിയ റൂട്ട്, ഹബ്ബിന്റെ റൂട്ട്, സെലക്ടറുകൾ, ഫയർവാൾ നിയമങ്ങൾ. അവ വിപരീത ക്രമത്തിൽ പിൻവലിക്കുക, SA വീണ്ടും സ്ഥാപിക്കുക, ഒരു ഉപയോക്താവിനെ വീണ്ടും കണക്ട് ചെയ്യാൻ അനുവദിക്കുക. ഭാഗിക റോൾബാക്ക് ഇനി പൊരുത്തപ്പെടാത്ത ടണലിലേക്ക് ചൂണ്ടുന്ന റൂട്ട് വിട്ടേക്കുന്നു, അത് യഥാർത്ഥ നിശ്ശബ്ദതയേക്കാൾ വായിക്കാൻ ബുദ്ധിമുട്ടാണ്. OpenVPN 2.6 മാനുവൽ നിങ്ങളുടെ പതിപ്പിനായി push, route, iroute രേഖപ്പെടുത്തുന്നു.