NAT-ന് പിന്നിലുള്ള OpenVPN ക്ലയന്റ് എങ്ങനെ ഇന്റർനെറ്റ് എക്സിറ്റ് ആകുന്നു
എക്സിറ്റ് സ്വയം പുറത്തേക്ക് വിളിക്കുന്നു, അതിനാൽ അതിന്റെ റൗട്ടറിന് ഇൻബൗണ്ട് പോർട്ട് ആവശ്യമില്ല. ഹബ് എന്ത് റൂട്ട് ചെയ്യുന്നു, എക്സിറ്റ് എന്ത് ഫോർവേഡ് ചെയ്യുന്നു, റിട്ടേൺ പാത എവിടെ നിന്ന് വരുന്നു എന്ന് പിന്തുടരുക.
മൂന്ന് Linux ഹോസ്റ്റുകൾ, ഒരു ഡിസൈൻ: പൊതുവെ ലഭ്യമായ OpenVPN ഹബ്, ഒരു ലാപ്ടോപ്പ്, അകത്തേക്ക് ഒന്നും ഫോർവേഡ് ചെയ്യാത്ത സാധാരണ ഹോം റൗട്ടറിന് പിന്നിലുള്ള ഒരു എക്സിറ്റ് മെഷീൻ. എക്സിറ്റ് തന്നെ ഹബ്ബിനെ വിളിക്കുന്നു. പിന്നീട് ഉപഭോക്താവിന്റെ ഇന്റർനെറ്റ് ട്രാഫിക് ലാപ്ടോപ്പിൽ ടണലിൽ കയറി എക്സിറ്റിന്റെ സ്വന്തം അപ്ലിങ്ക് വഴി പുറത്തു പോകുന്നു. ഈ ക്രമീകരണത്തിലെ എല്ലാ അത്ഭുതവും ഒരു വിശദാംശത്തിൽ നിന്നാണ്: ബന്ധം തുടങ്ങിയത് എക്സിറ്റ് ആണ്, അതിനാൽ അകത്തേക്കുള്ള വഴി ഇതിനകം ഉണ്ട്, അത് സൃഷ്ടിക്കാൻ പോർട്ട് ഫോർവേഡിംഗ് ആവശ്യമില്ല.
താഴെ പറയുന്നത് കോൺഫിഗറേഷന്റെ ക്രമമല്ല, പാക്കറ്റിന്റെ വഴിയാണ് പിന്തുടരുന്നത്, കാരണം ഏത് ഘടകം ഏത് തീരുമാനം എടുക്കുന്നു എന്ന് അറിഞ്ഞാൽ മാത്രമേ കോൺഫിഗറേഷന് അർത്ഥമുള്ളൂ. ഓരോ പാളിയും കൃത്യം ഒരു തീരുമാനം എടുക്കുന്നു, തെറ്റുകൾ രണ്ട് പാളികളെ ഒന്നായി കണക്കാക്കുന്നിടത്ത് കൂടുന്നു.
രണ്ട് ട്രാൻസ്പോർട്ട് സെഷനുകൾ, ഒരു ആന്തരിക വഴി
ഓരോ ഹോസ്റ്റും ഹബ്ബിലേക്ക് സ്വന്തം ബാഹ്യ ബന്ധം സൂക്ഷിക്കുന്നു, അവയിൽ ഒന്നും മറ്റൊന്നിനെ അറിയുന്നില്ല. ഉപഭോക്താവിന്റെ ഇന്റർനെറ്റിലേക്കുള്ള ട്രാഫിക് ഒരു പ്രത്യേക ആന്തരിക പ്രവാഹമാണ്, അത് ഉപഭോക്താവിന്റെ ടണലിൽ കൊണ്ടുപോയി പിന്നീട് എക്സിറ്റിന്റെ ടണലിൽ നിന്ന് വീണ്ടും പുറത്തു വിടുന്നു. ഹബ് റൂട്ട് ചെയ്യേണ്ടത് ഈ ആന്തരിക പ്രവാഹമാണ്, എക്സിറ്റ് ഫോർവേഡ് ചെയ്യേണ്ടതും അതു തന്നെ.
outer: consumer --TLS--> hub
outer: exit --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink
രണ്ട് ബാഹ്യ ബന്ധങ്ങളും ക്ലയന്റ് ഭാഗത്തു നിന്ന് പുറത്തേക്ക് പോകുന്നതിനാൽ, എക്സിറ്റിന്റെ റൗട്ടർ ഒരിക്കലും ഇൻബൗണ്ട് SYN കാണുന്നില്ല, ഒരിക്കലും ഡെസ്റ്റിനേഷൻ NAT നിയമം ആവശ്യപ്പെടുന്നില്ല. സ്ഥാപിത ട്രാൻസ്പോർട്ട് ജീവനോടെ നിലനിർത്തിയാൽ മതി, ഏത് ദീർഘകാല ബന്ധത്തിനും അത് ഇതിനകം ചെയ്യുന്നു. പൊതു ഇന്റർനെറ്റിലെ ഒന്നും ആദ്യം എക്സിറ്റിൽ എത്തേണ്ടതില്ല, അതിനാൽ ആ അപ്ലിങ്കിലെ ഡൈനാമിക് വിലാസം പ്രശ്നമല്ല. റൗട്ടർ ഇപ്പോഴും ഔട്ട്ബൗണ്ട് സെഷൻ അനുവദിക്കണം, പക്ഷേ അത് ബ്രൗസർ ഇതിനകം ഉപയോഗിക്കുന്ന അനുമതി തന്നെ.
iroute സർവറിനുള്ളിൽ യഥാർത്ഥത്തിൽ എന്ത് ഇൻസ്റ്റാൾ ചെയ്യുന്നു
ഏത് പിയർ ഏത് ലക്ഷ്യത്തിന്റെ ഉടമയാണ് എന്ന് തീരുമാനിക്കുന്ന ഏക ഉപകരണം ഹബ് ആണ്, ആ തീരുമാനം അത് കെർണലിലല്ല, സ്വന്തം യൂസർസ്പേസ് റൂട്ടിംഗ് പട്ടികയിൽ എടുക്കുന്നു. എക്സിറ്റിനുള്ള exit-node എന്ന client-config-dir എൻട്രിക്ക് അവിടെ ഡിഫോൾട്ട് പ്രിഫിക്സ് ആവശ്യപ്പെടാം:
# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0
ആ വരി സർവർ പ്രോസസ്സിനോട് "ഏത് ലക്ഷ്യമുള്ള ആന്തരിക പാക്കറ്റുകളും ഈ ക്ലയന്റിന്റേതാണ്" എന്ന് പറയുന്നു. അത് ഹബ്ബിന്റെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിലേക്ക് ഡിഫോൾട്ട് റൂട്ട് ചേർക്കുന്നില്ല, ഹബ്ബിനെ ഇന്റർനെറ്റ് ഗേറ്റ്വേ ആക്കുന്നുമില്ല. OpenVPN 2.6 റഫറൻസ് ക്ലയന്റിന് പ്രത്യേകമായ ആന്തരിക റൂട്ടിംഗും കെർണൽ റൂട്ടിംഗും വെവ്വേറെ സംവിധാനങ്ങളായി സൂക്ഷിക്കുന്നു, ഈ വേർതിരിവാണ് ഹബ്ബിന്റെ ഡിഫോൾട്ട് റൂട്ട് തൊടാതെ ഈ ഡിസൈൻ പ്രവർത്തിക്കാനുള്ള കാരണം.
ഉപഭോക്താവിന് കണ്ണാടി നിർദ്ദേശം വേണം, push ആയി എത്തിക്കുന്നത്, അതുവഴി അവരുടെ സ്വന്തം ട്രാഫിക് പ്രാദേശിക ഗേറ്റ്വേ വഴി പുറത്തു പോകുന്നതിനു പകരം ടണലിൽ പ്രവേശിക്കും. സബ്നെറ്റ് ടോപ്പോളജിയിൽ പൂൾ എക്സിറ്റിന്റെ tun ഉപകരണത്തിലെ ബന്ധിപ്പിച്ച റൂട്ടാണ്, അതിനാൽ തിരിച്ചു പോക്കിന് അധിക push വേണ്ട; എക്സിറ്റ് സ്വീകരിക്കാൻ പാടില്ലാത്തത് താഴെയുള്ള റീഡയറക്ട് ആണ്, അത് അതിന്റെ അപ്ലിങ്ക് ട്രാഫിക് ഉപയോഗിക്കാൻ ശ്രമിക്കുന്ന ടണലിലേക്ക് തിരികെ അയക്കും. അത് ഉപഭോക്താവിന് മാത്രം അയക്കുക, CCD ഫയൽ തിരഞ്ഞെടുത്തു എന്ന് വിശ്വസിക്കുന്നതിനു പകരം ക്ലയന്റിൽ പ്രയോഗിച്ച റൂട്ടുകൾ വായിക്കുക.
# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"
ഫോർവേഡിംഗ് ചെയ്യുന്നത് എക്സിറ്റിന്റെ കെർണൽ
എക്സിറ്റിനുള്ളിൽ ഉപഭോക്താവിൽ നിന്നുള്ള പാക്കറ്റ് tun ഇന്റർഫേസിൽ ഏതോ ഇന്റർനെറ്റ് ഹോസ്റ്റിനെ ലക്ഷ്യമാക്കി എത്തുന്നു. കെർണൽ തന്റെ റൂട്ടിംഗ് പട്ടിക പരിശോധിച്ച് ഏറ്റവും നല്ല പൊരുത്തമായി യഥാർത്ഥ അപ്ലിങ്ക് കണ്ടെത്തി, പിന്നീട് രണ്ട് സ്വതന്ത്ര നയങ്ങൾ പ്രയോഗിക്കുന്നു: ഈ പാക്കറ്റ് ഫോർവേഡ് ചെയ്യാമോ, ആ ഉറവിട വിലാസത്തോടെ ആ ഇന്റർഫേസിൽ നിന്ന് പുറത്തു പോകാമോ. ഫോർവേഡിംഗ് ഒരു sysctl ആണ്, പല വിതരണങ്ങളിലും സ്വതവേ ഓഫ് ആണ്.
അതിനാൽ എക്സിറ്റിന് സ്ഥിരമായി ഓണായ IPv4 ഫോർവേഡിംഗ്, ഉപഭോക്താവിന്റെ ടണൽ ഉറവിടങ്ങളെ അപ്ലിങ്കിലേക്ക് അനുവദിക്കുന്ന നിയമം, tun വഴി തിരികെ വരുന്ന മറുപടി പാത എന്നിവ വേണം. മുഴുവൻ ഹോസ്റ്റിനും ഫോർവേഡിംഗ് ഓണാക്കുന്നത് അതിലൂടെ റൂട്ട് ചെയ്യുന്ന മറ്റെല്ലാറ്റിന്റെയും പെരുമാറ്റം മാറ്റുന്നു, അതിനാൽ നിയമം എല്ലാം സ്വീകരിക്കുന്നതിനു പകരം ഉറവിടങ്ങളും ഇന്റർഫേസുകളും പേരിടണം.
തിരിച്ചു വരവിന്റെ വഴി വാങ്ങുന്നത് ഉറവിട വിവർത്തനം
ഇന്റർനെറ്റ് ഹോസ്റ്റിന് 10.90.0.x വിലാസത്തിലേക്ക് റൂട്ട് ഇല്ല, അതിനാൽ മറുപടികൾ എക്സിറ്റിൽ എത്തുന്നതിനു മുൻപേ ഉപേക്ഷിക്കപ്പെടും. പാക്കറ്റ് അപ്ലിങ്ക് വിട്ടുപോകുമ്പോൾ ഉറവിടം വീണ്ടും എഴുതുന്നത് അത് പരിഹരിക്കുന്നു, കണക്ഷൻ ട്രാക്കിംഗ് തിരികെ വരുമ്പോൾ ആ എഴുത്ത് പഴയപടിയാക്കുന്നു.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9 # run on the exit: must point at the tun
മുകളിലെ നിയമം ഒരു അപ്ലിങ്ക് ഇന്റർഫേസിനുള്ള തുടക്കമാണ്, ഫയർവാൾ നയമല്ല. ഉറവിടം യഥാർത്ഥത്തിൽ അനുവദിച്ച അനുവദനങ്ങളിലേക്ക് ചുരുക്കുക, എക്സിറ്റിന്റെ സ്വന്തം ഇൻപുട്ട് നയം വേർതിരിച്ചു സൂക്ഷിക്കുക, ടണൽ ട്രാഫിക്കിനുള്ള മാസ്കറേഡിംഗ് പ്രാദേശിക സേവനങ്ങളെ നിശബ്ദമായി വെളിപ്പെടുത്താതിരിക്കാൻ. ഡൈനാമിക് അപ്ലിങ്ക് വിലാസമുള്ള ഹോസ്റ്റിൽ മാസ്കറേഡ് വിലാസം കൈകൊണ്ട് ട്രാക്ക് ചെയ്യുന്നതിൽ നിന്നും രക്ഷിക്കുന്നു.
ഹബ് എവിടെ നടപ്പാക്കാം, എവിടെ പറ്റില്ല
client-to-client ഉം പരമ്പരാഗത യൂസർസ്പേസ് ഡാറ്റ പാതയും ഉപയോഗിച്ച് ഹബ് സർവർ പ്രോസസ്സിനുള്ളിൽ തന്നെ പിയറുകൾക്കിടയിൽ ആന്തരിക പാക്കറ്റുകൾ കൈമാറുന്നു. അവ ഒരിക്കലും ഹബ്ബിന്റെ കെർണൽ FORWARD ശൃംഖല കടക്കുന്നില്ല, അതിനാൽ അവിടെയുള്ള കെർണൽ നിയമത്തിന് എത്ര ശ്രദ്ധയോടെ എഴുതിയാലും പിയർ-ടു-പിയർ കടന്നുപോകൽ പരിമിതപ്പെടുത്താനാവില്ല. നടപ്പാക്കൽ സർവറിന്റെ സ്വന്തം നയത്തിൽ തന്നെ ജീവിക്കണം: ആർക്ക് കണക്ട് ചെയ്യാം, ഏത് CCD ഫയൽ ലഭിക്കുന്നു, എക്സിറ്റിന്റെ ഡിഫോൾട്ട് ഉടമസ്ഥത ഒട്ടും നൽകുന്നുണ്ടോ.
അതുകൊണ്ടാണ് ഡിഫോൾട്ട് iroute വിശാലമായ വിശ്വാസ തീരുമാനമാകുന്നത്. എക്സിറ്റ് അനിയന്ത്രിത ഇന്റർനെറ്റ് വിലാസങ്ങളിൽ നിന്നുള്ള തിരിച്ചുവരവ് ട്രാഫിക് നിയമപരമായി സ്വീകരിക്കണം, നിങ്ങൾ നിയന്ത്രിക്കുന്ന, പാച്ച് ചെയ്യുന്ന, നിരീക്ഷിക്കുന്ന യന്ത്രമായിരിക്കണം. അതേ ഉടമസ്ഥത നിങ്ങൾ റൗട്ടർ ഏൽപ്പിക്കാത്ത ഒരു പിയറിന് നൽകുന്നത് ഈ ഡിസൈൻ ക്ഷണിക്കുന്ന തെറ്റാണ്.
അംഗത്വമാണ് യഥാർത്ഥ നിയന്ത്രണം. സ്വന്തം റൂട്ടുകൾ കോൺഫിഗർ ചെയ്യാൻ കഴിയുന്ന ഏത് ക്ലയന്റും എക്സിറ്റ് ഉപയോഗിക്കാൻ ശ്രമിക്കാം, അതിനാൽ ആർക്ക് കണക്ട് ചെയ്യാം, എക്സിറ്റ് ഏത് പിയറുകൾക്ക് സേവനം നൽകും എന്ന് പരിമിതപ്പെടുത്തുന്നത് ഡിസൈന്റെ ഭാഗമാണ്, പിന്നീടുള്ള ചിന്തയല്ല.
എക്സിറ്റ് അപ്രത്യക്ഷമാകുമ്പോൾ സുരക്ഷിതമായി പരാജയപ്പെടുക
എക്സിറ്റ് ഓഫ്ലൈൻ ആക്കുക, ആന്തരിക ഡിഫോൾട്ട് ഉടമസ്ഥത അതിന്റെ സെഷനോടൊപ്പം അപ്രത്യക്ഷമാകും. സംഭവിക്കാൻ പാടില്ലാത്തത് ഹബ് നിശബ്ദമായി പകരം എക്സിറ്റ് ആകുന്നതാണ്: VPN പൂളിൽ നിന്ന് ഹബ്ബിന്റെ അപ്ലിങ്കിലേക്ക് ഡിഫോൾട്ട് റൂട്ട് ഇല്ല, ഹബ്ബിൽ അതേ ട്രാഫിക് സന്തോഷത്തോടെ ഫോർവേഡ് ചെയ്യുന്ന വിശാലമായ മാസ്കറേഡ് നിയമവുമില്ല. ആ പരാജയം ബോധപൂർവം പരീക്ഷിക്കുക, പിന്നീട് ഇതിനകം തുറന്ന പേജിനു പകരം പുതിയ പ്രവാഹത്തോടെ വീണ്ടെടുക്കൽ പരീക്ഷിക്കുക.
# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com
എക്സിറ്റ് പോയതിനു ശേഷവും ഉപഭോക്താവിന്റെ ട്രാഫിക് ഇന്റർനെറ്റിൽ എത്തുന്നുവെങ്കിൽ മറ്റെന്തോ അത് കൊണ്ടുപോകുന്നു, നിങ്ങൾ ഉദ്ദേശിച്ച അതിർത്തി നിലവിലില്ല. DNS, IPv6 എന്നിവയും വെവ്വേറെ തീരുമാനങ്ങളായി കാണുക: IPv4 റൂട്ടും മാസ്കറേഡും AAAA ട്രാഫിക്കിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ഹബ് തള്ളുന്ന റിസോൾവർ ചോദ്യം യഥാർത്ഥത്തിൽ പുറത്തു പോകുന്നിടത്തു നിന്ന് ഉത്തരം നൽകും.