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 ನಿಯಮಗಳು ಎಲ್ಲವೂ ಒಂದೇ ದಿಕ್ಕನ್ನು ತೋರಿಸಿದಾಗ; ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಬಿಟ್ಟರೆ ಖಾತೆ ಸೋರಿಕೆಯಾಗುತ್ತದೆ ಅಥವಾ ಸಂಪರ್ಕ ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.