PiVPN ഹാൻഡ്ഷേക്ക് പ്രവർത്തിക്കുന്നു, പേജുകൾ നിലയ്ക്കുന്നു: MASQUERADE പരിശോധിക്കുക

നിങ്ങളുടെ ഫോൺ ടണൽ കണക്റ്റ് ചെയ്തതായി കാണിക്കുന്നു, ക്ലയന്റ് ഒരു സ്വകാര്യ വിലാസം റിപ്പോർട്ട് ചെയ്യുന്നു, എന്നിട്ടും ആദ്യ പേജ് ലോഡിന്റെ പകുതിയിൽ തൂങ്ങിക്കിടക്കുന്നു. ഈ സംയോജനം മിക്ക ആളുകളെയും സൈഫർ ക്രമീകരണങ്ങളിലേക്കും പ്രോസസറിന്റെ താപനിലയിലേക്കും അയയ്ക്കുന്നു, എന്നാൽ യഥാർത്ഥത്തിൽ അവിടെ ഒന്നും തകർന്നിട്ടില്ല. ടണൽ ഉയർന്നു, അതായത് ചർച്ച പൂർത്തിയായി; പരാജയപ്പെട്ടത് അടുത്ത ഘട്ടമാണ്, സെർവർ ക്ലയന്റിന്റെ പാക്കറ്റുകൾ ഇന്റർനെറ്റിന് കൈമാറാൻ ശ്രമിക്കുമ്പോൾ. ആ പാക്കറ്റുകൾ പോകുന്ന അതേ വഴിയിലൂടെ നടക്കുക, പൊരുത്തക്കേട് സാധാരണയായി NAT പട്ടികയുടെ ഒരു വരിയിൽ കാണാം.

ക്ലയന്റിന് എത്താൻ കഴിയുന്നതും കഴിയാത്തതും കൊണ്ട് തുടങ്ങുക

കണക്റ്റ് ചെയ്ത ക്ലയന്റിൽ നിന്ന്, പൊതു ഇന്റർനെറ്റിൽ ഉള്ള ഒരു പേജ് ലോഡ് ചെയ്ത് അത് ഉടനടി പരാജയപ്പെടുന്നുണ്ടോ അതോ പകുതിയിൽ നിൽക്കുന്നുണ്ടോ എന്ന് ശ്രദ്ധിക്കുക. തുടർന്ന് VPN സെർവറിന്റെ സ്വന്തം സ്വകാര്യ വിലാസത്തിലുള്ള ഒരു വിഭവം തുറന്ന് രണ്ട് ഫലങ്ങളും താരതമ്യം ചെയ്യുക.

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

അടുത്തതായി, പൊതു വിലാസത്തിൽ എത്താൻ സെർവർ ഏത് ഇന്റർഫേസ് ഉപയോഗിക്കുമെന്ന് ചോദിക്കുക. ip route get 203.0.113.9 അതിന്റെ ആദ്യ വരിയിൽ തിരഞ്ഞെടുത്ത ഉപകരണവും ഉറവിടവും അച്ചടിക്കുന്നു. ആ ഉപകരണത്തിന്റെ പേര് എഴുതിവയ്ക്കുക, കാരണം NAT നിയമത്തിൽ ഉണ്ടായിരിക്കേണ്ട മൂല്യം അതാണ്.

പാക്കറ്റുകൾ പുറത്തുപോകുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്ന നിയമം വായിക്കുക

MASQUERADE ഒരു പാക്കറ്റ് വീണ്ടും എഴുതുന്നത് ആ പാക്കറ്റ് നിയമത്തിൽ പേരിട്ട ഇന്റർഫേസിലൂടെ പുറത്തുപോകുമ്പോൾ മാത്രമാണ്. കമ്പിയുള്ള ഉപകരണത്തിൽ പരിമിതപ്പെടുത്തിയ നിയമം Wi-Fi വഴി പുറത്തുപോകുന്ന ട്രാഫിക്കിന് ഒന്നും ചെയ്യുന്നില്ല, പാക്കറ്റ് മുകളിലെ റൂട്ടർ വരെ അതിന്റെ സ്വകാര്യ ഉറവിട വിലാസം നിലനിർത്തുന്നു. ആ റൂട്ടറിന് നിങ്ങളുടെ ടണൽ പൂളിലേക്ക് തിരിച്ചുള്ള വഴിയില്ല, അതിനാൽ അത് മറുപടി ഉപേക്ഷിക്കുന്നു, ക്ലയന്റ് തുറന്ന് പിന്നീട് മരിക്കുന്ന ഒരു കണക്ഷൻ കാണുന്നു. ആദ്യ മറുപടി ആവശ്യമാകുന്നതിന് മുമ്പ് പേജിന്റെ എത്ര ഭാഗം എത്തുന്നു എന്നതിനനുസരിച്ച് ലക്ഷണം വളരുന്നു.

ലൈവ് പട്ടിക ലിസ്റ്റ് ചെയ്ത് MASQUERADE എന്ന വാക്ക് മാത്രം തിരയുന്നതിന് പകരം ഔട്ട്-ഇന്റർഫേസ് കോളം വായിക്കുക. ഫോർമാറ്റ് ചെയ്ത ലിസ്റ്റിനേക്കാൾ ചേർക്കൽ രൂപത്തിലുള്ള ഔട്ട്പുട്ട് താരതമ്യം ചെയ്യാൻ എളുപ്പമാണ്:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

ഒരിക്കൽ Ethernet ഉം ഇപ്പോൾ Wi-Fi ഉം ഉപയോഗിക്കുന്ന Raspberry Pi-യിൽ, പഴയ പേര് മിക്കപ്പോഴും മുഴുവൻ കഥയാണ്. ഇൻസ്റ്റാളർ സെറ്റപ്പ് സമയത്ത് ഏത് ഉപകരണം ഉണ്ടായിരുന്നു എന്ന് രേഖപ്പെടുത്തി, സംഭരിച്ച നിയമസംഗ്രഹം ഓരോ ബൂട്ടിലും അത് വീണ്ടും പ്രവർത്തിപ്പിക്കുന്നു. മറ്റെന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് റൂട്ട് തിരയലിൽ നിന്നുള്ള ഉപകരണത്തെ നിയമത്തിലെ ഉപകരണവുമായി താരതമ്യം ചെയ്യുക. അവ ഒത്തുപോകുന്നുവെങ്കിൽ ഇന്റർഫേസ് നിങ്ങളുടെ പ്രശ്നമല്ല, അവസാന വിഭാഗത്തിലെ കൗണ്ടറുകളിലേക്ക് പോകണം. അവ വ്യത്യസ്തമാണെങ്കിൽ, പരിഹാരം സ്ഥിരതാ ഫയലിലെ ഒരു വാക്കിന്റെ എഡിറ്റ് ആണ്.

സംഭരിച്ച നിയമസംഗ്രഹം ശരിയാക്കുക, പ്രവർത്തിക്കുന്നത് മാത്രമല്ല

ലൈവ് പട്ടിക മാത്രം എഡിറ്റ് ചെയ്യുന്നത് അടുത്ത റീബൂട്ട് വരെ നിലനിൽക്കും, അത് പ്രശ്നം പരിഹരിച്ചുവെന്ന് നിങ്ങളെ ബോധ്യപ്പെടുത്താൻ കൃത്യമായി മതിയാകും. ബൂട്ടിൽ തിരികെ വരുന്ന നിയമങ്ങൾ ഫയർവാൾ സ്ഥിരതാ പാക്കേജ് വീണ്ടും ലോഡ് ചെയ്യുന്ന ഒരു ഫയലിലാണ്. Debian അടിസ്ഥാനമാക്കിയ Pi ഇമേജുകളിൽ ആ ഫയൽ സാധാരണയായി /etc/iptables/rules.v4.

തൊടുന്നതിന് മുമ്പ് ഒരു പകർപ്പ് എടുക്കുക, തുടർന്ന് MASQUERADE വരിയിലെ ഔട്ട്-ഇന്റർഫേസ് നിങ്ങൾ എഴുതിയ ഉപകരണം കൊണ്ട് മാറ്റുക, ഉദാഹരണത്തിന് -o wlan0 എന്നതിന് പകരം -o eth0. നിങ്ങളുടെ ക്ലയന്റ് പൂൾ മാറിയിട്ടില്ലെങ്കിൽ ഉറവിട ശ്രേണി അതുപോലെ വയ്ക്കുക. വീണ്ടും ലോഡ് ചെയ്ത് നിയമം ഇപ്പോൾ ശരിയായ ഉപകരണം പറയുന്നുവെന്ന് ഉറപ്പാക്കുക:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

അടുത്തടുത്തുള്ള രണ്ട് ക്രമീകരണങ്ങൾ മറക്കാൻ എളുപ്പമാണ്. sysctl net.ipv4.ip_forward 1 റിപ്പോർട്ട് ചെയ്യണം, മുകളിലെ റൂട്ടർ സ്വകാര്യ ഉറവിട വിലാസങ്ങൾ സ്വയം ഫിൽട്ടർ ചെയ്യരുത്.

നിയമം പ്രവർത്തിക്കുന്നുവെന്ന് തെളിയിക്കുക, തുടർന്ന് ഇപ്പോഴും മന്ദഗതിയിലുള്ളത് വേർതിരിക്കുക

ഒരു നിയമം പൊരുത്തപ്പെട്ടുവെന്നതിന്റെ ഏക സത്യസന്ധമായ തെളിവ് കൗണ്ടറുകളാണ്. വിശദമായ ലിസ്റ്റ് പ്രവർത്തിപ്പിക്കുക, ക്ലയന്റിൽ ഒരു ഡൗൺലോഡ് ആരംഭിക്കുക, വീണ്ടും പ്രവർത്തിപ്പിക്കുക. നിങ്ങളുടെ നിയമത്തിന് അടുത്തുള്ള പാക്കറ്റ്, ബൈറ്റ് കോളങ്ങൾ ഉയരണം, പൂജ്യത്തിൽ നിൽക്കുന്ന നിയമം ഇപ്പോഴും പൊരുത്തപ്പെടുന്നില്ല. കൗണ്ടറുകൾ നീങ്ങുന്നുവെങ്കിലും പേജുകൾ ഇപ്പോഴും പരാജയപ്പെടുന്നുവെങ്കിൽ, ഉറവിട ശ്രേണിയെ യഥാർത്ഥ പൂളുമായി ഇതുപയോഗിച്ച് താരതമ്യം ചെയ്യുക grep -n "^server " /etc/openvpn/server.conf. അവ നീങ്ങുകയും പേജുകൾ ലോഡ് ആകുകയും ചെയ്യുന്നുവെങ്കിലും ത്രൂപുട്ട് മോശമാണെങ്കിൽ, വിവർത്തനം കഴിഞ്ഞു, ബാക്കിയുള്ള പ്രശ്നം മറ്റൊരിടത്താണ്.

ഒരേ ക്ലയന്റിൽ നിന്നുള്ള രണ്ട് കൈമാറ്റങ്ങൾ താരതമ്യം ചെയ്യുക, ഒന്ന് പ്രാദേശിക നെറ്റ്വർക്കിലെ ഒരു ഹോസ്റ്റിലേക്ക്, മറ്റൊന്ന് ടണലിലൂടെ അതേ ഹോസ്റ്റിലേക്ക്. രണ്ടിലും മന്ദഗതിയാണെങ്കിൽ അത് VPN-യെയല്ല, Pi-യുടെ മുകളിലെ ലിങ്കിനെയോ Wi-Fi കണക്ഷനെയോ സൂചിപ്പിക്കുന്നു. ടണലിലൂടെ മാത്രം മന്ദഗതിയാണെങ്കിൽ അത് MTU-വിനെയും വീണ്ടും അയയ്ക്കലുകളെയും സൂചിപ്പിക്കുന്നു, അവ ഇതുപയോഗിച്ച് പരിശോധിക്കാം ip -s link show tun0 ഏതെങ്കിലും ക്രിപ്റ്റോ ക്രമീകരണം മാറ്റുന്നതിന് മുമ്പ്.

പരീക്ഷണം പിൻവലിക്കാൻ പകർപ്പ് പുനഃസ്ഥാപിച്ച് വീണ്ടും ലോഡ് ചെയ്യുക, തുടർന്ന് യഥാർത്ഥ നിയമവും അതിന്റെ കൗണ്ടറുകളും തിരികെ വന്നുവെന്ന് ഉറപ്പാക്കുക. അടുത്ത അപ്ലിങ്ക് മാറ്റം അതേ പൊരുത്തക്കേട് വീണ്ടും കണ്ടെത്തുന്നതിനാൽ, എഗ്രെസ് ഉപകരണവും വീണ്ടും ലോഡ് ചെയ്യാനുള്ള കമാൻഡും സെർവർ കുറിപ്പുകളിൽ എഴുതുക. തെറ്റായ ഉപകരണം പറയുന്ന നിയമം ട്രാഫിക്കിന് അത് ആവശ്യമാകുന്നത് വരെ അദൃശ്യമായി തുടരുന്നു.