OpenVPN-ലേക്ക് കണക്ട് ചെയ്തു, പക്ഷേ ഒന്നും ലോഡ് ആകുന്നില്ല: ക്ലയന്റിൽ നിന്ന് പുറത്തേക്കുള്ള ഒരു യാത്ര

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

ക്ലയന്റിൽ നിന്ന് തുടങ്ങി പുറത്തേക്ക് നീങ്ങുക

ഈ ക്രമത്തിൽ മൂന്ന് പരിശോധനകൾ നടത്തി ആദ്യത്തേത് എവിടെ പരാജയപ്പെടുന്നു എന്ന് എഴുതുക. സർവറിന്റെ ടണൽ വിലാസത്തിലേക്ക് ping ചെയ്യുക, അത് ടണൽ തന്നെ ട്രാഫിക് വഹിക്കുന്നു എന്ന് തെളിയിക്കുന്നു. നമ്പർ ഉപയോഗിച്ച് ഒരു പൊതു വിലാസത്തിലേക്ക് ping ചെയ്യുക, അത് പേര് വിശകലനം ഉൾപ്പെടുത്താതെ കൈമാറ്റവും വിവർത്തനവും തെളിയിക്കുന്നു. പിന്നെ ഒരു ഹോസ്റ്റ് നാമം പരിഹരിക്കാൻ ശ്രമിക്കുക, DNS ഉപയോഗിക്കുന്ന ഒരേയൊരു പരിശോധന അതാണ്. ഓരോ ഫലവും സംശയത്തിൽ നിന്ന് ഒരു പാളി മുഴുവൻ നീക്കം ചെയ്യുന്നു.

ബ്രൗസർ വേഗത്തിലാണെന്ന് തോന്നുന്നതിനാൽ മൂന്നാം പരിശോധനയിലേക്ക് ചാടരുത്. പരാജയപ്പെട്ട പേജ് ലോഡ് മൂന്ന് പാളികളെയും ഒരുമിച്ച് മൂടുന്നു, അവിടെ നിന്ന് തുടങ്ങിയാണ് ആളുകൾ പിന്നീട് പ്രവർത്തിച്ചിരുന്ന ടണൽ വീണ്ടും നിർമ്മിക്കുന്നത്. പരാജയപ്പെടുന്ന പേജ് മൂന്നിൽ ഏതാണ് തകർന്നതെന്ന് പറയുന്നില്ല.

രണ്ട് ക്യാപ്ചർ പാക്കറ്റുകൾ എവിടെ നിൽക്കുന്നു എന്ന് കാണിക്കുന്നു

ക്ലയന്റിൽ നിന്ന് ഒരു പൊതു വിലാസത്തിലേക്ക് ping നടക്കുമ്പോൾ ടണൽ ഇന്റർഫേസിൽ ഒരു ക്യാപ്ചർ, ഇന്റർനെറ്റിൽ എത്തേണ്ട അപ്ലിങ്കിൽ മറ്റൊന്ന് എടുക്കുക. സമയ മുദ്രകൾ ഒത്തുപോകാൻ രണ്ടും ഒരുമിച്ച് പ്രവർത്തിപ്പിക്കുക.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

അഭ്യർത്ഥനകൾ ടണലിൽ പ്രത്യക്ഷപ്പെടുകയും അപ്ലിങ്കിൽ ഒരിക്കലും വരികയും ചെയ്യുന്നില്ലെങ്കിൽ, സർവർ അവ ടണലിനും വയറിനും ഇടയിൽ ഉപേക്ഷിച്ചു, കാരണം കൈമാറ്റമോ ഫോർവേഡ് ഫയർവാൾ നയമോ ആണ്, NAT അല്ല. രണ്ടിലും പ്രത്യക്ഷപ്പെട്ടാൽ, സർവർ തന്റെ ഭാഗം ചെയ്തു, ഉത്തരം കൂടുതൽ പുറത്ത് നഷ്ടപ്പെട്ടു, ഇത് വിവർത്തനത്തിലേക്കോ മുകളിലെ ഫിൽട്ടറിലേക്കോ ദാതാവിന്റെ വശത്തുള്ള നിയന്ത്രണത്തിലേക്കോ വിരൽ ചൂണ്ടുന്നു.

അപ്ലിങ്കിന്റെ പേര് ട്യൂട്ടോറിയലിൽ നിന്നല്ല, റൂട്ടിംഗ് ടേബിളിൽ നിന്ന് എടുക്കുക. ക്ലൗഡ് ഇമേജുകളും പേരുമാറ്റിയ അഡാപ്റ്ററുകളും ഗൈഡിലെ ഉദാഹരണ ഇന്റർഫേസുമായി അപൂർവ്വമായേ ഒത്തുപോകുന്നു, തെറ്റായ ഉപകരണത്തിൽ എടുത്ത ക്യാപ്ചർ കൈമാറ്റം ചെയ്യാത്ത സർവറിനെപ്പോലെ തന്നെ കാണപ്പെടുന്നു:

ip -4 route get 9.9.9.9

ആ ഔട്ട്പുട്ടിലെ dev ഫീൽഡ് NAT നിയമത്തിന് പിന്നീട് വേണ്ടിവരുന്ന പേരാണ്, അതിനാൽ അത് സൂക്ഷിക്കുക.

കൈമാറ്റം കേർണലിലെ ഒരു സ്വിച്ചും ഫയർവാൾ നയവുമാണ്

കേർണൽ ആദ്യം കൈമാറാൻ സമ്മതിക്കണം. നിലവിലെ മൂല്യം വായിക്കുക, പിന്നെ പ്രവർത്തിക്കുന്ന കേർണലിൽ മാത്രം എഴുതുന്നതിന് പകരം ക്രമീകരണം സ്ഥിരമാക്കുക:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

കൈമാറ്റം പകുതി മാത്രമാണ്. UFW ഉള്ള ഹോസ്റ്റിൽ ഫോർവേഡ് നയം /etc/default/ufw-ൽ സജ്ജീകരിക്കുന്നു, റീലോഡ് പ്രാബല്യത്തിൽ വരുന്നതിന് മുൻപ് അത് ACCEPT ആയിരിക്കണം. ഫോർവേഡ് പാതയിലെ സ്ഥിരസ്ഥിതി ഡ്രോപ്പ് ഹാൻഡ്ഷേക്ക് പൂർണ്ണമായി ആരോഗ്യകരമായി വിട്ട് ടണലിലൂടെ പുറത്തുപോകാൻ ശ്രമിക്കുന്ന ഓരോ പാക്കറ്റും നിശ്ശബ്ദമായി വലിച്ചെറിയുന്നു, അതാണ് നിങ്ങൾ തുടങ്ങിയ കൃത്യമായ ലക്ഷണം.

nftables നേരിട്ട് കൈകാര്യം ചെയ്യുന്ന ഹോസ്റ്റുകൾക്ക് അതേ ചോദ്യം മറ്റൊരു വാക്യഘടനയിൽ വരുന്നു. ക്ലയന്റ് പരിശോധന നടക്കുമ്പോൾ ഫോർവേഡ് ചെയിനിലെ കൗണ്ടറുകൾ നോക്കുക, കാരണം ആലോചിക്കപ്പെടുന്ന ചെയിനും വലിച്ചെറിയുന്ന ചെയിനും കോൺഫിഗറേഷൻ ഫയലിൽ ഒരുപോലെ കാണപ്പെടുന്നു.

NAT നിയമത്തിൽ യഥാർത്ഥ എഗ്രസ് ഇന്റർഫേസ് പേര് നൽകുക

ഉറവിട വിവർത്തനം ഹോസ്റ്റ് യഥാർത്ഥത്തിൽ വിടുന്ന ഇന്റർഫേസിനാണ്, സർവർ വിതരണം ചെയ്യുന്ന പൂളിനൊപ്പം. ആ നിയമത്തിന്റെ രണ്ട് പകുതികളും യാഥാർത്ഥ്യം വിവരിക്കണം, ഒന്നും ഓപ്ഷണൽ അല്ല.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

പതിവ് പരാജയം ഗൈഡിൽ നിന്ന് പകർത്തിയ ഒരു നിയമമാണ്, അത് -o eth0 എന്ന് പറയുന്നു, എന്നാൽ ആ യന്ത്രത്തിന്റെ അഡാപ്റ്ററിന് വേറെ പേരാണ്. നിയമം മുന്നറിയിപ്പില്ലാതെ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, ഒന്നുമായും ഒത്തുപോകുന്നില്ല, ക്ലയന്റിന് ഇപ്പോഴും ഇന്റർനെറ്റ് ഇല്ല. പൂൾ അതേ തെറ്റിന്റെ മറ്റേ പകുതിയാണ്: സർവർ 10.44.0.0/24 നൽകുകയും നിയമം 10.8.0.0/24 ഉൾക്കൊള്ളുകയും ചെയ്താൽ, ഒന്നും ഒരിക്കലും ഒത്തുപോകില്ല.

നിയമത്തിന്റെ വാചകം വിശ്വസിക്കുന്നതിന് പകരം കൗണ്ടറുകൾ നോക്കുക. ലിസ്റ്റ് ഓരോ നിയമത്തിനും പാക്കറ്റുകൾ റിപ്പോർട്ട് ചെയ്യുന്നു, ഒരിക്കലും ഒത്തുപോകാത്ത നിയമം എത്ര ശരിയായി കാണപ്പെട്ടാലും പൂജ്യത്തിൽ തന്നെ നിൽക്കുന്നു. ആ സംഖ്യയിൽ നിന്ന് എന്തെങ്കിലും വായിക്കുന്നതിന് മുൻപ് അതിന് ഒരു മിനിറ്റ് യഥാർത്ഥ ക്ലയന്റ് ട്രാഫിക് നൽകുക:

iptables -t nat -L POSTROUTING -v -n

യഥാർത്ഥ ക്ലയന്റ് പരിശോധനയ്ക്ക് ശേഷം പൂജ്യം പാക്കറ്റ് എണ്ണം എന്നാൽ പൊരുത്തം തെറ്റാണ്, ടണൽ തകർന്നു എന്നല്ല. ഒത്തുപോയാൽ നിയമക്കൂട്ടം സംരക്ഷിക്കുക, അത് റീബൂട്ടിനെ അതിജീവിക്കട്ടെ; നിങ്ങളുടെ ഷെൽ ചരിത്രത്തിൽ മാത്രം ജീവിക്കുന്ന അറ്റകുറ്റപ്പണി ആദ്യ റീസ്റ്റാർട്ടിൽ തന്നെ അപ്രത്യക്ഷമാകുന്നു.

സർവർ ഒരു ക്ലൗഡ് NAT ഇൻസ്റ്റൻസ് കൂടിയാണെങ്കിൽ, പ്ലാറ്റ്ഫോമിനും വാക്കുണ്ട്. വിലാസങ്ങൾ വിവർത്തനം ചെയ്യുന്ന ഇൻസ്റ്റൻസിന് സാധാരണയായി ദാതാവ് ആ ക്രമീകരണം വാഗ്ദാനം ചെയ്യുന്നിടത്ത് ഉറവിട, ലക്ഷ്യ പരിശോധന പ്രവർത്തനരഹിതമാക്കേണ്ടതുണ്ട്, VPN പോർട്ട് തന്നെ പുറത്തുനിന്ന് എത്താവുന്നതുമായിരിക്കണം.

DNS ആദ്യത്തിന് പിന്നിലെ രണ്ടാമത്തെ പരാജയമാണ്

പേരുകൾ പരാജയപ്പെടുമ്പോൾ വിലാസം കൊണ്ടുള്ള ping പ്രവർത്തിക്കുന്നത് റിസോൾവർ പ്രശ്നമാണ്, അതിന് സ്വന്തം കാരണമുണ്ട്. തന്റെ പ്രാദേശിക റിസോൾവർ സൂക്ഷിക്കുന്ന ക്ലയന്റ് ആ ചോദ്യങ്ങൾ പൂർണ്ണ ടണലിലേക്ക് അയച്ച് ഒരിക്കലും വരാത്ത ഉത്തരത്തിനായി കാത്തിരിക്കുന്നു, കാരണം പ്രാദേശിക റിസോൾവർ ഇപ്പോൾ റൂട്ടിന്റെ തെറ്റായ വശത്താണ്.

ക്ലയന്റ് എവിടെ ചോദിക്കണമെന്ന് അറിയാൻ സർവറിൽ നിന്ന് ഒരു റിസോൾവർ അയക്കുക. രണ്ട് എൻട്രികൾ ആദ്യത്തേത് എത്താത്തപക്ഷം ക്ലയന്റിന് ബദൽ നൽകുന്നു, രണ്ടും ടണൽ യഥാർത്ഥത്തിൽ അനുവദിക്കുന്ന റിസോൾവറുകളായിരിക്കണം.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows ക്ലയന്റുകൾ പിന്നീട് പ്രാദേശിക റിസോൾവറിലേക്ക് തിരികെ പോകാം, block-outside-dns അത് തടയാൻ വേണ്ടിയുള്ളതാണ്, പക്ഷേ പ്രാദേശിക നെറ്റ്വർക്കിന് മാത്രം പരിഹരിക്കാനാകുന്ന പേരുകൾ നഷ്ടപ്പെടുന്നതിന്റെ വിലയ്ക്ക്. systemd-resolved ഉപയോഗിക്കുന്ന Linux ക്ലയന്റുകൾ സ്ക്രിപ്റ്റ് ഇൻസ്റ്റാൾ ചെയ്യാത്ത പക്ഷം അയച്ച റിസോൾവർ പലപ്പോഴും അവഗണിക്കുന്നു, അതിനാൽ അയക്കൽ അവഗണിക്കപ്പെട്ടു എന്ന് തീരുമാനിക്കുന്നതിന് മുൻപ് ടണൽ ഉപകരണത്തിനായി resolvectl status പരിശോധിക്കുക.

ഉപയോക്താവ് അനുഭവിക്കുന്ന രീതിയിൽ ഈ യാത്ര അവസാനിപ്പിക്കുക. ക്ലയന്റിൽ നിന്ന് യഥാർത്ഥ പേജ് ലോഡ് ചെയ്യുക, ഏത് വിലാസത്തിൽ നിന്നാണ് പുറത്തുപോകുന്നതെന്ന് സ്ഥിരീകരിക്കുക, സർവർ റീബൂട്ട് ചെയ്യുക, വീണ്ടും കണക്ട് ചെയ്യുക, മൂന്ന് പരിശോധനകളും ആവർത്തിക്കുക. ആ രണ്ടാം റൗണ്ട് മാത്രമാണ് സംരക്ഷിച്ച നിയമങ്ങളും ഫയർവാൾ നയവും അയച്ച റിസോൾവറും എല്ലാം ഒരുമിച്ച് അതിജീവിച്ചു എന്ന് തെളിയിക്കുന്നത്.