VPN ಹಿಂದಿನ ಸೇವೆಗೆ ufw allow 443 ಏನೂ ಮಾಡಲಿಲ್ಲ

ಒಳಬರುವ ಅನುಮತಿ ಫೈರ್‌ವಾಲ್ ಹೋಸ್ಟ್‌ಗೆ ಸಂಬಂಧಿಸಿದೆ, ಅದರ ಹಿಂದಿನ ಯಂತ್ರಕ್ಕಲ್ಲ. UFW ಬ್ಲಾಕ್ ಓದಿ, ನಂತರ ಮುಂದಕ್ಕೆ ರವಾನೆಯಾಗುವ ಸೇವೆಗೆ ಮಾರ್ಗ ನಿಯಮ ಬರೆಯಿರಿ.

VPN ಕ್ಲೈಂಟ್‌ನಿಂದ ping ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, TCP ಸೇವೆ ಸಮಯ ಮೀರುತ್ತದೆ, ಮತ್ತು ufw allow 443/tcp ಏನನ್ನೂ ಬದಲಾಯಿಸುವುದಿಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಗೇಟ್‌ವೇ ಮೇಲೆಯೇ ಅಲ್ಲದೆ ಗೇಟ್‌ವೇ ಹಿಂದಿನ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಚಲಿಸಿದಾಗ, ಆ ಅನುಮತಿ ತಪ್ಪು ಸಂಚಾರ ಮಾರ್ಗಕ್ಕೆ ಬರೆಯಲಾಗಿತ್ತು. ಪ್ಯಾಕೆಟ್ ಫೈರ್‌ವಾಲ್‌ಗೆ ವಿಳಾಸವಾಗಿಲ್ಲ ಮತ್ತು ಸ್ಥಳೀಯ ಪ್ರಕ್ರಿಯೆಗೆ ತಲುಪಿಸಲಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಒಳಬರುವ ನಿಯಮಗಳು ಅದನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ. ಪರಿಹಾರ ಮುಂದಕ್ಕೆ ರವಾನೆಯಾಗುವ ಹರಿವಿಗೆ ಗುರಿಯಾದ ಮಾರ್ಗ ನಿಯಮ, ಮತ್ತು ಅದರ ಸಾಕ್ಷ್ಯ ಈಗಾಗಲೇ ಲಾಗ್‌ನಲ್ಲಿದೆ.

ಗಮ್ಯಸ್ಥಾನ ಸ್ಥಳೀಯವೇ ಅಥವಾ ರವಾನೆಯಾಗಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ

ಕರ್ನೆಲ್ ನೋಡುವ ರೀತಿಯಲ್ಲೇ ಪ್ಯಾಕೆಟ್ ಓದಿ. ಗೇಟ್‌ವೇ ಮೇಲಿನ ಸೇವೆಗೆ ತಲುಪಿಸುವ ಸಂಚಾರ ಸ್ಥಳೀಯ ಒಳಹರಿವು. ಗೇಟ್‌ವೇ ಇನ್ನೊಂದು ಹೋಸ್ಟ್‌ಗೆ ರವಾನಿಸುವ ಸಂಚಾರ ರವಾನೆಯಾಗಿದೆ, ಮತ್ತು UFW ಎರಡು ಮಾರ್ಗಗಳಿಗೆ ಪ್ರತ್ಯೇಕ ನಿಯಮ ಸಂಗ್ರಹಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ವ್ಯತ್ಯಾಸವನ್ನು ಗಮ್ಯಸ್ಥಾನ ವಿಳಾಸ ಮತ್ತು ಮಾರ್ಗ ಹುಡುಕಾಟ ನಿರ್ಧರಿಸುತ್ತದೆ, ಪ್ಯಾಕೆಟ್ ಬಂದ ಇಂಟರ್‌ಫೇಸ್ ಅಲ್ಲ.

IN ಮತ್ತು OUT ಎರಡೂ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಒಂದೇ ಇಂಟರ್‌ಫೇಸ್ ತೋರಿಸುವ ಲಾಗ್ ಸಾಲು ಇನ್ನೂ ಮಾರ್ಗೀಕೃತ ಪ್ಯಾಕೆಟ್ ವಿವರಿಸಬಹುದು, ಏಕೆಂದರೆ ಒಂದೇ ಸಾಧನದಿಂದ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಒಳಗೆ ಮತ್ತು ಹೊರಗೆ ಸಾಗಿಸುವ ಸುರಂಗ ನಿಖರವಾಗಿ ಹಾಗೆಯೇ ಕಾಣುತ್ತದೆ. ಗಮ್ಯಸ್ಥಾನ ವಿಳಾಸ ಇಂಟರ್‌ಫೇಸ್ ಹೆಸರುಗಳಿಗಿಂತ ಬೇಗ ಈ ಪ್ರಶ್ನೆ ಬಗೆಹರಿಸುತ್ತದೆ. ಒಂದೇ ಹೆಸರನ್ನು ಎರಡು ಬಾರಿ ನೋಡುವುದು ಸ್ಥಳೀಯ ತಲುಪಿಸುವಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ನಿಯೋಜನೆ ಎಂದೂ ರಚಿಸದ ಸುರಂಗ ಇಂಟರ್‌ಫೇಸ್ ಕಲ್ಪಿಸುವುದೂ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.

ಯಾವುದೇ ನಿಯಮ ಸೇರಿಸುವ ಮೊದಲು ಬ್ಲಾಕ್ ಓದಿ

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

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

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

ಹೊಂದುವ ಅತ್ಯಂತ ಸಂಕುಚಿತ ಮಾರ್ಗ ನಿಯಮ ಬರೆಯಿರಿ

ಈ ಉದಾಹರಣೆಯಲ್ಲಿ ಕ್ಲೈಂಟ್‌ಗಳು 172.20.8.0/24 ನಿಂದ tun0 ಗೆ ಬರುತ್ತಾರೆ, ಸೇವೆ 8443 ಪೋರ್ಟ್‌ನಲ್ಲಿ 10.30.0.15 ನಲ್ಲಿ ಕೇಳುತ್ತದೆ, ಮತ್ತು ಗೇಟ್‌ವೇ ens5 ಮೂಲಕ ಹೊರಡುತ್ತದೆ. ಆ ಮೌಲ್ಯಗಳನ್ನು ಕ್ಲೌಡ್ VPC ಯ ಡಿಫಾಲ್ಟ್ 10.0.0.0/16 ಅಥವಾ ಮನೆಯ 192.168.0.0/16 ನಂತೆ ಕಾಣದಂತೆ ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ, ಮತ್ತು 8443 ಉದಾಹರಣೆಯನ್ನು ಗೇಟ್‌ವೇಯ ಸ್ವಂತ 443 ಶ್ರೋತೃದಿಂದ ದೂರವಿಡುತ್ತದೆ.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

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

UFW ಅನುಮತಿಸಿದ ಸಂಪರ್ಕಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅನುಮತಿಸಿದ ರವಾನೆ ಹರಿವಿನ ಪ್ರತ್ಯುತ್ತರಗಳು ಸ್ಪಷ್ಟ ವಿರುದ್ಧ ನಿಯಮವಿಲ್ಲದೆ ಸ್ವೀಕರಿಸಲ್ಪಡುತ್ತವೆ. ವಿಷಯಗಳು ಕೆಲಸ ಮಾಡಲು ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ನಿರ್ಬಂಧವಿಲ್ಲದ ನಿಯಮ ಸೇರಿಸುವುದು ನೀತಿಯನ್ನು ಒಂದು ಸೇವೆಯಿಂದ ಬಹಳ ದೂರ ವಿಸ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯ ವಿನಂತಿ-ಪ್ರತ್ಯುತ್ತರ ವಿನಿಮಯಕ್ಕೆ ಅದು ಬೇಕಿಲ್ಲ. ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಗುಪ್ತವಾಗಿ ಮತ್ತು ನಿಯಮ ಸಂಗ್ರಹವನ್ನು ಓದಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಇರಿಸಿ.

ಶುಷ್ಕ ರನ್ ನಿಮ್ಮ ಉದ್ದೇಶಕ್ಕೆ ಹೊಂದಿದ ನಂತರವೇ ನಿಯಮವನ್ನು ಅನ್ವಯಿಸಿ, ನಂತರ ಕ್ರಮಬದ್ಧ ಪಟ್ಟಿ ಅದನ್ನು ನಿರೀಕ್ಷಿತ ಸ್ಥಾನದಲ್ಲಿ ತೋರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. VPN ಶ್ರೋತೃ ಮತ್ತು ನಿರ್ವಹಣಾ ನಿಯಮಗಳನ್ನು ಪ್ರತ್ಯೇಕ ವಿಷಯಗಳಾಗಿ ಉಳಿಸಿ, ಏಕೆಂದರೆ ಅವನ್ನು ಬದಲಿಸುವುದು ಒಂದು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅನುಮತಿ ನೀಡುವುದಕ್ಕಿಂತ ಬೇರೆ ನಿರ್ಣಯ. ಟೋಪೋಲಜಿ ಬರೆದಿರುವ ಅದೇ ಸ್ಥಳದಲ್ಲಿ ಬದಲಾವಣೆ ದಾಖಲಿಸಿ, ಮುಂದಿನ ಇಂಜಿನಿಯರ್ ಪ್ಯಾಕೆಟ್ ಕ್ಯಾಪ್ಚರ್‌ನಿಂದ ಅದನ್ನು ಮತ್ತೆ ಕಂಡುಹಿಡಿಯಬೇಕಾಗದಂತೆ.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

UFW ನಿಮ್ಮ ಪರವಾಗಿ ಏನನ್ನು ಜಾರಿಗೊಳಿಸಲಾಗದು ಎಂದು ಪರಿಶೀಲಿಸಿ

ಸರಿಯಾದ ನಿಯಮಕ್ಕೆ ಇನ್ನೂ ಕರ್ನೆಲ್ ರವಾನೆ ಮತ್ತು ಸೇವೆಯನ್ನು ತಲುಪುವ ಮಾರ್ಗ ಬೇಕು. ಫೈರ್‌ವಾಲ್ ಅನ್ನು ಎರಡನೇ ಬಾರಿ ದೂಷಿಸುವ ಮೊದಲು ಎರಡನ್ನೂ ಖಚಿತಪಡಿಸಿ.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

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

ಫೈರ್‌ವಾಲ್ ಸಕ್ರಿಯವಾಗಿರುವಾಗ ಹೊಸ ಸಂಪರ್ಕವನ್ನು ಪರೀಕ್ಷಿಸಿ ಮುಗಿಸಿ, ಅನುಮತಿಸಿದ ಮೂಲದಿಂದ ಮತ್ತು ಸಂಬಂಧವಿಲ್ಲದ ಮೂಲದಿಂದ. UFW ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಒಂದೇ ಆಜ್ಞೆಯಲ್ಲಿ ಲಕ್ಷಣವನ್ನು ತೆಗೆದು ಸಾಕ್ಷ್ಯವನ್ನು ನಾಶಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಮೊದಲನೆಯದಲ್ಲ, ಕೊನೆಯ ಪ್ರಯೋಗವಾಗಿರಬೇಕು.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು