nftables cgroup ബൈപാസിന് സോഴ്‌സ് വിലാസ പരിഹാരവും വേണം

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

മൂന്ന് തീരുമാനങ്ങൾ, ഒന്നല്ല

വർഗ്ഗീകരണം ആരാണ് ഒഴിവാക്കപ്പെട്ടത് എന്നതിന് ഉത്തരം നൽകുന്നു. റൂട്ടിംഗ് അടയാളപ്പെടുത്തിയ പാക്കറ്റ് പകരം എവിടെ പോകുന്നു എന്നതിന് ഉത്തരം നൽകുന്നു. സോഴ്സ് തിരഞ്ഞെടുപ്പ് ദൂരേയറ്റം എന്ത് കാണും, മറുപടി എവിടേക്ക് മടങ്ങണം എന്നതിന് ഉത്തരം നൽകുന്നു.

ഇവ സ്വതന്ത്രമായി പരാജയപ്പെടുന്നു. ഒരു പാക്കറ്റ് വർഗ്ഗീകരിക്കപ്പെട്ട്, ഭൗതിക ഇന്റർഫേസിലേക്ക് വീണ്ടും റൂട്ട് ചെയ്തിട്ടും, മുകൾനില റൂട്ടറിന് തിരികെ അയക്കാനാകാത്ത സ്വകാര്യ വിലാസം വഹിച്ചേക്കാം; അത് ഫയർവാൾ തടയലിനോട് കൃത്യമായി സാമ്യമുള്ള ടൈംഔട്ട് ഉണ്ടാക്കുന്നു. വർഗ്ഗീകരണ ഘട്ടത്തിൽ അതിനെപ്പറ്റി ഒന്നും മുന്നറിയിപ്പ് നൽകുന്നില്ല. റൂട്ടിംഗ് ഘട്ടത്തിലും ഒന്നുമില്ല.

ക്രമവും പ്രധാനമാണ്. പാക്കറ്റ് നിർമ്മിക്കുമ്പോൾ വർഗ്ഗീകരണം സംഭവിക്കുന്നു, അതിനുശേഷം റൂട്ടിംഗ്, പുറത്തുകടക്കുന്ന ബിന്ദുവിൽ വിവർത്തനം.

മൂന്ന് ഘട്ടങ്ങളിൽ ഏതാണ് കേടായതെന്ന് പറയാനാകുന്നില്ലെങ്കിൽ, നിങ്ങൾ ഡീബഗ് ചെയ്യുന്നില്ല, നിയമങ്ങൾ പുനഃക്രമീകരിച്ച് പ്രതീക്ഷിക്കുകയാണ്.

നാളെയും നിലനിൽക്കുന്ന cgroup-മായി പൊരുത്തപ്പെടുക

nftables-ന് സോക്കറ്റിന്റെ cgroup v2 അംഗത്വം പരിശോധിക്കാം; ഇത് യഥാർത്ഥത്തിൽ ഉപയോഗപ്രദമാണ്, കാരണം അത് ലക്ഷ്യസ്ഥാനത്തെയല്ല, പ്രക്രിയയെ പിന്തുടരുന്നു. കെണി ഐഡന്റിഫയറാണ്. മെനുവിൽ നിന്ന് തുടങ്ങുന്ന ഡെസ്ക്ടോപ്പ് ആപ്ലിക്കേഷൻ പലപ്പോഴും അടുത്ത തുടക്കത്തിൽ പേര് മാറുന്ന താൽക്കാലിക scope-ൽ കഴിയുന്നു.

nft list ruleset
systemctl status session.slice 2>/dev/null
cat /proc/self/cgroup

ഒരു സെഷനിൽ നിന്ന് scope പേര് പകർത്തി ഹാർഡ്‌കോഡ് ചെയ്യുന്നത് ഇന്ന് പ്രവർത്തിക്കുന്ന, നാളെ നിശബ്ദമായി പൊരുത്തപ്പെടാതാകുന്ന നിയമം ഉണ്ടാക്കുന്നു. പകരം ആപ്ലിക്കേഷനെ ബോധപൂർവമായ, സ്ഥിരമായ പ്രവർത്തന സന്ദർഭത്തിൽ ഇടുക, ഉദാഹരണത്തിന് നിങ്ങൾ നിയന്ത്രിക്കുന്ന സമർപ്പിത scope അല്ലെങ്കിൽ unit, അതുമായി പൊരുത്തപ്പെടുക. അപ്പോൾ നിയമം റീബൂട്ടുകളെയും പാക്കേജ് അപ്ഡേറ്റുകളെയും അതിജീവിക്കുന്നു. നിങ്ങളുടെ സെഷൻ ചരിത്രമില്ലാതെ സഹപ്രവർത്തകന് ഇതിനെക്കുറിച്ച് ചിന്തിക്കാനും കഴിയും.

ഏത് സംവിധാനമാണ് ഉപയോഗിക്കുന്നതെന്നും കൃത്യമായിരിക്കുക. cgroup v1-ന്റെ net_cls വർഗ്ഗീകരണവും cgroup v2-ന്റെ സോക്കറ്റ് പൊരുത്തവും വ്യത്യസ്ത കാര്യങ്ങളാണ്, ഡോക്യുമെന്റേഷനിൽ സമാനമായ പേരുള്ള ഫീൽഡ് അവയെ പരസ്പരം മാറ്റാവുന്നതാക്കുന്നില്ല.

രണ്ടാമത്തെ അന്വേഷണം ഉണ്ടാക്കുന്നത് route ചെയിനാണ്

പ്രാദേശികമായി നിർമ്മിക്കുന്ന ട്രാഫിക്കിന്, അടയാളം സജ്ജമാക്കിയതിന് ശേഷം എന്തെങ്കിലും സംഭവിക്കുമോ എന്ന് ചെയിൻ തരം തീരുമാനിക്കുന്നു. filter തരത്തിലുള്ള output ചെയിനിന് പാക്കറ്റ് അടയാളപ്പെടുത്താം, കർണൽ ഇതിനകം തിരഞ്ഞെടുത്ത റൂട്ട് തുടരും. route തരത്തിലുള്ള ചെയിനാണ് പുതിയ അന്വേഷണം ആവശ്യപ്പെടുന്ന സംവിധാനം.

table inet bypass {
  chain mark {
    type route hook output priority mangle; policy accept;
    socket cgroupv2 level 2 "app.slice" meta mark set 0x1 comment "app bypass"
  }
}
ip rule add fwmark 0x1 lookup 200
ip route add default via 203.0.113.1 dev wlan0 table 200

പിന്നീട് അടയാളത്തിന് അതിനെ പട്ടികയിലേക്ക് അയക്കുന്ന നയ നിയമം വേണം, ആ പട്ടിക സമ്പൂർണ്ണമായിരിക്കണം: ഡിഫോൾട്ട് റൂട്ട്, ആപ്ലിക്കേഷന് ഇനിയും വേണ്ട പ്രാദേശിക ലക്ഷ്യങ്ങൾ, യഥാർത്ഥത്തിൽ മറുപടി നൽകുന്ന മുകൾനില ഗേറ്റ്‌വേ.

അടയാള മൂല്യം ബോധപൂർവം തിരഞ്ഞെടുക്കുക. WireGuard പുറം ഗതാഗത ട്രാഫിക്കിന് സ്വന്തം fwmark ഉപയോഗിക്കുന്നു, ആകസ്മികമായി അതേ നമ്പറിൽ എത്തുന്നത് ടണലിന്റെ സ്വന്തം റൂട്ട് ഒഴിവാക്കലിനെ രോഗനിർണ്ണയം ബുദ്ധിമുട്ടുള്ള രീതിയിൽ തടസ്സപ്പെടുത്താം.

സോഴ്സ് വിലാസം റൂട്ടിനെ പിന്തുടരുന്നില്ല

ടണൽ പാതയ്ക്കായി ഇതിനകം സോഴ്സ് വിലാസം തിരഞ്ഞെടുത്ത സോക്കറ്റ്, വീണ്ടും റൂട്ട് ചെയ്തതിന് ശേഷവും ആ വിലാസം നിലനിർത്തുന്നു. റൂട്ട് മാറ്റത്തിൽ അത് വീണ്ടും എഴുതുന്ന ഒന്നുമില്ല, അതുകൊണ്ടാണ് മുകൾനില നെറ്റ്‌വർക്കിന് തിരികെ അയക്കാനാകാത്ത സ്വകാര്യ സോഴ്സുമായി പാക്കറ്റ് ഭൗതിക ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്നത്.

കാണാവുന്ന ലക്ഷണം, ഡാറ്റ അയക്കുന്നതായി തോന്നുകയും ഒരിക്കലും മറുപടി ലഭിക്കാതിരിക്കുകയും ചെയ്യുന്ന ആപ്ലിക്കേഷനും, പാക്കറ്റ് തിരികെ വരാത്തതിനാൽ ഒന്നും കാണിക്കാത്ത ഫയർവാൾ ലോഗും ആണ്.

ഇടുങ്ങിയ പരിഹാരം, ആ ആപ്ലിക്കേഷന്റെ അടയാളത്തിലും അതിന്റെ യഥാർത്ഥ ഔട്ട്പുട്ട് ഇന്റർഫേസിലും പരിമിതപ്പെടുത്തിയ, ഇതിനകം ഉള്ള NAT-മായി സംയോജിപ്പിച്ച, അതിനെ മാറ്റിസ്ഥാപിക്കാത്ത സോഴ്സ് വിവർത്തന നിയമമാണ്:

table inet bypass {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    meta mark 0x1 oifname "wlan0" masquerade
  }
}

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

ഇപ്പോഴും ഒഴിവാക്കലിൽ നിന്ന് രക്ഷപ്പെടുന്നത്

നാമ പരിഹാരം മറ്റൊരു cgroup-ലെ വേറിട്ട resolver പ്രക്രിയിൽ നിന്ന് വരാം, അതിനാൽ ബ്രൗസറിന്റെ സോക്കറ്റ് വർഗ്ഗീകരിച്ചാൽ അതിന്റെ അന്വേഷണങ്ങൾ വർഗ്ഗീകരിക്കപ്പെടുന്നില്ല. resolver-ന്റെ ചോദ്യങ്ങൾ ടണലിൽ തുടരുകയും ബന്ധം അതിന് പുറത്തേക്ക് പോകുകയും ചെയ്താൽ, split-horizon മറുപടികൾ പാതയുമായി പൊരുത്തപ്പെടാതിരിക്കാം. ആ പൊരുത്തക്കേട് DNS ബഗുകളെപ്പോലെ തോന്നുന്ന, എന്നാൽ അല്ലാത്ത തകരാറുകൾ ഉണ്ടാക്കുന്നു.

മിക്ക ക്രമീകരണങ്ങളിലും ചൈൽഡ് പ്രക്രിയകൾ cgroup പാരമ്പര്യമായി നേടുന്നു, എന്നാൽ തന്നെത്തന്നെ സ്വന്തം scope-ലേക്ക് മാറ്റുന്ന ഹെൽപ്പർ നേടുന്നില്ല. അനുമാനിക്കുന്നതിന് പകരം പരിശോധിക്കുക, പ്രത്യേകിച്ച് സ്വയം വീണ്ടും പ്രവർത്തിപ്പിക്കുന്ന എല്ലാത്തിനും.

അവസാനമായി, ടണൽ താഴെയിരിക്കുമ്പോൾ എന്ത് സംഭവിക്കണം എന്ന് തീരുമാനിക്കുക. നിശബ്ദമായി പൂർണ്ണ ബൈപാസ് ആകുന്ന ഒഴിവാക്കൽ, പരാജയത്തിൽ അടയുന്ന ഒഴിവാക്കലിൽ നിന്ന് വ്യത്യസ്തമായ സുരക്ഷാ നിലയാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് നിങ്ങൾ ഉദ്ദേശിച്ചത്.