UID നിയമങ്ങളുപയോഗിച്ച് ഒരു Linux ആപ്പ് VPN-ലേക്ക് ബന്ധിപ്പിക്കുന്നത്

Linux-ൽ ഒരു പ്രോഗ്രാം VPN-ലേക്ക് ബന്ധിപ്പിക്കുന്നത് പ്രധാനമായും ഒരു റൂട്ടിംഗ് പ്രശ്നമാണ്, ഫയർവാൾ നിയമം റൂട്ട് തിരഞ്ഞെടുത്തതിന് ശേഷം എന്ത് സംഭവിക്കുന്നു എന്ന് മാത്രം തീരുമാനിക്കുന്നു. ടണലിന് ഡിഫോൾട്ട് റൂട്ട് ലഭിക്കുന്നതിന് മുമ്പ് OUTPUT-ൽ പ്രോഗ്രാമിന്റെ UID പൊരുത്തപ്പെടുത്തിയാൽ, നിയമം നിങ്ങൾ സംരക്ഷിക്കാൻ ഉദ്ദേശിച്ച ട്രാഫിക്ക് തന്നെ ഉപേക്ഷിക്കുന്നു. അതേ നിയമം പ്രോഗ്രാമിന്റെ DNS ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്ന റെസോൾവർ പ്രോസസ്സിനെയും കാണുന്നില്ല. ക്രമം ശരിയാക്കിയാൽ, പ്രത്യേകാവകാശമില്ലാത്ത ഒരു അക്കൗണ്ട് വിശ്വസനീയമായ സ്പ്ലിറ്റ്-ടണൽ തിരഞ്ഞെടുക്കലായി മാറുന്നു.

വിധിക്ക് മുമ്പ് അക്കൗണ്ടിന് ഒരു റൂട്ട് നൽകുക

ഉടമസ്ഥ പൊരുത്തം ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ഈ UID-ൽ ഉള്ള പ്രാദേശിക സോക്കറ്റാണോ പാക്കറ്റ് നിർമ്മിച്ചത്? അത് ഇന്റർഫേസ് തിരഞ്ഞെടുക്കുന്നില്ല, പ്രധാന പട്ടിക ഇതിനകം ഭൗതിക NIC വഴി അയക്കുന്ന ട്രാഫിക്ക് നീക്കാനും കഴിയില്ല. അതിനാൽ പൊരുത്തമുള്ള റൂട്ടില്ലാത്ത UID നിയമം പ്രോഗ്രാമിനെ തിരിച്ചുവിടുന്നതിന് പകരം തടയുന്നു.

അക്കൗണ്ടിനെ ആദ്യം അതിന്റെ സ്വന്തം പട്ടികയിലൂടെ കടത്തിവിട്ട്, പിന്നീട് ഫയർവാൾ ഫലം സ്ഥിരീകരിക്കട്ടെ. iproute2 uidrange മനസ്സിലാക്കുന്ന ഹോസ്റ്റിൽ ഇത് പ്രവർത്തിക്കുന്നു, അത് ip rule help ഒരു വരിയിൽ റിപ്പോർട്ട് ചെയ്യുന്നു. പട്ടിക 100 ടണലിലൂടെയുള്ള ഡിഫോൾട്ട് റൂട്ട് സൂക്ഷിക്കുന്നു, നിയമം UID 1000 മാത്രം ആ പട്ടികയിലേക്ക് അയക്കുന്നു. ബാക്കിയെല്ലാം പ്രധാന പട്ടികയിൽ തുടരുകയും ഭൗതിക കണ്ണി ഉപയോഗിക്കുകയും ചെയ്യുന്നു.

ip rule add uidrange 1000-1000 table 100
ip route add default dev tun0 table 100

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

loopback ഒഴിവാക്കൽ ടണലിനെ കൊല്ലുന്നത് എന്തുകൊണ്ട്

പകർത്തിയ നിയമപതിപ്പുകളിൽ ഭൂരിഭാഗവും loopback വഴി പുറത്തുപോകാത്ത ഓരോ പാക്കറ്റും ഉപേക്ഷിക്കുന്നു. ടണൽ loopback അല്ല, അതിനാൽ ആ രൂപം ടണൽ ട്രാഫിക്കും ഉപേക്ഷിക്കുന്നു, ഫലം ഫയർവാൾ പിശകിന് പകരം മരിച്ച VPN പോലെ തോന്നുന്നു.

OUTPUT പ്രവർത്തിക്കുമ്പോൾ കെർണൽ ഇതിനകം പുറത്തുകടക്കുന്ന ഇന്റർഫേസ് തിരഞ്ഞെടുത്തിട്ടുണ്ട്, അതിനാൽ -o പാക്കറ്റ് തലക്കെട്ടിന് പകരം റൂട്ടിന്റെ ഉത്തരവുമായി താരതമ്യം ചെയ്യുന്നു. ഉടമസ്ഥ പൊരുത്തം OUTPUT-ലും POSTROUTING-ലും മാത്രം പരിഗണിക്കുന്നു, കൈമാറിയ പാക്കറ്റുകൾക്ക് അത് വായിക്കാൻ സോക്കറ്റില്ല. ഈ സംയോജനം അർത്ഥമാക്കുന്നത്, ഒഴിവാക്കൽ loopback നിഷേധിക്കുന്നതിന് പകരം ടണലിന്റെ ഇന്റർഫേസ് പേരിട്ട് ആ പൊരുത്തം നിഷേധിക്കണം എന്നാണ്.

loopback-ന് ഇപ്പോഴും DROP-ന് മുകളിൽ സ്വന്തം ACCEPT അർഹതയുണ്ട്, കാരണം പ്രോഗ്രാമിന്റെ ആദ്യ DNS പാക്കറ്റ് lo വഴി പ്രാദേശിക സ്റ്റബ്ബിലേക്ക് പോകുന്നു. രണ്ട് നിയമങ്ങളും ഈ ക്രമത്തിൽ വെക്കുക, അപ്പോൾ അക്കൗണ്ട് സ്റ്റബ്ബിൽ എത്തുന്നു, പിന്നീട് ടണലിൽ, മറ്റൊരിടത്തും ഇല്ല.

iptables -I OUTPUT 1 -o lo -m owner --uid-owner vpnapp -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner vpnapp ! -o tun0 -j DROP

IPv6 വേറിട്ട നിയമക്കൂട്ടമാണ്, v4-ന് മാത്രമുള്ള ജോടി ip6tables തൊടാതെ വിടുന്നു. AAAA റെക്കോർഡുകൾക്ക് മുൻഗണന നൽകുന്ന പ്രോഗ്രാം അപ്പോൾ DROP-ൽ ഒരിക്കലും എത്താതെ ഭൗതിക കണ്ണി വഴി പുറത്തുപോകും. രണ്ട് നിയമങ്ങളും ip6tables ൽ പ്രതിഫലിപ്പിക്കുക, അല്ലെങ്കിൽ ടണൽ v6 വിലാസം വഹിക്കാത്തപ്പോൾ ഹോസ്റ്റിൽ IPv6 പ്രവർത്തനരഹിതമാക്കുക. കൈകൊണ്ട് ചേർത്ത നിയമങ്ങളും റീബൂട്ടിൽ അപ്രത്യക്ഷമാകും, അതിനാൽ അവ netfilter-persistent save ഉപയോഗിച്ച് സംരക്ഷിക്കുക അല്ലെങ്കിൽ അതേ യുക്തി ബൂട്ട് യൂണിറ്റ് ലോഡ് ചെയ്യുന്ന nftables പട്ടികയായി വീണ്ടും നിർമ്മിക്കുക.

DNS ഉത്തരങ്ങൾ മറ്റൊരു പ്രോസസ്സിൽ നിന്ന് വരുന്നു

പ്രോഗ്രാമിന്റെ 127.0.0.53 ലേക്കുള്ള ചോദ്യം loopback ACCEPT കടക്കുന്നു, അവിടെ തന്നെ UID പൊരുത്തം നിലയ്ക്കുന്നു. സ്റ്റബ് റെസോൾവർ അതിന്റെ സേവന അക്കൗണ്ടിൽ നിന്ന് മുകളിലേക്ക് കൈമാറുന്നു, അതിനാൽ vpnapp ലേക്ക് ബന്ധിപ്പിച്ച നിയമം രണ്ടാമത്തെ ചോദ്യം ഒരിക്കലും കാണുന്നില്ല. റെസോൾവർ കണ്ണിക്ക് LAN സെർവർ തിരഞ്ഞെടുത്താൽ, ഉത്തരങ്ങൾ ഭൗതിക NIC വഴി തിരികെ വരുന്നു, പ്രോഗ്രാമിന്റെ സ്വന്തം പാക്കറ്റുകൾ ടണലിൽ തുടരുന്നു. കാണാവുന്ന ഫലം തകർന്ന പേരുകളുമായി പ്രവർത്തിക്കുന്ന ടണൽ, അല്ലെങ്കിൽ നിങ്ങൾ തിരഞ്ഞെടുക്കാത്ത സെർവർ ഉത്തരം നൽകുന്ന പേരുകൾ.

പേര് നിർണ്ണയം അപ്ലിക്കേഷനിൽ അല്ല, ടണൽ കണ്ണിയിൽ തിരുത്തുക. ടണൽ പ്രൊഫൈലിന് DNS സെർവറും റൂട്ടിംഗ് ഡൊമെയ്നും നൽകി, പിന്നീട് resolvectl query ഉം resolvectl status tun0 ഉം ഉപയോഗിച്ച് പ്രധാന പേരുകൾക്ക് റെസോൾവർ അത് ഉപയോഗിക്കുന്നു എന്ന് സ്ഥിരീകരിക്കുക. നെറ്റ്വർക്ക് നാമസ്ഥലത്തിനുള്ളിൽ പ്രശ്നം അപ്രത്യക്ഷമാകുന്നു, കാരണം സ്ഥലത്തിന്റെ റെസോൾവർ ടണൽ മാത്രം അറിയുന്നു.

അക്കൗണ്ടിൽ നിന്ന് തന്നെ നിയമം പരിശോധിക്കുക

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

ip route get 1.1.1.1 uid 1000
sudo -u vpnapp curl -s https://ifconfig.co

കൗണ്ടറുകൾ ഒരു നിയമം എപ്പോഴെങ്കിലും പ്രവർത്തിച്ചോ എന്ന് കാണിക്കുന്നു. iptables -vnL OUTPUT പ്രവർത്തിപ്പിച്ച്, ഓരോ നിയമത്തിനും അടുത്തുള്ള പാക്കറ്റ് എണ്ണം വായിച്ച്, യഥാർത്ഥ ട്രാഫിക്കിന് ശേഷം DROP-ന് അടുത്തുള്ള പൂജ്യം പൊരുത്ത പിശകായി കണക്കാക്കുക.

കൈമാറുന്ന ട്രാഫിക് ഈ രൂപകൽപ്പനയ്ക്ക് പുറത്താണ്. പാലത്തിന് പിന്നിലുള്ള കണ്ടെയ്നറിനോ VM-നോ vpnapp ന്റെ ഉടമസ്ഥതയിലുള്ള പ്രാദേശിക സോക്കറ്റില്ല, അതിനാൽ ഉടമസ്ഥ പൊരുത്തം ഒരിക്കലും പ്രവർത്തിക്കുന്നില്ല, ആ പാക്കറ്റുകൾ പകരം FORWARD നയം പിന്തുടരുന്നു. ആ ജോലിഭാരം ഉൾക്കൊള്ളേണ്ടതുണ്ടെങ്കിൽ, അത് വേർതിരിച്ച് പരിശോധിച്ച് പാലത്തിനോ കണ്ടെയ്നർ വിലാസത്തിനോ ബന്ധിപ്പിച്ച നയം എഴുതുക. പട്ടിക, ഇന്റർഫേസ് ഒഴിവാക്കൽ, റെസോൾവർ, v6 നിയമങ്ങൾ എല്ലാം ഒരേ ദിശയിലേക്ക് ചൂണ്ടുമ്പോൾ മാത്രമേ രൂപകൽപ്പന നിലനിൽക്കൂ; അവയിലൊന്ന് ഒഴിവാക്കിയാൽ അക്കൗണ്ട് ചോരുകയോ ബന്ധം നഷ്ടപ്പെടുകയോ ചെയ്യും.