VPN ക്ലയന്റുകൾ ബന്ധിക്കുന്നു പക്ഷേ ഇന്റർനെറ്റ് ഇല്ല: മൂന്ന് കാണാതായ ഭാഗങ്ങൾ

ക്ലയന്റിന് ഒരു വിലാസം ലഭിക്കുന്നു, സർവർ ping-ന് ഉത്തരം നൽകുന്നു, എന്നിട്ടും ഓരോ പേജും സമയപരിധി കഴിഞ്ഞ് പരാജയപ്പെടുന്നു. മിക്ക ആളുകളും ഈ ഘട്ടത്തിൽ ക്ലയന്റ് പ്രൊഫൈൽ എഡിറ്റ് ചെയ്യാൻ തുടങ്ങുന്നു, ഇത് സാധാരണയായി പാഴ്വേലയാണ്: ടണൽ ഉയർന്നാൽ സർവർ ഒരു റൗട്ടർ പോലെ പെരുമാറണം. പാക്കറ്റ് പുറത്തുപോയി ഉത്തരം തിരിച്ചുവരാൻ മൂന്ന് വ്യവസ്ഥകൾ ഒരേസമയം പാലിക്കണം, ഏതാണ് കാണാതായാലും ലക്ഷണം ഒന്നുതന്നെ.

പ്രവർത്തിക്കുന്ന ടണലിന് ഇപ്പോഴും പുറത്തേക്കുള്ള വഴിയില്ലാത്തത് എന്തുകൊണ്ട്

ഇന്റർഫേസുകൾക്കിടയിൽ പാക്കറ്റുകൾ ഫോർവേഡ് ചെയ്യാൻ കേർണൽ വേണം, ഇത് മിക്ക Linux വിതരണങ്ങളിലും സ്വതവേ ഓഫാണ്. പുറംലോകത്തിന് ഉത്തരം നൽകാൻ കഴിയുന്ന ഒരു വിലാസത്തിലേക്ക് ട്രാഫിക് വിവർത്തനം ചെയ്യണം, ഓരോ മുകൾ റൗട്ടറിനും ടണൽ സബ്നെറ്റിലേക്കുള്ള തിരിച്ചുവരവ് വഴി ഇതിനകം അറിയില്ലെങ്കിൽ. ഫയർവാളിന്റെ ഫോർവേഡ് പാത ഉത്തരങ്ങൾ ഉൾപ്പെടെ ഇരു ദിശകളിലും ട്രാഫിക് അനുവദിക്കണം.

ഇവയിൽ ഓരോന്നും വെവ്വേറെ പരിഹരിക്കാം, അതാണ് കെണി. വിവർത്തന നിയമമില്ലാതെ ഫോർവേഡിംഗ് ഓണാക്കിയാൽ പാക്കറ്റുകൾ സ്വകാര്യ ഉറവിടത്തോടെയും തിരിച്ചുവരവ് വഴിയില്ലാതെയും പുറത്തുപോകുന്നു. ഫോർവേഡ് നിയമമില്ലാതെ വിവർത്തനം ചേർത്താൽ കേർണൽ ഒരു ഘട്ടം കഴിഞ്ഞ് പാക്കറ്റ് ഉപേക്ഷിക്കുന്നു.

അതിനാൽ ക്ലയന്റിനെയല്ല, മൂന്ന് പാളികളെ പരിശോധിക്കുക, ഫലത്തിന് അർത്ഥമുണ്ടാകാൻ ഒരു സമയത്ത് ഒന്ന് മാത്രം മാറ്റുക.

ഫോർവേഡിംഗ് ശാശ്വതമാക്കേണ്ട കേർണൽ സ്വിച്ചാണ്

മാറ്റുന്നതിന് മുമ്പ് നിലവിലെ മൂല്യം പരിശോധിക്കുക, പിന്നീട് അത് സെറ്റ് ചെയ്ത് മാറ്റം പ്രാബല്യത്തിൽ വന്നുവെന്ന് ഉറപ്പാക്കുക.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

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

/etc/sysctl.d/ യുടെ കീഴിലുള്ള ഒരു ഫയലിൽ ഇത് ശാശ്വതമാക്കുക, പിന്നീട് അറിയാൻ റീബൂട്ട് ചെയ്യുന്നതിനുപകരം ആ ഫയൽ പ്രയോഗിക്കുക. FreeBSD-യിൽ തത്തുല്യമായത് net.inet.ip.forwarding ആണ്, ശാശ്വതതയ്ക്ക് rc.conf-ൽ gateway_enable=YES. ഫോർവേഡിംഗ് ഓഫാണെന്ന് റിപ്പോർട്ട് ചെയ്യുന്ന ഉപകരണം «പാക്കറ്റുകൾ വരുന്നു, ഒന്നും തിരിച്ചുവരുന്നില്ല» എന്ന വിഭാഗത്തിലെ റിപ്പോർട്ടുകൾ മുഴുവൻ വിശദീകരിക്കുന്നു. ഓരോ അപ്ഗ്രേഡിന് ശേഷവും ക്രമീകരണം പരിശോധിക്കുക, കാരണം പുനർനിർമ്മിച്ച കേർണലോ മാറ്റിയ ഉപകരണ ഇമേജോ ആരോടും പറയാതെ അത് പുനഃസജ്ജമാക്കാം.

masquerade അല്ലെങ്കിൽ ഒരു സ്ഥിര വിവർത്തന വിലാസം തിരഞ്ഞെടുക്കുക

ചലനാത്മക പുറം വിലാസത്തോടെ masquerading ആണ് ഏറ്റവും ലളിതമായ ശരിയായ രൂപം. ടണൽ സബ്നെറ്റിനെ ഉറവിടമായും പുറം ഇന്റർഫേസിനെ പുറത്തുകടക്കലായും വിളിക്കുക.

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

സ്ഥിര പൊതു വിലാസത്തോടെ, ഉറവിടം കൃത്യമായി ആ വിലാസത്തിലേക്ക് വിവർത്തനം ചെയ്യുന്നത് കൂടുതൽ പ്രവചനാതീതവും പരിശോധിക്കാൻ എളുപ്പവുമാണ്.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

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

ഫിൽട്ടർ പട്ടിക മൂന്നാം കവാടമാണ്

ഫോർവേഡിംഗും വിവർത്തനവും രണ്ടും ശരിയായിരിക്കെ പാക്കറ്റ് ഫിൽട്ടർ പട്ടികയിൽ മരിക്കാം. ufw പലപ്പോഴും കുറ്റക്കാരനാണ്: അതിന്റെ ഫോർവേഡ് നയം DROP ആയി വരുന്നു, ബാക്കി ക്രമീകരണം തികച്ചും ശരിയായി തോന്നാം, ആ ഒരു ക്രമീകരണം ട്രാഫിക് കൊല്ലുമ്പോൾ. അത് ഉയർത്തുന്നത് ചെക്ക്ബോക്സല്ല, ബോധപൂർവമായ സുരക്ഷാ തീരുമാനമാണ്.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ആദ്യ നിയമം ടണലിൽ നിന്ന് പുറത്തേക്കുള്ള പുതിയ ട്രാഫിക്ക് അനുവാദം നൽകുന്നു, രണ്ടാമത്തേത് ഉത്തരങ്ങൾക്ക് മാത്രം തിരിച്ചുവരാൻ. രണ്ടും ടണൽ സബ്നെറ്റിലേക്കും ഉദ്ദേശിച്ച ലക്ഷ്യസ്ഥാനത്തേക്കും ചുരുക്കുക, കാരണം ടണൽ ഇന്റർഫേസിലെ സാർവത്രിക അനുമതി ഓതന്റിക്കേറ്റ് ചെയ്യാൻ കഴിയുന്ന ആർക്കും VPN-നെ തുറന്ന പുറത്തുകടക്കൽ കേന്ദ്രമാക്കി മാറ്റുന്നു.

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

പേജ് ഒരിക്കലും ലോഡ് ചെയ്യാത്തപ്പോൾ എവിടെ നോക്കണം

ടണൽ ഉണ്ടെന്ന് തെളിയിക്കാൻ സർവറിന്റെ ടണൽ വിലാസത്തിലേക്ക് ping ചെയ്യുക. പിന്നീട് ക്ലയന്റിൽ നിന്ന് പൊതു വിലാസത്തിലേക്ക് traceroute ഓടിച്ച് എവിടെ നിൽക്കുന്നുവെന്ന് വായിക്കുക: സർവറിൽ പാക്കറ്റ് എത്തുന്നു, പക്ഷേ ഫോർവേഡ് ചെയ്യുന്നില്ല, വിവർത്തനം ചെയ്യുന്നുമില്ല; സർവറിനപ്പുറം പ്രശ്നം മുകളിലാണ്, നിങ്ങളുടെ കൈയിലല്ല.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

ആദ്യ കമാൻഡ് ടണൽ ട്രാഫിക്കിനെ സർവറിലേക്കുതന്നെ എത്തിക്കുന്നുവെന്ന് തെളിയിക്കുന്നു, രണ്ടാമത്തേത് പാക്കറ്റ് പുറത്തേക്ക് എത്ര ദൂരം എത്തുന്നുവെന്ന് കാണിക്കുന്നു. ടണൽ വിലാസത്തിൽ അവസാനിക്കുന്ന ട്രെയ്സ് സർവറിലെ ഫോർവേഡിംഗിനെയോ വിവർത്തനത്തെയോ സൂചിപ്പിക്കുന്നു, ഒരു ഹോപ്പ് കഴിഞ്ഞ് നിൽക്കുന്ന ട്രെയ്സ് ദാതാവിനെയോ മുകൾ റൗട്ടറിന്റെ തിരിച്ചുവരവ് പാതയെയോ സൂചിപ്പിക്കുന്നു.

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

വിദൂര ക്ലയന്റുകൾക്ക് സർവറിന്റെ LAN-ലെ ഹോസ്റ്റുകളിലും എത്തണമെങ്കിൽ, LAN-ന് ടണൽ സബ്നെറ്റിലേക്ക് തിരിച്ചുവരവ് പാത വേണമെന്ന് ഓർക്കുക. ഇത് വിവർത്തനമല്ല, റൂട്ടിംഗ് ആണ്, ഇന്റർനെറ്റ് പാത ഒടുവിൽ പ്രവർത്തിച്ചശേഷം ഏറ്റവും കൂടുതൽ മറക്കപ്പെടുന്ന ഘട്ടം ഇതാണ്.