പോർട്ട് ഫോർവേഡിംഗ് vs VPN ആക്സസ്: പാക്കറ്റ് യഥാർത്ഥത്തിൽ എവിടെ പോകുന്നു

പോർട്ട് ഫോർവേഡിംഗ് ലക്ഷ്യം വീണ്ടും എഴുതി അവിടെ നിർത്തുന്നു; VPN ആദ്യം പാക്കറ്റ് പൊതിയുന്നു. ഓരോന്നും ഏത് പാളി മാറ്റുന്നു, HTTPS-ന് അതിന്റെ അർത്ഥം എന്ത് എന്ന് കാണുക.

രണ്ട് ഡിസൈനുകൾ, ഒരു HTTPS ആപ്ലിക്കേഷൻ, പാക്കറ്റ് ഓരോന്നിലും വ്യത്യസ്ത പാതയിലൂടെ പോകുന്നു. പോർട്ട് ഫോർവേഡിംഗ് പാക്കറ്റ് എവിടെ എത്തിക്കണം എന്ന് മാറ്റുകയും ബാക്കി അതേപടി വിടുകയും ചെയ്യുന്നു. VPN ആദ്യം ആ പാക്കറ്റ് മറ്റൊരു പാക്കറ്റിനുള്ളിൽ കൊണ്ടുപോകുന്നു, അതിനാൽ ആപ്ലിക്കേഷന്റെ ലിസണർ വ്യത്യസ്ത ഉറവിടവും ചെറിയ പരമാവധി പേലോഡും കാണുന്നു. ആളുകൾ ചർച്ച ചെയ്യുന്ന എൻക്രിപ്ഷൻ രണ്ട് സാഹചര്യങ്ങളിലും ഉണ്ട്, കാരണം ആപ്ലിക്കേഷൻ ഇപ്പോഴും HTTPS ആണ്; വ്യത്യാസം ആര് കണക്ഷൻ തുറക്കാം, ഇടയിലുള്ള നെറ്റ്വർക്ക് എന്ത് നിരീക്ഷിക്കാം എന്നതിലാണ്. ഈ വ്യത്യാസം മിക്ക പ്രായോഗിക ചോദ്യങ്ങളും തീർക്കുന്നു.

DNAT നിയമം ലക്ഷ്യം വീണ്ടും എഴുതി അവിടെ നിർത്തുന്നു

Linux ഗേറ്റ്വേയിൽ സേവനം പ്രസിദ്ധീകരിക്കുക എന്നാൽ nat ടേബിളിന്റെ PREROUTING ചെയിനിൽ ഒരു നിയമം, അല്ലെങ്കിൽ nftables-ൽ അതിന് തുല്യമായത്. നിയമം പൊതു വിലാസത്തോടും പോർട്ടിനോടും പൊരുത്തപ്പെട്ട്, തുടർന്ന് ലക്ഷ്യം ആപ്ലിക്കേഷന്റെ സ്വകാര്യ വിലാസത്തിലേക്ക് വീണ്ടും എഴുതുന്നു. ഉറവിട വിലാസം, ഉറവിട പോർട്ട്, പേലോഡ് എന്നിവ തൊടാതെ നിൽക്കുന്നു, conntrack മാപ്പിംഗ് രേഖപ്പെടുത്തുന്നു, അതിനാൽ മറുപടികൾ പുറത്തുപോകുമ്പോൾ വീണ്ടും എഴുതപ്പെടുന്നു. ഈ പെരുമാറ്റം RFC 3022-ൽ വിവരിച്ച പരമ്പരാഗത വിലാസ വിവർത്തന മാതൃകയാണ്.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

ആപ്ലിക്കേഷന്റെ ലിസണർ കണക്ഷൻ വിവർത്തനത്തിലൂടെ വന്നത് ഒരിക്കലും അറിയുന്നില്ല. ക്ലയന്റിന്റെ യഥാർത്ഥ ഉറവിട വിലാസം കാണുന്നു, ഇത് ആക്സസ് ലോഗുകൾക്കും വേഗതാ പരിധികൾക്കും ഉപകാരപ്രദമാണ്, conntrack മാപ്പിംഗ് തിരിച്ചിടുന്നതിനാൽ സ്വകാര്യ വിലാസത്തിന് മറുപടി നൽകുന്നു. ആ പാതയിൽ ഒന്നും ഡീക്രിപ്റ്റ് ചെയ്യുകയോ വീണ്ടും എൻക്രിപ്റ്റ് ചെയ്യുകയോ ചെയ്യുന്നില്ല: TLS ഇപ്പോഴും ക്ലയന്റും ആപ്ലിക്കേഷന്റെ സ്വന്തം സർട്ടിഫിക്കറ്റും തമ്മിൽ പ്രവർത്തിക്കുന്നു.

നിയമം പിന്നീട് നേരിടുന്ന പരാജയ മോഡുകളും നിർണ്ണയിക്കുന്നു. ഗേറ്റ്വേ ഫോർവേഡ് ചെയ്യുന്നുവെങ്കിലും ആപ്ലിക്കേഷൻ ഹോസ്റ്റിന് ക്ലയന്റിലേക്ക് തിരിച്ചുള്ള പാതയില്ലെങ്കിൽ, മറുപടികൾ തെറ്റായ ഉറവിടവുമായി പുറത്തുപോകുന്നു, ഹാൻഡ്ഷേക്ക് നിലയ്ക്കുന്നു. രണ്ടാമത്തെ നിയമം ആദ്യം പൊരുത്തപ്പെട്ടാൽ ക്രമം ഫലം നിർണ്ണയിക്കുന്നു, ഏത് നിയമം പാക്കറ്റ് എടുത്തു എന്ന് തെളിയിക്കുന്ന കൗണ്ടറുകൾ iptables -t nat -L -n -v കാണിക്കുന്നു.

ടണൽ ലിസണർ കാണുന്നതിന് മുമ്പ് പാക്കറ്റ് പൊതിയുന്നു

VPN ആപ്ലിക്കേഷൻ പ്രസിദ്ധീകരിക്കുന്നേയില്ല. ക്ലയന്റ് ഗേറ്റ്വേയുടെ പൊതു വിലാസത്തിലേക്ക് അഭിസംബോധന ചെയ്ത ബാഹ്യ പാക്കറ്റ് നിർമ്മിക്കുന്നു, അതിനുള്ളിൽ ആന്തരിക പാക്കറ്റ് എൻക്രിപ്റ്റ് ചെയ്യുന്നു, ഗേറ്റ്വേ ഡീക്രിപ്റ്റ് ചെയ്ത് ആന്തരിക പാക്കറ്റ് സ്വകാര്യ ലക്ഷ്യത്തിലേക്ക് റൂട്ട് ചെയ്യുന്നു. WireGuard-ൽ ബാഹ്യ ഗതാഗതം UDP ആണ്, സാധാരണയായി ഉയർന്ന പോർട്ടിൽ; OpenVPN TCP 443-ൽ ആകുമ്പോൾ പാത നിരീക്ഷിക്കുന്ന എന്തിനും ബാഹ്യ പാക്കറ്റ് TLS പോലെ തോന്നുന്നു.

ടണലിനുള്ളിൽ ആന്തരിക പാക്കറ്റ് സ്വകാര്യ വിലാസങ്ങൾ നിലനിർത്തുന്നു: ക്ലയന്റിന്റെ ടണൽ വിലാസം, ഉദാഹരണത്തിന് 10.8.0.6, ഒപ്പം 10.20.30.40-ലുള്ള ആപ്ലിക്കേഷൻ. അതിനാൽ ലിസണർ ടണൽ പൂളിൽ നിന്നുള്ള ഉറവിടം കാണുന്നു, ഓരോ ക്ലയന്റും ആ ഗേറ്റ്വേ അടുത്ത ഹോപ്പായി പങ്കിടുന്നു. VPN-ന്റെ പിന്നിലെ ആക്സസ് ലോഗുകൾ ഉപയോക്താവിന് പകരം ഗേറ്റ്വേ കാണിക്കുന്നത് കൃത്യമായി ഈ കാരണത്താലാണ്, ഗേറ്റ്വേ യഥാർത്ഥ ഉറവിടം സൂക്ഷിക്കുന്നില്ലെങ്കിൽ.

പൊതിയുന്നത് ഹെഡർ സ്ഥലം ചെലവാക്കുന്നു, കൃത്യമായി അളക്കാവുന്ന ഫലമുള്ള ഏക മെക്കാനിസം തലത്തിലുള്ള വ്യത്യാസം ഇതാണ്. ബാഹ്യ IP ഹെഡറും UDP-യും WireGuard-ന്റെ സ്വന്തം ഹെഡറും പാതയുടെ MTU-വിൽ നിന്ന് കഴിക്കുന്നു, അതിനാൽ വലിയ പാക്കറ്റുകൾ വിഭജിക്കണം അല്ലെങ്കിൽ ആന്തരിക TCP സ്റ്റാക്ക് അതിന്റെ MSS പരിമിതപ്പെടുത്തണം. ഫോർവേഡ് ചെയ്ത പാതയിൽ പ്രവർത്തിക്കുന്ന കൈമാറ്റം, ഇടയിലുള്ള ഉപകരണം ചെറിയ MTU അറിയിക്കുന്ന ICMP ഉപേക്ഷിച്ചാൽ ടണലിൽ നിലയ്ക്കാം.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

എക്സ്പോഷർ പ്രവേശന കവാടത്തിൽ തീരുമാനിക്കുന്നു, സൈഫറിൽ അല്ല

രണ്ട് ഡിസൈനുകളും ഒരേ TLS ലിസണറിൽ അവസാനിക്കുന്നു, അതിനാൽ രണ്ടും ഒരേ സർട്ടിഫിക്കറ്റ്, ഒരേ പ്രോട്ടോക്കോൾ പതിപ്പുകൾ, ഒരേ ആപ്ലിക്കേഷൻ ലോഗിൻ എന്നിവ പാരമ്പര്യമായി സ്വീകരിക്കുന്നു. മാറുന്നത് ആർക്ക് ഹാൻഡ്ഷേക്ക് ആരംഭിക്കാം എന്നതാണ്. പൊതു ഫോർവേഡിൽ, 203.0.113.10:443 ലഭിക്കുന്ന ഏത് ഹോസ്റ്റും നിങ്ങളുടെ ആപ്ലിക്കേഷൻ അധികാരം പരിശോധിക്കുന്നതിന് മുമ്പ് തന്നെ TCP ഹാൻഡ്ഷേക്കും TLS ClientHello-ഉം നേടുന്നു. ടണൽ വഴി മാത്രമുള്ള ആക്സസിൽ, ഗേറ്റ്വേ ടണലിലേക്ക് റൂട്ട് ചെയ്യുന്ന വിലാസങ്ങളിൽ നിന്ന് മാത്രമേ ലിസണറിൽ എത്താനാകൂ, അപരിചിതന്റെ SYN ഗേറ്റ്വേ നയത്തിൽ മരിക്കുന്നു.

ഈ വ്യത്യാസം ലഭ്യതയെക്കുറിച്ചാണ്, രഹസ്യതയെക്കുറിച്ചല്ല. ഫോർവേഡ് ചെയ്ത HTTPS സേവനം പ്ലെയിൻ ടെക്സ്റ്റല്ല, VPN ആപ്ലിക്കേഷൻ പ്രാമാണീകരണത്തിന്റെ ആവശ്യകത ഒഴിവാക്കുന്നുമില്ല: ടണലിലേക്കുള്ള പ്രവേശനം ഈ നെറ്റ്വർക്കിലേക്ക് ഉപകരണത്തിന് പാക്കറ്റ് അയക്കാമോ എന്ന് ഉത്തരം നൽകുന്നു, ഫയൽ ആപ്ലിക്കേഷൻ ഉപയോക്താവിന് രേഖ വായിക്കാമോ എന്നും. രണ്ടും കൂട്ടിക്കലർത്തുന്നതാണ് ടീമുകൾ മുഴുവൻ LAN നൽകുന്ന VPN-ഉം ഒരു പങ്കിട്ട പാസ്വേഡുള്ള ആപ്ലിക്കേഷനും കൊണ്ട് അവസാനിക്കുന്നത്.

ലിസണറും നയവും വെവ്വേറെ പരിശോധിക്കുക, കാരണം ഇവയിൽ ഏതും നിങ്ങൾ കരുതുന്നതിലും വിശാലമായിരിക്കാം:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

ss ലിസണർ 0.0.0.0-ലേക്ക് ബന്ധിപ്പിച്ചിരിക്കുന്നു എന്ന് കാണിച്ചാൽ, റൂട്ടിംഗും ഫയർവാൾ നയവും അനുവദിക്കുന്ന എവിടെ നിന്നും ആപ്ലിക്കേഷൻ ലഭ്യമാണ്, ഫോർവേഡ് പ്രവേശിക്കാനുള്ള ഒരു വഴി മാത്രം. സ്വകാര്യ വിലാസത്തിലേക്ക് ബന്ധിപ്പിക്കുകയോ ഫയർവാളിൽ ഉറവിട ശ്രേണി പരിമിതപ്പെടുത്തുകയോ ചെയ്യുന്നത് VPN തിരഞ്ഞെടുക്കുന്നതിൽ നിന്ന് വേറിട്ട തീരുമാനമാണ്, എക്സ്പോഷർ യഥാർത്ഥത്തിൽ കുറയ്ക്കുന്നത് ആ തീരുമാനമാണ്.

പാത അളക്കുക, ലേബലല്ല

ഫോർവേഡ് വേഗതയേറിയതാണെന്ന് ആരെങ്കിലും അവകാശപ്പെടുമ്പോൾ, സത്യസന്ധമായ താരതമ്യം ബാക്കിയെല്ലാം സ്ഥിരമായി നിർത്തുന്നു: ഒരേ ക്ലയന്റ്, ഒരേ ആക്സസ് നെറ്റ്വർക്ക്, ഒരേ ഫയൽ, ഒരേ TLS കോൺഫിഗറേഷൻ, ഒരേ ആപ്ലിക്കേഷൻ ഹോസ്റ്റ്. ഓരോ പാതയിലും കൈമാറ്റം രണ്ടുതവണ പ്രവർത്തിപ്പിച്ച് ആകെ സമയം, പരാജയങ്ങളുടെ എണ്ണം, പ്രതികരണശേഷി എന്നിവ രേഖപ്പെടുത്തുക, അനുബന്ധമല്ലാത്ത വേഗതാ പരീക്ഷയുടെ ഔട്ട്പുട്ടല്ല.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

ഈ സംഖ്യകൾ കണക്ഷൻ സ്ഥാപിക്കലിനെ കൈമാറ്റ സമയത്തിൽ നിന്ന് വേർതിരിക്കുന്നു, ഇത് പ്രധാനമാണ് കാരണം രണ്ട് പാതകളും സാധാരണയായി സൈഫർ ചെലവിലല്ല, മറിച്ച് പോയി-വരവ് കാലതാമസത്തിലും MTU-വിലും വ്യത്യാസപ്പെടുന്നു. TLS ജോലി രണ്ട് ഡിസൈനുകളിലും അറ്റങ്ങളിൽ നടക്കുന്നു, ടണൽ എൻക്യാപ്സുലേഷൻ, വേറെ റൂട്ട്, ഒരുപക്ഷേ തിരക്കേറിയ ഗേറ്റ്വേ എന്നിവ ചേർക്കുന്നു. ടണൽ പാത നീളമുള്ളതാണെങ്കിലോ അതിന്റെ ഗേറ്റ്വേ ഭാരമുള്ളതാണെങ്കിലോ, വ്യത്യാസം പാതയുടേതാണ്, എൻക്രിപ്ഷൻ എന്ന വാക്കിന്റേതല്ല.

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

ഡിസൈൻ പൂർത്തിയായി പ്രഖ്യാപിക്കുന്നതിന് മുമ്പ് നാല് കാര്യങ്ങൾ സ്ഥിരീകരിക്കുക: ലിസണർ ഏത് വിലാസത്തിലേക്ക് ബന്ധിപ്പിച്ചിരിക്കുന്നു, ഏത് നിയമമോ റൂട്ടോ പാക്കറ്റ് അകത്തേക്ക് വിടുന്നു, ക്ലയന്റിന്റെ യഥാർത്ഥ വിലാസത്തിൽ നിന്ന് തിരിച്ചുള്ള പാത പ്രവർത്തിക്കുന്നുണ്ടോ, വലിയ പേലോഡുകൾ MTU കടക്കുന്നുണ്ടോ. ഇവയിൽ ഓരോന്നിനും മുകളിൽ ഒരു കമാൻഡ് ഉണ്ട്, ഏതിനും «സുരക്ഷിതം» എന്ന വാക്കോ ബാൻഡ്വിഡ്ത്ത് ചാർട്ടോ ഉത്തരം നൽകുന്നില്ല.

അനുബന്ധ ലേഖനങ്ങൾ