Linux ನಲ್ಲಿ Transmission: ಪ್ರಕ್ರಿಯೆಯ ಮಾಲೀಕರ ಪ್ರಕಾರ ಹೊರಹೋಗುವ ಟ್ರಾಫಿಕ್ ಜಾರಿಗೊಳಿಸಿ
ಪೀರ್ ಪೋರ್ಟ್ ಇಡೀ ಕಥೆಯಲ್ಲ. ಫೈರ್‌ವಾಲ್ ನಿಯಮವನ್ನು ಕ್ಲೈಂಟ್ ಖಾತೆಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳನ್ನು ಒಳಗೊಳ್ಳಿ ಮತ್ತು ಸುರಂಗ ಕೆಳಗಿರುವಾಗ ಪರೀಕ್ಷಿಸಿ.
Transmission ನ ಒಳಬರುವ ಪೋರ್ಟ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸುವುದು VPN ನೀತಿ ಅಲ್ಲ. ಟೊರೆಂಟ್ ಕ್ಲೈಂಟ್ ಪೀರ್‌ಗಳು ಮತ್ತು ಟ್ರ್ಯಾಕರ್‌ಗಳ ಕಡೆಗೆ ಹೊರಹೋಗುವ ಸಂಪರ್ಕಗಳನ್ನು ತೆರೆಯುತ್ತದೆ, ಹೆಸರುಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು ದೂರದ ನಿಯಂತ್ರಣಕ್ಕಾಗಿ ಶ್ರೋತೆಯನ್ನು ಒಡ್ಡಬಹುದು, ಮತ್ತು ಇವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ನೀವು ಉದ್ದೇಶಿಸದ ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ಹೊರಹೋಗಬಹುದು. ಐದು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ಗಡಿಯಾಗಿ ಫೈರ್‌ವಾಲ್ ನಿಯಮವನ್ನು, ಕ್ಲೈಂಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಅಲ್ಲ, ಪರಿಗಣಿಸಿ. ಕೊನೆಯ ಎರಡು ಪರಿಶೀಲನೆಗಳೇ ಜನರು ಬಿಟ್ಟುಬಿಡುವಂಥವು, ಮತ್ತು ಸುರಂಗ ಬಿದ್ದಾಗ ಖಾತರಿ ನಿಲ್ಲುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಅವೇ ನಿರ್ಧರಿಸುತ್ತವೆ.
ವರ್ಗಾವಣೆಯ ಮಾಲೀಕರಾದ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೆಸರಿಸಿ
ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಸಿಸ್ಟಂ ಡೀಮನ್ ಬೇರೆ ಬೇರೆ ಖಾತೆಗಳ ಅಡಿಯಲ್ಲಿ ಚಲಿಸುತ್ತವೆ, ಮತ್ತು ಮಾಲೀಕ ಆಧಾರಿತ ನಿಯಮ ಕಾರ್ಯಕ್ರಮದ ಹೆಸರನ್ನು ಅಲ್ಲ, ಖಾತೆಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಯಾವುದೇ ನಿಯಮ ಬರೆಯುವ ಮೊದಲು ಇವುಗಳಲ್ಲಿ ಯಾವುದು ಚಲಿಸುತ್ತಿದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ. ಮೀಸಲಾದ ಸೇವಾ ಖಾತೆ ನೀತಿಗೆ ನಿಖರವಾದ ವಿಷಯವನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ಡೆಸ್ಕ್‌ಟಾಪ್ ಬಳಕೆದಾರ ತನ್ನ ಗುರುತನ್ನು ಬ್ರೌಸರ್‌ಗಳು, ಸಂಪಾದಕರು ಮತ್ತು ಅಧಿವೇಶನದ ಎಲ್ಲದರೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳುತ್ತಾರೆ. UID ಅನ್ನು ದೃಢೀಕರಿಸಿ, ಪ್ಯಾಕೇಜ್ ಖಾತೆ ಹೆಸರೇ ಬಳಸಲಾಗುತ್ತಿದೆ ಎಂದು ಊಹಿಸಬೇಡಿ.
systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemonಖಾತೆ ಇನ್ನೂ ಇಲ್ಲದಿದ್ದರೆ ಇದೇ ಉದ್ದೇಶಕ್ಕಾಗಿ ರಚಿಸಿ ಮತ್ತು ಅದನ್ನು ಚಲಾಯಿಸಲು ಬೇರೆ ಏನನ್ನೂ ನೀಡಬೇಡಿ. ಖಾತೆ ಮತ್ತು UID ಅನ್ನು ನಿಯಮದ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ವಿಷಯವಿಲ್ಲದ ನಿಯಮ ಯಾರೂ ಸುರಕ್ಷಿತವಾಗಿ ಸಂಪಾದಿಸಲಾಗದ ನಿಯಮ.
ಆಲಿಸುವ ಕ್ಷೇತ್ರಗಳನ್ನು ಮಾರ್ಗದಿಂದ ಬೇರ್ಪಡಿಸಿ
Transmission 4.x ಪೀರ್ ಆಲಿಸುವ ವಿಳಾಸಗಳನ್ನು rpc-bind-address ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ. RPC ಸೆಟ್ಟಿಂಗ್ ದೂರದ ನಿಯಂತ್ರಣ ಶ್ರೋತೆಯನ್ನು ಮಾತ್ರ ನಿಯಂತ್ರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಬದಲಿಸುವುದು ಪೀರ್ ಟ್ರಾಫಿಕ್‌ಗೆ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ. ಎರಡೂ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಒಂದಾಗಿ ಓದುವುದೇ ಎಚ್ಚರಿಕೆಯಿಂದ ಕಾಣುವ ಸಂರಚನೆಯೂ ಸೋರುವುದಕ್ಕೆ ಸಾಮಾನ್ಯ ಕಾರಣ. ಅದೇ ದಾಖಲೆ ಪೀರ್ ಆಲಿಸುವ ವಿಳಾಸ ಅಮಾನ್ಯವಾದಾಗ ಪರ್ಯಾಯ ಮಾರ್ಗವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಅಂದರೆ ಲಭ್ಯವಿಲ್ಲದ ವಿಳಾಸ ದಾಖಲಿತ ಪರ್ಯಾಯ ಸ್ಥಿತಿ, ಖಾತರಿಪಡಿಸಿದ ನಿರಾಕರಣೆ ಅಲ್ಲ.
grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.jsonಕ್ಲೈಂಟ್ ನಿಯಂತ್ರಣಗಳನ್ನು ಅವು ಏನೋ ಅದಕ್ಕೆ ಬಳಸಿ ಮತ್ತು ಖಾತರಿಯನ್ನು ಫೈರ್‌ವಾಲ್‌ನಲ್ಲಿ ಇರಿಸಿ. ಆಲಿಸುವ ಸೆಟ್ಟಿಂಗ್ ಇನ್ನೂ ಉಪಯುಕ್ತವಾಗಿರಬಹುದು, ಆದರೆ ಟ್ರ್ಯಾಕರ್ ಸಂಪರ್ಕ, ಸ್ಥಳೀಯ ಪತ್ತೆ ಅಥವಾ ನಿಯೋಜಿತ ಹುಡುಕಾಟ ಎಲ್ಲವೂ ಸುರಂಗದ ಮೂಲಕ ಹೊರಹೋಗುತ್ತವೆ ಎಂದು ಅದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಎರಡೂ ಭಿನ್ನಾಭಿಪ್ರಾಯ ಹೊಂದಿದಾಗ ಫೈರ್‌ವಾಲ್ ನಿರ್ಧರಿಸುತ್ತದೆ.
ಮಾಲೀಕ ಹೊಂದಾಣಿಕೆಯನ್ನು ಸರಿಯಾದ ಸರಪಳಿಯಲ್ಲಿ ಬರೆಯಿರಿ
ಮಾಲೀಕ ಹೊಂದಾಣಿಕೆ ಬಗ್ಗೆ Netfilter ಕೈಪಿಡಿ ಸ್ಥಳೀಯವಾಗಿ ರಚಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗಳು ಸಾಕೆಟ್ ಫೈಲ್ ಮಾಲೀಕರಾದ ಬಳಕೆದಾರ ಅಥವಾ ಗುಂಪಿಗೆ ಹೇಗೆ ಆರೋಪಿಸಲ್ಪಡುತ್ತವೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ. ಆ ಆರೋಪಣೆ ಮುಂದೆ ಕಳುಹಿಸಿದ ಟ್ರಾಫಿಕ್‌ಗೆ ವಿಸ್ತರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಹೆಚ್ಚುವರಿ ಗುಂಪುಗಳ ಹೊಂದಾಣಿಕೆಗೆ ಸ್ಪಷ್ಟ ಆಯ್ಕೆ ಬೇಕು. ನೀವು ನಿಜವಾಗಿ ಬಳಸುತ್ತಿರುವ ವಿಸ್ತರಣೆಯ ಕೈಪಿಡಿಯನ್ನು ಓದಿ, ಸಿಕ್ಕ ಮೊದಲ ಉದಾಹರಣೆಯಲ್ಲ.
iptables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner transmission -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
ip6tables -A OUTPUT -m owner --uid-owner transmission -j REJECTಕ್ರಮ ಹೊಂದಾಣಿಕೆಯಷ್ಟೇ ಮುಖ್ಯ. ಸರಪಳಿಯಲ್ಲಿ ಮೇಲಿನ ವಿಶಾಲ ಒಪ್ಪಿಗೆ ಕೆಳಗಿನ ನಿಖರ ನಿರಾಕರಣೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಯಮ ಸೇರಿಸಿ ನಿರೀಕ್ಷಿಸುವ ಬದಲು ಇಡೀ ಸರಪಳಿಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಹೋಸ್ಟ್ IPv6 ಚಲಾಯಿಸಿದರೆ ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳನ್ನು ಸೇರಿಸಿ, ಏಕೆಂದರೆ v4 ಮಾತ್ರ ನೀತಿ ಯಾರೂ ಗಮನಿಸದ ಮಾರ್ಗವನ್ನು ತೆರೆದಿಡುತ್ತದೆ. ನಿಯಮಗಳನ್ನು ಕ್ಲೈಂಟ್ ಮತ್ತು ಸುರಂಗದ ಮರುಪ್ರಾರಂಭಗಳಲ್ಲೂ ಸ್ಥಾಪಿತವಾಗಿ ಇರಿಸಿ.
tun0 ಮಾಯವಾದಾಗ ಏನಾಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿ
ವೈಫಲ್ಯ ನೀತಿಯೇ ಈ ಅಭ್ಯಾಸದ ಸಾರ. ಸುರಂಗ ಮಾಯವಾಗಿ ಅದೇ ಹುಕ್ ನಿಯಮಗಳನ್ನು ತೆಗೆದರೆ, ಬೇರೆ ಯಾವುದೋ ಅದನ್ನು ನಿಲ್ಲಿಸುವವರೆಗೆ ಕ್ಲೈಂಟ್ ಭೌತಿಕ ಇಂಟರ್‌ಫೇಸ್ ಬಳಸಲು ಸ್ವತಂತ್ರ. ಸುರಕ್ಷಿತ ವಿನ್ಯಾಸ ನಿಯಮಗಳನ್ನು ಉಳಿಸಿಕೊಂಡು ಅವು ನಿರಾಕರಿಸಲು ಅನುವು ಮಾಡುತ್ತದೆ, ಅದೇ ಗಡಿಯನ್ನು ಸುರಂಗದ ಆರೋಗ್ಯದಿಂದ ಸ್ವತಂತ್ರಗೊಳಿಸುತ್ತದೆ. ನಿಯಮಗಳನ್ನೂ ಅಳಿಸುವ ಹುಕ್ ವೈಫಲ್ಯ ನೀತಿಗೆ ನೇರ ವಿರುದ್ಧ.
ip link show tun0
iptables -S OUTPUTಅದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ: ಸುರಂಗ ನಿಲ್ಲಿಸಿ, ಬಿಟ್ಟುಬಿಡಲು ಸುರಕ್ಷಿತವಾದ ವರ್ಗಾವಣೆ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಏನಾದರೂ ಹೊರಹೋಗುತ್ತದೆಯೇ ನೋಡಿ. ನಂತರ ಸುರಂಗವನ್ನು ಮರಳಿ ತಂದು ಉದ್ದೇಶಿತ ಮಾರ್ಗ ಮತ್ತೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.
ನಿಯಮ ನೋಡಲಾಗದ ಮಾರ್ಗಗಳನ್ನು ಒಳಗೊಳ್ಳಿ
ಹೆಸರು ಪರಿಹಾರವನ್ನು ಪ್ರತ್ಯೇಕ ಪರಿಹಾರಕ ಪ್ರಕ್ರಿಯೆ ನಿರ್ವಹಿಸಬಹುದು, ಮತ್ತು ಹೆಸರಿನ ಸ್ಥಳ ಅಥವಾ ಮೀಸಲಾದ ಗೇಟ್‌ವೇ ಅವುಗಳ ಹಂಚಿಕೆ ಮತ್ತು ಬೂಟ್‌ಸ್ಟ್ರ್ಯಾಪ್ ಮಾರ್ಗಗಳು ಅದಕ್ಕಾಗಿ ವಿನ್ಯಾಸಗೊಂಡಿದ್ದರೆ ಇನ್ನೊಂದು ಗಡಿಯನ್ನು ನೀಡಬಹುದು. DNS ಯಾವ ಘಟಕದ ಮಾಲೀಕತ್ವ ಮತ್ತು ಅದು ಅದೇ ನಿರ್ಗಮ ನಿಯಮವನ್ನು ಅನುಸರಿಸುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ. ನಂತರ RPC ನೋಡಿ: rpc-whitelist ಬಳಕೆಯಲ್ಲಿದ್ದರೆ ಅನುಮೋದಿತ ನಿರ್ವಹಣಾ ಜಾಲ ಒಪ್ಪಂದದ ಭಾಗ, ಮತ್ತು ವಿಶಾಲ RFC1918 ಶ್ರೇಣಿ ಅಲ್ಲ.
ss -tunp | grep -i transmissionಇಂಟರ್‌ಫೇಸ್ ಕೌಂಟರ್‌ಗಳು ವೀಕ್ಷಣೆಗೆ ಬೆಂಬಲ ನೀಡಬಹುದು, ಆದರೆ ಯಾವ ಪ್ರಕ್ರಿಯೆ ಬೈಟ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸಿತು ಎಂದು ಸಾಬೀತುಪಡಿಸಲಾರವು. ಬಿಟ್ಟುಬಿಡಲು ಅನುಮತಿ ಇರುವ ವರ್ಗಾವಣೆ ಮಾಡಿ: ಮೊದಲು ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗದಲ್ಲಿ, ನಂತರ ಪ್ರಾರಂಭದಲ್ಲಿ ಸುರಂಗವಿಲ್ಲದೆ, ಆಮೇಲೆ ಅಡಚಣೆ, ಮರುಸಂಪರ್ಕ ಮತ್ತು ಹೊಸದಾಗಿ ರಚಿಸಿದ ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ. ಹೊಸ ಪ್ರಯತ್ನ ಮತ್ತು ಈಗಾಗಲೇ ತೆರೆದ ಸಂಪರ್ಕ ಎರಡನ್ನೂ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ನಿಯಮ ಹಳೆಯ ಸಾಕೆಟ್‌ಗೆ ಅನ್ವಯಿಸದೇ ಇರಬಹುದು. ದಿನಾಂಕ, ಖಾತೆ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ದಾಖಲಿಸಿ.
ಇಡೀ ಸರಪಳಿಯನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವ ಉದಾಹರಣೆ ಅಂಟಿಸುವುದು ಒಂದು ರಂಧ್ರದ ಬದಲು ಹಲವನ್ನು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಯಮಗಳನ್ನು ಅಳಿಸುವ ಬದಲು ಸೇರಿಸಿ. ಐದು ಪರಿಶೀಲನೆಗಳೂ ಉತ್ತೀರ್ಣವಾದಾಗ, ಖಾತರಿ ಸ್ಪಷ್ಟ: ಕ್ಲೈಂಟ್ ಟ್ರಾಫಿಕ್ ಸುರಂಗದ ಮೂಲಕ ಹೊರಹೋಗುತ್ತದೆ ಅಥವಾ ಸುತರಾಂ ಹೋಗುವುದಿಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಜಾರಿಗೊಳಿಸುವ ನಿಯಮ ಸುರಂಗದ ಸ್ವಂತ ವೈಫಲ್ಯವನ್ನೂ ತಡೆದುಕೊಳ್ಳುತ್ತದೆ.