ಸ್ಥಳೀಯ ಅಪ್ಲಿಕೇಶನ್, VPN ನಿಯಮ: ನಿಮ್ಮ FORWARD ಸರಪಳಿ ಏಕೆ ಎಂದಿಗೂ ಸಕ್ರಿಯವಾಗದು
ಯಂತ್ರದಲ್ಲಿನ ಪ್ರಕ್ರಿಯೆ OUTPUT ಬಳಸುತ್ತದೆ, FORWARD ಅಲ್ಲ. ಸರಿಯಾದ namespace ನಲ್ಲಿ hook ಆಯ್ಕೆಮಾಡಿ, ನಂತರ mark ಅಥವಾ ಸರಳ route ಸಾಕೇ ಎಂದು ನಿರ್ಧರಿಸಿ.
ನೀವು FORWARD ಸರಪಳಿಯಲ್ಲಿ VPN ಸಂಚಾರಕ್ಕಾಗಿ ನಿಯಮ ಸೇರಿಸುತ್ತೀರಿ, ಅದೇ Linux ಯಂತ್ರದಿಂದ ವಿನಂತಿ ಚಲಾಯಿಸುತ್ತೀರಿ, ಮತ್ತು ಎಣಿಕೆಯು ಶೂನ್ಯದಲ್ಲೇ ಉಳಿಯುತ್ತದೆ. ನಿಯಮ ಬಹುಶಃ ಸರಿಯಾಗಿದೆ. ಪ್ಯಾಕೆಟ್ ಆ ಮಾರ್ಗವನ್ನು ಎಂದಿಗೂ ತೆಗೆದುಕೊಳ್ಳಲಿಲ್ಲ, ಏಕೆಂದರೆ ಯಂತ್ರದಲ್ಲೇ ಹುಟ್ಟಿದ ವಿನಂತಿಯನ್ನು ಅದು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವುದಿಲ್ಲ. ಪ್ಯಾಕೆಟ್ನ ಜೀವನವನ್ನು ಸಾಕೆಟ್ನಿಂದ ತಂತಿವರೆಗೆ ಅನುಸರಿಸುವುದು ಏಕೆ ಹೀಗೆ ಎಂಬುದನ್ನು ಮತ್ತು ನಿಯಮ ನಿಜವಾಗಿ ಎಲ್ಲಿ ಇರಬೇಕು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಪ್ಯಾಕೆಟ್ ಎಲ್ಲಿ ಹುಟ್ಟಿತು ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ
Netfilter ನ hook ಕ್ರಮವು ಮೂರು ಸಂದರ್ಭಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಒಂದು FORWARD ಒಳಗೊಂಡಿದೆ:
| Origin | Path | Hook that sees it |
|---|---|---|
| Local process | OUTPUT then POSTROUTING | OUTPUT, POSTROUTING |
| Addressed to a local service | PREROUTING then INPUT | PREROUTING, INPUT |
| Received for another host | PREROUTING, FORWARD, POSTROUTING | FORWARD |
ಸ್ಥಳೀಯ ಅಪ್ಲಿಕೇಶನ್ OUTPUT ಮಾರ್ಗದಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಕರ್ನಲ್ ಈಗಾಗಲೇ ಪ್ಯಾಕೆಟ್ ಇಲ್ಲಿಯೇ ಹುಟ್ಟುತ್ತದೆ ಮತ್ತು ಎಂದಿಗೂ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಅಭ್ಯರ್ಥಿಯಲ್ಲ ಎಂದು ನಿರ್ಧರಿಸಿದೆ. ಟನೆಲ್ ರಚಿಸುವುದು ಆ ವರ್ಗೀಕರಣವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ; ಟನೆಲ್ ಎಂಬುದು ಪ್ಯಾಕೆಟ್ ಹೊರಹೋಗಬಹುದಾದ ಸಾಧನ, ಸ್ಥಳೀಯ ಔಟ್ಪುಟ್ ಅನ್ನು ಟ್ರಾನ್ಸಿಟ್ ಆಗಿ ಮಾರ್ಪಡಿಸುವ ಹಂತವಲ್ಲ.
ಎರಡು ಪ್ಯಾಕೆಟ್, ಒಂದು ಕಥೆ
ಟನೆಲ್ ಎದ್ದ ನಂತರ ಅಪ್ಲಿಕೇಶನ್ನ ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಮತ್ತು ಗೂಢಲಿಪೀಕೃತ ಹೊರಗಿನ ಪ್ಯಾಕೆಟ್ ಬೇರೆ ಬೇರೆ ವಸ್ತುಗಳು. ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಅಪ್ಲಿಕೇಶನ್ ಆಯ್ಕೆಮಾಡಿದ ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಪೇಲೋಡ್ ಅನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ. ಹೊರಗಿನ ಪ್ಯಾಕೆಟ್ ಸೈಫರ್ಟೆಕ್ಸ್ಟ್ ಅನ್ನು ಸಹಚರನ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ಗೆ ಒಯ್ಯುತ್ತದೆ, ಮತ್ತು ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ವಾಸ್ತವವಾಗಿ ದಾಟುವುದು ಅದೇ.
ನಿಮ್ಮ ನೀತಿ ಅವುಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ, ಮತ್ತು ತಪ್ಪಾದದನ್ನು ಆಯ್ಕೆಮಾಡುವುದು ನಿಯಮ ಏನೂ ಮಾಡುತ್ತಿಲ್ಲ ಎಂದು ತೋರುವ ಸಾಮಾನ್ಯ ಕಾರಣ. ಸಹಚರನ ಹೊರಗಿನ ವಿಳಾಸಕ್ಕೆ ಹೊಂದುವ ನಿಯಮವು ಪ್ರತಿ ಟನೆಲ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಒಂದೇ ರೀತಿ ನೋಡುತ್ತದೆ, ಒಳಗಿನ ಅಪ್ಲಿಕೇಶನ್ ಏನೇ ಮಾಡುತ್ತಿದ್ದರೂ. ಒಳಗಿನ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಹೊಂದುವ ನಿಯಮವು ನಿಮಗೆ ಮುಖ್ಯವಾದ ಸಂಚಾರವನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಆ ಪ್ಯಾಕೆಟ್ ನೀವು ನಿಯಮ ಇರಿಸಿದ hook ತಲುಪಿದಾಗ ಮಾತ್ರ ಅದು ಸಕ್ರಿಯವಾಗುತ್ತದೆ.
namespace ಗಡಿಯನ್ನು ಸರಿಸುತ್ತವೆ
ಕಂಟೇನರ್ ತತ್ವವನ್ನು ಬದಲಿಸದೆ ಇದನ್ನು ಕಷ್ಟಕರವಾಗಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ನ ವಿನಂತಿ ಕಂಟೇನರ್ನ ನೆಟ್ವರ್ಕ್ namespace ಒಳಗಿನ ಸ್ಥಳೀಯ ಔಟ್ಪುಟ್. ಹೋಸ್ಟ್ ಆ ಸಂಚಾರವನ್ನು ವರ್ಚುವಲ್ Ethernet ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸ್ವೀಕರಿಸಿ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಬಹುದು, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ನಲ್ಲಿನ FORWARD ನಿಯಮ ಅರ್ಥಪೂರ್ಣವಾಗಿರಬಹುದು, ವಿನಂತಿ ಹುಟ್ಟಿಸಿದ ಪ್ರಕ್ರಿಯೆ ಹೋಸ್ಟ್ನ OUTPUT ಸರಪಳಿಯನ್ನು ಎಂದಿಗೂ ಸ್ಪರ್ಶಿಸದಿದ್ದರೂ.
hook ಆಯ್ಕೆಮಾಡುವ ಮೊದಲು ನಿಯಮಗಳ ಗುಂಪು ಮತ್ತು ಟನೆಲ್ ನಿಜವಾಗಿ ಎಲ್ಲಿ ಇರುತ್ತವೆ ಎಂದು ನಿರ್ಧರಿಸಿ. ಕಂಟೇನರ್ ಒಳಗಿನ ಟನೆಲ್, ಕಂಟೇನರ್ ಅನ್ನು ಅದರ ಮೂಲಕ route ಮಾಡಿದ ಹೋಸ್ಟ್ನ ಟನೆಲ್, ಮತ್ತು ಪ್ರತ್ಯೇಕ namespace ನಲ್ಲಿನ ಟನೆಲ್ ಎಂಬುವು ಮೂರು ವಿಭಿನ್ನ ಟೋಪಾಲಜಿಗಳು ಮತ್ತು ಮೂರು ವಿಭಿನ್ನ ನಿಯಮ ಸ್ಥಾನಗಳು. ನಿಯಮಗಳನ್ನು ಸಾಧನವನ್ನು ಹೊಂದಿರುವ namespace ಒಳಗೆ ಓದಿ, ಕೇವಲ ಡೀಫಾಲ್ಟ್ನಲ್ಲಿ ಅಲ್ಲ.
mark ನಿಜಕ್ಕೂ ಬೇಕೇ ಎಂದು ಕೇಳಿ
ಒಂದು ಗಮ್ಯಸ್ಥಾನ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಟನೆಲ್ ಮೂಲಕ ಕಳುಹಿಸುವುದು ಗುರಿಯಾದರೆ, ಆ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಒಂದು route ಸಾಕಾಗಬಹುದು. ಮೊದಲು ಪರಿಣಾಮಕಾರಿ route ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಸರ್ವರ್ ತಳ್ಳಿದ ಎಲ್ಲವನ್ನೂ ಸೇರಿಸಿ: ಮರುನಿರ್ದೇಶಿತ ಡೀಫಾಲ್ಟ್ ನೀವು ಉದ್ದೇಶಿಸಿದ ಸಂಕುಚಿತ ನೀತಿಗಿಂತ ಬಹಳ ಹೆಚ್ಚು ಸಂಚಾರವನ್ನು VPN ಮೂಲಕ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಎಷ್ಟೇ mark ಮಾಡಿದರೂ ಫಲಿತಾಂಶ ಉದ್ದೇಶಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗದು.
ನಿರ್ಧಾರವು route ವ್ಯಕ್ತಪಡಿಸಲಾಗದ ಯಾವುದೋ ಒಂದನ್ನು ಅವಲಂಬಿಸಿದಾಗ ವರ್ಗೀಕರಣ ಬೇಕು, ಉದಾಹರಣೆಗೆ ಮೂಲ, ಬಳಕೆದಾರ ಅಥವಾ ಪ್ರಕ್ರಿಯೆ. ಸ್ವೀಕರಿಸಿದ ಸಂಚಾರಕ್ಕೆ PREROUTING ನಲ್ಲಿ mark ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಸ್ಥಳೀಯ ಸಂಚಾರಕ್ಕೆ mark ಅನ್ನು mark ಇಟ್ಟ ನಂತರ ಹೊಸ route ಹುಡುಕಾಟವನ್ನು ಪ್ರಚೋದಿಸಬಲ್ಲ ಔಟ್ಪುಟ್ ಹಂತದಲ್ಲಿ ಮಾಡಬೇಕು. nftables ನಲ್ಲಿ ಅದು ಔಟ್ಪುಟ್ hook ನಲ್ಲಿ route ಪ್ರಕಾರದ ಸರಪಳಿ; ಸಾಮಾನ್ಯ ಔಟ್ಪುಟ್ ಫಿಲ್ಟರ್ ಸರಪಳಿ ಮೌಲ್ಯವನ್ನು ಇಟ್ಟು route ಅನ್ನು ಬದಲಾಗದೆ ಬಿಡುತ್ತದೆ.
iptables ನಲ್ಲಿ ಸಮಾನವಾದುದು mangle OUTPUT ಜೋಡಣೆಯಲ್ಲಿ ಇರುತ್ತದೆ, ಮತ್ತು ಅದೇ ಷರತ್ತು ಅನ್ವಯಿಸುತ್ತದೆ: mark ಇದ್ದ ನಂತರ route ನಿರ್ಧಾರವನ್ನು ಮರುಪರಿಶೀಲಿಸಬೇಕು. ನಂತರ ನೀತಿ ನಿಯಮವು mark ಅನ್ನು ಬಳಸಿಕೊಂಡು ಉಪಯುಕ್ತ route ಹೊಂದಿರುವ ಕೋಷ್ಟಕಕ್ಕೆ ತೋರಿಸಬೇಕು. conntrack mark ಇಡುವುದು ಮೂರನೇ, ಪ್ರತ್ಯೇಕ ಕಾರ್ಯಾಚರಣೆ; ಅದು ಹರಿವಿನ ಮೇಲೆ ಮೌಲ್ಯವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಆ ಮೌಲ್ಯವನ್ನು route ಮಾಡುವಿಕೆ ಓದಲು ಪ್ರಸ್ತುತ ಪ್ಯಾಕೆಟ್ನಲ್ಲಿ ತಾನೇ ಇಡುವುದಿಲ್ಲ.
ಹುಡುಕಾಟ ಮತ್ತು ಎಣಿಕೆಯನ್ನು ಒಟ್ಟಿಗೆ ಪರಿಶೀಲಿಸಿ
nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1ವಿಳಾಸ ಮತ್ತು mark ಉದಾಹರಣೆಗಾಗಿ ಮಾತ್ರ, ಮತ್ತು ಎರಡು route ಪ್ರಶ್ನೆಗಳು ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ. ಎರಡನೆಯದು ಪ್ಯಾಕೆಟ್ ಆ mark ಹೊತ್ತಿದ್ದರೆ ಕರ್ನಲ್ ಏನು ಮಾಡುತ್ತಿತ್ತು ಎಂದು ಕೇಳುತ್ತದೆ; ಅದು ನಿಮ್ಮ ನಿಯಮಗಳ ಗುಂಪು ಒಂದನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸುವುದಿಲ್ಲ. ಅದನ್ನು ಊಹೆ-ಪರೀಕ್ಷೆ ಎಂದು ಪರಿಗಣಿಸಿ, ನೀತಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬ ಸಾಕ್ಷ್ಯವಲ್ಲ.
ನಂತರ ನಿರುಪದ್ರವ ವಿನಂತಿ ಚಲಾಯಿಸಿ ಮತ್ತು ಒಟ್ಟಿಗೆ ಎರಡು ವಿಷಯಗಳನ್ನು ನೋಡಿ: ನೀವು ಆಯ್ಕೆಮಾಡಿದ hook ನಲ್ಲಿನ ಎಣಿಕೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ವಾಸ್ತವವಾಗಿ ತೆಗೆದುಕೊಂಡ ನಿರ್ಗಮನ. ಎಣಿಕೆ ಏರಿ ಪ್ಯಾಕೆಟ್ ಬೇರೆಡೆಯಿಂದ ಹೊರಟರೆ mark ಅಥವಾ ಕೋಷ್ಟಕ ತಪ್ಪು. ಎರಡೂ ಏರದಿದ್ದರೆ ಪ್ಯಾಕೆಟ್ ಆ hook ಗೆ ತಲುಪುವುದೇ ಇಲ್ಲ, ಮತ್ತು ಮುಂದಿನ ಪ್ರಶ್ನೆ namespace ಅಥವಾ ಮಾರ್ಗ.
ಕೊನೆಯದಾಗಿ, ಪರೀಕ್ಷೆಯನ್ನು ಕ್ರಿಯಾವಿಧಾನ ವ್ಯಕ್ತಪಡಿಸಬಲ್ಲದಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಿ. ಒಂದು ವಿಳಾಸಕ್ಕೆ ಒಂದು route, ವಿಳಾಸಗಳು ಬದಲಾಗುವ ಸೇವೆಗೆ ಶಾಶ್ವತ ನೀತಿಯಾಗುವುದಿಲ್ಲ. ಮೊದಲು ಪ್ಯಾಕೆಟ್ ವ್ಯಾಪ್ತಿಯನ್ನು ನಿರ್ಧರಿಸಿ, ನಂತರ ಮರುಸಂಪರ್ಕದ ನಂತರವೂ route ಮತ್ತು mark ವಿನ್ಯಾಸ ಆ ವ್ಯಾಪ್ತಿಯನ್ನು ಹಿಡಿದಿಡಬಲ್ಲದೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.