ಹೊಸ UFW ನಿಯಮ, ಹಳೆಯ ಸಂಪರ್ಕ: ಸ್ಥಾಪಿತ ಸ್ಥಿತಿಯೇ ಗೆಲ್ಲುತ್ತದೆ

ನಿರಾಕರಣೆ ನಿಯಮವನ್ನು ಸೇರಿಸಿ, ತೆರೆದ ಡೌನ್‌ಲೋಡ್ ಮುಂದುವರಿಯುವುದನ್ನು ನೋಡುವುದು UFW ದೋಷವಲ್ಲ. ನೀವು ಸೇರಿಸಿದ ನಿಯಮವು ಈಗಾಗಲೇ ಈ ಹರಿವನ್ನು ಸ್ವೀಕರಿಸಿದ ನಿಯಮಗಳ ನಂತರ ಬರುತ್ತದೆ, ಮತ್ತು ಹಿಂದೆ ಸ್ಥಾಪಿತವಾದ ಸಂಪರ್ಕವು ಅವುಗಳೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತಲೇ ಇರುತ್ತದೆ. ಇದನ್ನು ಸರಿಪಡಿಸಲು ಸರಿಯಾದ ಸ್ಥಾನದಲ್ಲಿ ಸೇರಿಸಬೇಕು ಮತ್ತು ಹಿಂದಿನ ನಿಯಮಗಳು ಏನನ್ನು ಭರವಸೆ ನೀಡುತ್ತವೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. ಆ ಬದಲಾವಣೆಯ ಸಂಕುಚಿತ ರೂಪವೇ ಮುಂದಿನದು.

ನಿಯಮದ ಅಸ್ತಿತ್ವವಲ್ಲ, ಕ್ರಮವೇ ನಿರ್ಧರಿಸುತ್ತದೆ

UFW ಎಂಬುದು netfilter ನಿಯಮಗಳನ್ನು ಹಂತಹಂತವಾಗಿ ಬರೆಯುವ ಮುಂಭಾಗವಾಗಿದೆ: ಬಳಕೆದಾರರ ನಿಯಮಗಳಿಗಿಂತ ಮೊದಲು ಚಲಿಸುವ ಚೌಕಟ್ಟಿನ ವಿಭಾಗ, ನಂತರ ಸ್ವತಃ ಬಳಕೆದಾರರ ನಿಯಮಗಳು, ನಂತರ ಅವುಗಳ ನಂತರ ಚಲಿಸುವ ವಿಭಾಗ. ಸ್ಟಾಕ್ ಹಿಂದಿನ ನಿಯಮಗಳು ಸ್ಥಾಪಿತ ಮತ್ತು ಸಂಬಂಧಿತ ಸಂಪರ್ಕಗಳ ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ, ಮತ್ತು ಆ ನಿಯಮಗಳು ನೀವು ಸಾಮಾನ್ಯ allow ಅಥವಾ deny ನಿಂದ ಸೇರಿಸುವ ಯಾವುದಕ್ಕಿಂತ ಮೊದಲು ಮೌಲ್ಯಮಾಪನಗೊಳ್ಳುತ್ತವೆ. UFW ಆಜ್ಞೆ ಉಲ್ಲೇಖವು ಸೇರಿಸುವ ವಾಕ್ಯರಚನೆ ಮತ್ತು ಈ ಬದಲಾವಣೆ ಅವಲಂಬಿಸಿರುವ ಸಂಖ್ಯಾಂಕಿತ ಸ್ಥಿತಿ ನೋಟವನ್ನು ದಾಖಲಿಸುತ್ತದೆ.

ಆ ಕ್ರಮವೇ ಆಶ್ಚರ್ಯವನ್ನು ವಿವರಿಸುತ್ತದೆ. ನಿಮ್ಮ ಹೊಸ ನಿಯಮ ನಿಜವಾದದ್ದು ಮತ್ತು ಸರಿಯಾದ ಕೋಷ್ಟಕದಲ್ಲಿದೆ, ಆದರೆ ಪ್ಯಾಕೆಟ್ ಎದುರಿಸುವ ಮೊದಲ ನಿರ್ಧಾರ ಅದಲ್ಲ. ಈಗಾಗಲೇ ಸ್ಥಾಪಿತ ಎಂದು ಟ್ರ್ಯಾಕ್ ಆಗುತ್ತಿರುವ ಸಂಪರ್ಕ ಅಲ್ಲಿಗೆ ಎಂದಿಗೂ ತಲುಪುವುದಿಲ್ಲ.

ಈ ಕೆಲಸಕ್ಕೆ route ನಿಯಮಗಳನ್ನು ಬಳಸಿ, ಏಕೆಂದರೆ ಪ್ಯಾಕೆಟ್ ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ಸೇವೆಗಳಿಗೆ ಉದ್ದೇಶಿಸಲ್ಪಡದೆ ಗೇಟ್‌ವೇ ಮೂಲಕ ಮುಂದಕ್ಕೆ ರವಾನೆಯಾಗುತ್ತದೆ. ಇನ್‌ಪುಟ್ ನಿಯಮವು ತಪ್ಪು ಸಂಚಾರವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿ ಏನೂ ಮಾಡದಂತೆ ಕಾಣುತ್ತಿತ್ತು.

ವಿಶಾಲ ಅನುಮತಿಯ ಮೇಲೆ ಸೇರಿಸಿ

ಅನ್ವಯಿಸುವ ಮೊದಲು ಸೇರಿಸುವಿಕೆಯನ್ನು ಮುನ್ನೋಟ ಮಾಡಿ ಮತ್ತು ನಿಯಮವು ಪಟ್ಟಿಯಲ್ಲಿ ಬೇರೆಡೆ ಈಗಾಗಲೇ ಇಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಒಂದೇ ನೀತಿಯನ್ನು ನಕಲಿಸುವುದು ನಂತರದ ತೆಗೆಯುವಿಕೆಯನ್ನು ಅಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ತಪ್ಪು ಪ್ರತಿಯನ್ನು ತೆಗೆಯುವವರಿಗೆ ವಾರಗಳವರೆಗೆ ಗೊತ್ತಾಗುವುದಿಲ್ಲ.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

ಮುನ್ನೋಟವು ನಿರೀಕ್ಷಿಸಿದ ಸ್ಥಾನದಲ್ಲಿ ನಿಖರವಾಗಿ ಒಂದು ನಿಯಮವನ್ನು ತೋರಿಸಿದರೆ, dry-run ಫ್ಲ್ಯಾಗ್ ಇಲ್ಲದೆ ಅದೇ ಆಜ್ಞೆಯನ್ನು ಅನ್ವಯಿಸಿ. ಸ್ಥಾನ 1 ಅದನ್ನು ಹೆಚ್ಚು ವಿಶಾಲ ಬಳಕೆದಾರ ಅನುಮತಿಗಳ ಮೇಲೆ ಇಡುತ್ತದೆ, ಮೊದಲು ಚರ್ಚಿಸಿದ ಚೌಕಟ್ಟಿನ ನಿಯಮಗಳ ಮೇಲಲ್ಲ. ಇಂಟರ್ಫೇಸ್ ಹೆಸರು ಈ ಗೇಟ್‌ವೇಯ ಟನಲ್ ಸಾಧನಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಇನ್ನು ಇಲ್ಲದ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಬಿಗಿದ ನಿಯಮವು ಪಟ್ಟಿಯಲ್ಲಿ ಕುಳಿತು ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಯಾವುದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಅನ್ವಯಿಸುವ ಮೊದಲೇ ಸಾಧನದ ಉಲ್ಲೇಖವನ್ನು ಮರುನಾಮಕರಣ ಮಾಡಿ, ಪರೀಕ್ಷೆ ವಿಫಲವಾದ ನಂತರವಲ್ಲ.

ಆ ನಿಯಮದಲ್ಲಿ ಗಮ್ಯ ಪೋರ್ಟ್ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಅದು ಆ ವಿಳಾಸದಲ್ಲಿ HTTPS ಮಾತ್ರವಲ್ಲ, ಎಲ್ಲಾ TCP ಪೋರ್ಟ್‌ಗಳನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ. ಉದ್ದೇಶ ಒಂದೇ ಸೇವೆಯಾಗಿದ್ದರೆ ಪೋರ್ಟ್ ಹೆಸರಿಸಿ; ನೀತಿಗಿಂತ ವಿಶಾಲವಾದ ನಿಯಮವು ಅದರ ಮೊದಲ ಓದುಗನನ್ನು ಕಾಯುತ್ತಿರುವ ಭವಿಷ್ಯದ ಘಟನೆ.

ಮೂಲವನ್ನು ಒಂದೇ ವಿಳಾಸಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಿ, ಆ ವಿಳಾಸವು ಉದ್ದೇಶಿತ ಗುರುತಿಗೆ ಬದ್ಧವಾಗಿದ್ದರೆ ಮಾತ್ರ. ಕ್ರಿಯಾತ್ಮಕ ಹಂಚಿಕೆಯ VPN ಪೂಲ್ ನಾಳೆ ಅದೇ ವಿಳಾಸವನ್ನು ಇನ್ನೊಬ್ಬ ಕ್ಲೈಂಟ್‌ಗೆ ಕೊಡಬಹುದು, ಮತ್ತು ನಿರಾಕರಣೆ ವ್ಯಕ್ತಿಯ ಬದಲು ವಿಳಾಸವನ್ನು ಹಿಂಬಾಲಿಸುತ್ತದೆ.

ಸ್ಥಾಪಿತ ಹರಿವುಗಳು ಹೊಸ ನಿಯಮದಿಂದ ಪಾರಾಗುತ್ತವೆ

ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್‌ವೇ ಇರುವ ಸೆಷನ್ ಮುಂದುವರಿಯುವ ಕಾರಣ. ಹರಿವು ಸ್ಥಾಪಿತ ಎಂದು ದಾಖಲಾದ ನಂತರ, ಹಿಂದಿನ ನಿಯಮಗಳು ನಿಮ್ಮ ನಿರಾಕರಣೆಯನ್ನು ನೋಡುವ ಮೊದಲೇ ಅದರ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ, ಮತ್ತು ವರ್ಗಾವಣೆ ಏನೂ ಬದಲಾಗದಂತೆ ಮುಗಿಯುತ್ತದೆ. ಆದ್ದರಿಂದ ತೆರೆದ ಸಂಪರ್ಕವನ್ನು ಮರುಬಳಕೆ ಮಾಡುವ ಬ್ರೌಸರ್‌ನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸುವುದು ಹೊಸ ನೀತಿಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ನಿಯೋಜನೆಯ ನಂತರ ಕೆಲವು ನಿಮಿಷಗಳಲ್ಲಿ ನಿರಾಕರಣೆ ನಿಷ್ಪ್ರಯೋಜಕವೆಂದು ತೋರಬಹುದು ಮತ್ತು ಮುಂದೆ ಸಂಪರ್ಕಿಸುವ ಬಳಕೆದಾರರಿಗೆ ಸಂಪೂರ್ಣ ಪರಿಣಾಮಕಾರಿಯಾಗಿರಬಹುದು.

ಅಗತ್ಯವು ಜೀವಂತ ಸಂಚಾರವನ್ನು ಕಡಿತಗೊಳಿಸುವುದನ್ನು ಒಳಗೊಂಡಿದ್ದರೆ, ಈ ಬಳಕೆದಾರ-ನಿಯಮ ಬದಲಾವಣೆ ಅದನ್ನು ನೀಡಲಾರದು. ಟ್ರ್ಯಾಕ್ ಮಾಡಿದ ಸ್ಥಿತಿಯನ್ನು ಹಿಂಪಡೆಯುವುದು ತನ್ನದೇ ಪ್ರಭಾವ ವ್ಯಾಪ್ತಿಯ ಪ್ರತ್ಯೇಕ ಕ್ರಿಯೆ, ಮತ್ತು ಅದು ನಿಯಮ ಸೇರಿಸಿದವರದ್ದಲ್ಲ, ಫೈರ್‌ವಾಲ್ ಮಾಲೀಕರದ್ದು. ಒಂದು ಸೆಷನ್ ಮಾಯವಾಗಲು ಗೇಟ್‌ವೇಯ ಎಲ್ಲಾ ಸಂಪರ್ಕಗಳನ್ನು ಖಾಲಿ ಮಾಡುವುದು ಎರಡನೇ ಘಟನೆಯನ್ನು ಸೃಷ್ಟಿಸುವ ರೀತಿಯ ಸರಿಪಡಿಸುವಿಕೆ.

ಮಿತಿಗಳನ್ನೂ ನೆನಪಿಡಿ. ಈ ನಿಯಮ ICMP, UDP ಅಥವಾ IPv6 ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಯಶಸ್ವಿ ping ನಿರಾಕರಣೆ ವಿಫಲವಾಯಿತು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ. ಒಂದು IPv4 ವಿಳಾಸವೂ ವೆಬ್‌ಸೈಟ್ ಅಲ್ಲ: ಹೆಸರು ಹಲವು ವಿಳಾಸಗಳಿಗೆ ಪರಿಹರಿಸಬಹುದು, ಮತ್ತು ನೀವು ಹೆಸರಿಸಿದ ಒಂದೇ ಆವರಿಸಲ್ಪಡುತ್ತದೆ.

ಹೊಸ ಹರಿವಿನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ

ಸಂಖ್ಯಾಂಕಿತ ಬಳಕೆದಾರ ನಿಯಮಗಳನ್ನು ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ಕಚ್ಚಾ ನೋಟವನ್ನು ಓದಿ, ನಂತರ ಆಯ್ಕೆಮಾಡಿದ ಕ್ಲೈಂಟ್‌ನಿಂದ ಹೊಸ ಸಂಪರ್ಕ ತೆರೆಯಿರಿ:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

ಕಚ್ಚಾ ನೋಟ ಮುಖ್ಯ ಏಕೆಂದರೆ status ಕೈಯಿಂದ ಬರೆದ ಚೌಕಟ್ಟಿನ ನಿಯಮಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಕ್ರಮವು ಕರ್ನೆಲ್ ಜಾರಿಗೊಳಿಸುವುದಕ್ಕಿಂತ ಬೇರೆಯಾಗಿ ಕಾಣಬಹುದು. ನಿಯಮ ತಪ್ಪು ಜಾಗದಲ್ಲಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಎರಡನ್ನೂ ಹೋಲಿಸಿ.

ನಂತರ ನಿಯಮವು ವಿಶಾಲವಲ್ಲ, ಸಂಕುಚಿತ ಎಂದು ಸಾಬೀತುಪಡಿಸುವ ಎರಡು ನಿಯಂತ್ರಣಗಳನ್ನು ಪರಿಶೀಲಿಸಿ: ಅದೇ ಕ್ಲೈಂಟ್‌ನಿಂದ ಅನುಮತಿಸಲಾದ ಗಮ್ಯಸ್ಥಾನ ಇನ್ನೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಎರಡನೇ ಕ್ಲೈಂಟ್ ತನ್ನ ನೀತಿ ಅನುಮತಿಸಿದರೆ ನಿರಾಕರಿಸಿದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಇನ್ನೂ ತಲುಪುತ್ತದೆ. ಎರಡೂ ಪರೀಕ್ಷೆಗಳನ್ನು ಮುರಿಯುವ ನಿರಾಕರಣೆ ನೀತಿ ಬದಲಾವಣೆ, ಗುರಿಯುತ ಕ್ರಮವಲ್ಲ.

ಪರೀಕ್ಷೆ ಮುಗಿದ ನಂತರ ನೀವು ಸೇರಿಸಿದ ನಿಯಮವನ್ನು ಮಾತ್ರ ತೆಗೆಯಿರಿ, ಅದನ್ನು ನಿಖರವಾಗಿ ಪುನಃ ಹೇಳಿ. ನೀತಿ ಶಾಶ್ವತವಾಗಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಗುರುತು, ಗಮ್ಯಸ್ಥಾನದ ಮಾಲೀಕ ಮತ್ತು ಪರಿಶೀಲನಾ ದಿನಾಂಕದೊಂದಿಗೆ ಅದನ್ನು ಫೈರ್‌ವಾಲ್ ಮಾಲೀಕರಿಗೆ ಒಪ್ಪಿಸಿ, ಇದರಿಂದ ಮರುಹಂಚಿಕೆಯಾದ ಟನಲ್ ವಿಳಾಸ ಹಳೆಯ ನಿರಾಕರಣೆಯನ್ನು ಬಿಟ್ಟುಹೋಗುವುದಿಲ್ಲ.