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‌ಗೆ ಸ್ಥಳಾಂತರಿಸುವ ಸಹಾಯಕ ಪಡೆಯುವುದಿಲ್ಲ. ಊಹಿಸುವ ಬದಲು ಪರಿಶೀಲಿಸಿ, ಅದರಲ್ಲೂ ತನ್ನನ್ನು ಮರು-ನಿರ್ವಹಿಸುವ ಎಲ್ಲದಕ್ಕೂ.

ಕೊನೆಯದಾಗಿ, ಸುರಂಗ ಕೆಳಗಿರುವಾಗ ಏನಾಗಬೇಕೆಂದು ನಿರ್ಧರಿಸಿ. ಮೌನವಾಗಿ ಪೂರ್ಣ ಬೈಪಾಸ್ ಆಗುವ ವಿನಾಯಿತಿ, ವಿಫಲವಾದಾಗ ಮುಚ್ಚಿಕೊಳ್ಳುವ ವಿನಾಯಿತಿಗಿಂತ ಬೇರೆ ಭದ್ರತಾ ಭಂಗಿ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ನೀವು ಉದ್ದೇಶಿಸಿದ್ದು.