ಪ್ರತಿ VPN ಕ್ಲೈಂಟ್ ಪೂಲ್‌ಗೆ ಒಂದು ಗಮ್ಯಸ್ಥಾನ ಶ್ರೇಣಿಯನ್ನು ನಿರ್ಬಂಧಿಸಿ
ಒಂದು nftables ನಿಯಮವು ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ಸಂಚಾರವನ್ನು ಮುಟ್ಟದೆಯೇ ಅನುಮತಿಸಲಾದ VPN ಪೂಲ್‌ಗೆ ಗಮ್ಯಸ್ಥಾನ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ನಿರಾಕರಿಸಬಹುದು. ಹುಕ್ ಮತ್ತು ಸ್ಥಾನವನ್ನು ಹೊಂದಿಸಿ.
ಒಂದು ನಿಯಮವು ಅನುಮತಿಸಲಾದ VPN ಪೂಲ್ ಅನ್ನು ಗಮ್ಯಸ್ಥಾನ ಶ್ರೇಣಿಯಿಂದ ದೂರವಿಡಬಹುದು, ಗೇಟ್‌ವೇ ಮಾಡುವ ಬೇರೆ ಯಾವುದಕ್ಕೂ ಅಡ್ಡಿಯಾಗದೆ. ನಿಯಮ ಸ್ವತಃ ಚಿಕ್ಕದು; ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಭಾಗಗಳೆಂದರೆ ಅದು ವಾಸಿಸುವ ಹುಕ್ ಮತ್ತು ಸರಪಳಿಯಲ್ಲಿನ ಅದರ ಸ್ಥಾನ. ಈ ಎರಡನ್ನೂ ತಪ್ಪಿಸಿದರೆ ಸರಿಯಾಗಿ ಕಾಣುವ ಆದರೆ ಅಸಂಗತವಾಗಿ ವರ್ತಿಸುವ ಫೈರ್‌ವಾಲ್ ಸಿಗುತ್ತದೆ. ನಿಯಮವು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ನೋಡಿದಾಗ ಪ್ಯಾಕೆಟ್ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ.
ನಿಯಮವು ನಿಜವಾಗಿ ಏನನ್ನು ಹೊಂದಿಸುತ್ತದೆ
ನಿಯಮವು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಮೂರು ವಿಷಯಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ: ಇನ್‌ಪುಟ್ ಇಂಟರ್‌ಫೇಸ್, ಮೂಲ ಪೂರ್ವಪ್ರತ್ಯಯ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ಪೂರ್ವಪ್ರತ್ಯಯ. ಡ್ರಾಪ್ ಅನ್ವಯವಾಗುವ ಮೊದಲು ಮೂರೂ ನಿಜವಾಗಿರಬೇಕು, ಮತ್ತು ಇದು ಅದನ್ನು ಸಣ್ಣದಾಗಿ ಇಡುತ್ತದೆ. ಅದನ್ನು ಮೂರು ಪ್ರತ್ಯೇಕ ನೀತಿಗಳಾಗಿ ಓದುವುದಕ್ಕಿಂತ ಒಂದು ಅಭಿವ್ಯಕ್ತಿಯಾಗಿ ಓದುವುದು ಸುಲಭ.
ಇಂಟರ್‌ಫೇಸ್ ಹೊಂದಾಣಿಕೆಯು ಮುಂದಕ್ಕೆ ರವಾನೆಯಾದ ಕ್ಲೈಂಟ್ ಸಂಚಾರವನ್ನು ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ಸಂಪರ್ಕಗಳಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಅದಿಲ್ಲದೆ, ಕೇವಲ ಮೂಲ ಪೂಲ್ ಅನ್ನು ಹೆಸರಿಸುವ ನಿಯಮವು ಗೇಟ್‌ವೇ ಸ್ವತಃ ಆ ವಿಳಾಸದಿಂದ ರಚಿಸುವ ಪ್ಯಾಕೆಟ್‌ಗಳ ಮೇಲೂ ಪರಿಣಾಮ ಬೀರುತ್ತಿತ್ತು, ಅಂತಹದ್ದು ಎಂದಾದರೂ ಸಂಭವಿಸಿದರೆ. ಮೂಲ ಪೂರ್ವಪ್ರತ್ಯಯವು ನೀತಿಯನ್ನು ಅನುಮತಿಸಲಾದ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ಪೂರ್ವಪ್ರತ್ಯಯವು ಅದನ್ನು ಒಂದು ಶ್ರೇಣಿಗೆ ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ. ನಿಯಮವನ್ನು ಪಟ್ಟಿಯಲ್ಲ, ಛೇದನವಾಗಿ ಓದಿ.
ಏನನ್ನಾದರೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ಮೂರು ಮೌಲ್ಯಗಳನ್ನು ಬರೆಯಿರಿ: ಟನಲ್ ಇಂಟರ್‌ಫೇಸ್‌ನ ಹೆಸರು, ಸರ್ವರ್ ಹಂಚುವ ಪೂಲ್, ಮತ್ತು ನೀವು ನಿರಾಕರಿಸಲು ಉದ್ದೇಶಿಸಿರುವ ಪೂರ್ವಪ್ರತ್ಯಯ. ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಟೈಪೊ ಇದ್ದರೆ ಸ್ವಚ್ಛವಾಗಿ ಪಾರ್ಸ್ ಆಗುವ ಆದರೆ ಏನನ್ನೂ ರಕ್ಷಿಸದ ನಿಯಮ ಉಂಟಾಗುತ್ತದೆ. ಆ ಮೂರು ಮೌಲ್ಯಗಳನ್ನು ನಿಯಮದ ಪಕ್ಕದಲ್ಲಿರುವ ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ಇರಿಸಿ.
ಹುಕ್ ನಿಯಮವು ಯಾರಿಗೆ ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ
netfilter ಸರಪಳಿಯು ಹುಕ್‌ಗೆ ಜೋಡಣೆಯಾಗಿರುತ್ತದೆ, ಮತ್ತು ಯಾವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸರಪಳಿ ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ಹುಕ್ ನಿರ್ಧರಿಸುತ್ತದೆ. forward ಹುಕ್ ಗೇಟ್‌ವೇ ಮೂಲಕ ರೂಟ್ ಆಗುವ ಸಂಚಾರವನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್‌ನಿಂದ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಸಂಚಾರ ಅದೇ ಆಗಿದೆ. ಸರಪಳಿಯಲ್ಲಿನ ಉಳಿದೆಲ್ಲವೂ ಬೇರೆ ಪ್ರೇಕ್ಷಕರ ಕಡೆಗೆ ಗುರಿಯಾಗಿದೆ.
input ಹುಕ್ ಗೇಟ್‌ವೇಗೆ ಸ್ವತಃ ಉದ್ದೇಶಿಸಿದ ಸಂಚಾರವನ್ನು ನೋಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಲ್ಲಿ ಇಡುವ ನಿಯಮವು ಸಾಗಣೆಯ ಬದಲು ಅದರ ಸ್ವಂತ ಸೇವೆಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. output ಹುಕ್ ಗೇಟ್‌ವೇ ಉತ್ಪಾದಿಸುವ ಸಂಚಾರವನ್ನು ನೋಡುತ್ತದೆ, ಇದು ಕ್ಲೈಂಟ್ ಪೂಲ್ ನೀತಿಗೆ ಬೇಕಾದದ್ದಕ್ಕೆ ವಿರುದ್ಧ. ಸರಪಳಿಯ ಹೆಸರುಗಳು ನಿಯಮಸಂಗ್ರಹ ಬರೆದವರು ಆಯ್ಕೆ ಮಾಡಿದ ಅನಿಯತ ಲೇಬಲ್‌ಗಳು, ಆದ್ದರಿಂದ ಹೆಸರಿನಿಂದ ಹುಕ್ ಅನ್ನು ಊಹಿಸಬೇಡಿ. ಸರಪಳಿ ಎಲ್ಲಿ ಜೋಡಣೆಯಾಗಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಅದು ಏನನ್ನು ಹೊಂದಿಸಬಹುದು ಎಂದು ಊಹಿಸಿ.
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
ಜೋಡಣೆಯನ್ನು ಓದುವುದು ಒಂದು ಸಾಲಿನ ಪರಿಶೀಲನೆ, ಇದು ನಿಯಮವು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಎಂದಿಗೂ ನೋಡದ ಸರಪಳಿಗೆ ಬೀಳುವುದನ್ನು ತಡೆಯುತ್ತದೆ.
ವಿಶಾಲ accept ಗಿಂತ ಮೊದಲು ನಿಯಮವನ್ನು ಇರಿಸಿ
ನಿಯಮಗಳು ಕ್ರಮದಲ್ಲಿ ಮೌಲ್ಯಮಾಪನವಾಗುತ್ತವೆ, ಮತ್ತು ಮೊದಲ ತೀರ್ಪು ಗೆಲ್ಲುತ್ತದೆ. ಸರಪಳಿಯಲ್ಲಿ ಹಿಂದಿನ ವಿಶಾಲ accept ತಾನು ಹೊಂದಿಸುವ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಮೌಲ್ಯಮಾಪನವನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಂತರ ಸೇರಿಸಿದ ಡ್ರಾಪ್ ಅವುಗಳಿಗೆ ಎಂದಿಗೂ ಚಲಿಸುವುದಿಲ್ಲ. ಆ ಕ್ರಮ ನಿಯಮವೇ ಸರಿಯಾಗಿ ಕಾಣುವ ನಿಯಮಕ್ಕೆ ಪರಿಣಾಮ ಇಲ್ಲದಿರಲು ಸಂಪೂರ್ಣ ಕಾರಣ.
ನಿಯಮವನ್ನು ಕೊನೆಗೆ ಸೇರಿಸುವ ಬದಲು accept ಗಿಂತ ಮೊದಲು ಸೇರಿಸಿ. ಸರಪಳಿಯಲ್ಲಿ ಟನಲ್ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಈಗಾಗಲೇ ಸಾಮಾನ್ಯ accept ಇದ್ದರೆ, ಹೊಸ ನಿಯಮವು ಅದಕ್ಕಿಂತ ಮೊದಲು ಇರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಅದು ಕೇವಲ ಅಲಂಕಾರ. ನೀವು ಸಂಪಾದಿಸಿದ ಫೈಲ್ ಅಲ್ಲ, ಪರಿಣಾಮವಾಗಿ ಬರುವ ಕ್ರಮವನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಹಲವು ಫೈಲ್‌ಗಳಿಂದ ಜೋಡಿಸಿದ ನಿಯಮಸಂಗ್ರಹವು ಯಾವುದೇ ಒಂದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗದಿರಬಹುದು. ನಂತರ ಪೂಲ್‌ನಿಂದ ಪರೀಕ್ಷಾ ಪ್ಯಾಕೆಟ್‌ನಿಂದ ದೃಢೀಕರಿಸಿ.
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.confಮೂರನೇ ಆಜ್ಞೆಯು ಫೈಲ್ ಅನ್ನು ಅನ್ವಯಿಸದೆ ವಿಶ್ಲೇಷಿಸುತ್ತದೆ, ಇದು ಸಿಂಟ್ಯಾಕ್ಸ್ ದೋಷಗಳನ್ನು ಅಡಚಣೆಯಾಗುವ ಮೊದಲು ಹಿಡಿಯುತ್ತದೆ. ಹಿಂಪಡೆಯುವ ಯೋಜನೆಯೊಂದಿಗೆ ಅನ್ವಯಿಸಿ, ಏಕೆಂದರೆ forward ಸರಪಳಿಯಲ್ಲಿ ತಪ್ಪಾದ ನಿಯಮವು ನೀವು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಟನಲ್ ಅನ್ನು ಕಡಿಯಬಹುದು.
ಇರುವ ಹರಿವುಗಳು ನಿಮ್ಮ ಹೊಸ ನಿಯಮದ ಬಗ್ಗೆ ಲಕ್ಷ್ಯವಿಡುವುದಿಲ್ಲ
ನಿಯಮ ಅಸ್ತಿತ್ವಕ್ಕೆ ಬರುವ ಮೊದಲು ರಚಿಸಿದ conntrack ನಮೂದು ಹಿಂದಿನ accept ಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತಲೇ ಇರುತ್ತದೆ. ಆದ್ದರಿಂದ ಹೊಸ ಡ್ರಾಪ್ ಕೆಲವೊಮ್ಮೆ ಹೊಸ ಸಂಪರ್ಕಗಳಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಂತೆ ಕಾಣುತ್ತದೆ ಮತ್ತು ಪರೀಕ್ಷಿಸುತ್ತಿರುವ ಸಂಪರ್ಕಕ್ಕೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.
ಸರಪಳಿಯ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಸ್ಥಿತಿ ಹೊಂದಾಣಿಕೆಯನ್ನು ಓದಿ. ಅದು ನಿಮ್ಮ ನಿಯಮಕ್ಕಿಂತ ಮೊದಲು established ಮತ್ತು related ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸಿದರೆ, ಈಗಾಗಲೇ ನಡೆಯುತ್ತಿರುವ ಪ್ರತಿ ಹರಿವು ಮುಚ್ಚುವವರೆಗೆ ಹರಿಯುತ್ತಲೇ ಇರುತ್ತದೆ. ತುರ್ತು ನಿಯಮಕ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಇದೇ ಬೇಕಾದ ವರ್ತನೆ, ಮತ್ತು ತಕ್ಷಣದ ಕಡಿತವನ್ನು ನಿರೀಕ್ಷಿಸಿದಾಗ ಇದು ಗೊಂದಲ ಉಂಟುಮಾಡುತ್ತದೆ. ನಿಯೋಜಿಸುವ ಮೊದಲು ಯಾವ ಪರಿಣಾಮ ಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ. ತೆರೆದ ಸಂಪರ್ಕವನ್ನು ಮರುಬಳಕೆ ಮಾಡುವ ಪರೀಕ್ಷೆ ನಿಮಗೆ ತಪ್ಪು ಕಥೆ ಹೇಳುತ್ತದೆ.
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'ಮೊದಲ ಆಜ್ಞೆ ಹರಿವು ಇದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಎರಡನೆಯದು ಹಿಂದಿನ ಸ್ಥಿತಿ ನಿಯಮವು ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತಲೇ ಇದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಎರಡೂ ಓದಲು-ಮಾತ್ರ ಮತ್ತು ಘಟನೆಯ ಸಮಯದಲ್ಲಿ ಚಲಾಯಿಸಲು ಸುರಕ್ಷಿತ.
ಈ ನಿಯಮ ಏನಲ್ಲ
ನಿಯಮವು ಡೊಮೇನ್ ಕಪ್ಪುಪಟ್ಟಿ, IPv6 ನೀತಿ ಅಥವಾ ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್ ಖಾತೆಯ ಮೇಲಿನ ನಿರ್ಬಂಧವಲ್ಲ.
ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಕಾರ್ಯವಿಧಾನ ಬೇಕು. ಡೊಮೇನ್ ನಿರ್ಬಂಧವು ಹೆಸರುಗಳನ್ನು ಪರಿಹರಿಸಬೇಕು, ಪ್ಯಾಕೆಟ್ ಫಿಲ್ಟರ್ ಅದನ್ನು ಮಾಡುವುದಿಲ್ಲ. IPv6 ಸಂಚಾರಕ್ಕೆ ತನ್ನದೇ ಹೊಂದಾಣಿಕೆ ಬೇಕು, ಏಕೆಂದರೆ ip ಅಭಿವ್ಯಕ್ತಿ ip6 ಪ್ಯಾಕೆಟ್‌ಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ನಿರ್ಬಂಧವು ಪೂರ್ವಪ್ರತ್ಯಯ ಹೊಂದಾಣಿಕೆಗೆ ಅಲ್ಲ, ಸೇವೆ ಅಥವಾ ದೃಢೀಕೃತ ಪ್ರಾಕ್ಸಿಗೆ ಸೇರಿದ್ದು. ಈ ಅಗತ್ಯಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುವುದೇ ಒಂದು ಸಣ್ಣ ನಿಯಮಕ್ಕೆ ನಾಲ್ಕು ಕೆಲಸಗಳನ್ನು ಕೇಳುವುದನ್ನು ತಡೆಯುತ್ತದೆ.
ಈ ನಿಯಮ ನೀಡುವ ಒಪ್ಪಂದ ನಿಖರವಾಗಿದೆ: ಅನುಮತಿಸಲಾದ ಪೂಲ್‌ನಿಂದ ಒಂದು ಗಮ್ಯಸ್ಥಾನ ಪೂರ್ವಪ್ರತ್ಯಯಕ್ಕೆ ಸಂಚಾರ ನಿರಾಕರಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಸಂಬಂಧವಿಲ್ಲದ ಗೇಟ್‌ವೇ ಸಂಚಾರ ತನ್ನ ಪ್ರಸ್ತುತ ನೀತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಆ ವಾಕ್ಯವನ್ನು ನಿಯಮದ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅದು ಯಾವುದಕ್ಕಾಗಿ ಎಂದು ತಿಳಿಯುತ್ತಾರೆ.