firewalld ಕೇಳುಗ ನಿಯಮ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿ: ಪ್ರತಿಯೊಂದೂ ಏನು ಮಾಡುತ್ತದೆ

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

ಎರಡು ನೀತಿಗಳು, ಒಂದು ಟನೆಲ್

ಹೊರ ನೀತಿ ಸರಳ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಈ ಮೂಲದಿಂದ ಬರುವ ಪ್ಯಾಕೆಟ್ ಈ ಹೋಸ್ಟ್‌ನಲ್ಲಿ UDP 1194 ತಲುಪಬಹುದೇ? ಒಳ ನೀತಿ ಇನ್ನೊಂದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ: ಆ ಟನೆಲ್‌ನ ಹಿಂದಿನ ದೃಢೀಕೃತ ಕ್ಲೈಂಟ್ ಈ ಗಮ್ಯಸ್ಥಾನವನ್ನು, ಈ ಪ್ರೋಟೋಕಾಲ್‌ನೊಂದಿಗೆ, ಈ ಪೋರ್ಟ್‌ನಲ್ಲಿ ತಲುಪಬಹುದೇ? ಮೊದಲನೆಯದು ಸಾಕೆಟ್ ಬಗ್ಗೆ, ಎರಡನೆಯದು ಮಾರ್ಗದ ಬಗ್ಗೆ, ಮತ್ತು firewalld ಅವುಗಳನ್ನು ಬೇರೆ ಬೇರೆ ವಸ್ತುಗಳಿಂದ ರೂಪಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಅವು ಬೇರೆ ಬೇರೆ ಹಂತಗಳಲ್ಲಿ ನಿರ್ಧರಿಸಲ್ಪಡುತ್ತವೆ. ಒಂದು ಈ ಹೋಸ್ಟ್‌ನ ಸಾಕೆಟ್‌ನ ಗುಣ, ಇನ್ನೊಂದು ಅದರ ಮೂಲಕ ಹಾದುಹೋಗುವ ಮಾರ್ಗದ ಗುಣ.

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

ನಿಜವಾದ ಹೊರ ಕೇಳುಗವನ್ನು ಅನುಮತಿಸಿ

ಊಹಿಸುವ ಬದಲು ಈಗಾಗಲೇ ನಿಗದಿಯಾಗಿರುವುದನ್ನು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ. ಸಕ್ರಿಯ ವಲಯಗಳನ್ನು ಓದಿ, ನಿಜವಾಗಿ ಒಳಹರಿವನ್ನು ಹೊತ್ತಿರುವ ವಲಯವನ್ನು ಪಟ್ಟಿ ಮಾಡಿ ಮತ್ತು ಸ್ಥಾಪಿತ ಸೇವಾ ವ್ಯಾಖ್ಯಾನವನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಸೇವೆಯ ಹೆಸರು ಪೋರ್ಟ್‌ಗಳ ಗುಂಪನ್ನು ವಿವರಿಸುತ್ತದೆ ಮತ್ತು ಈ ಸರ್ವರ್‌ನ ಕೇಳುಗ ಅದಕ್ಕೆ ಹೊಂದುತ್ತದೆಯೇ ಎಂಬ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

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

ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಅಧಿಕೃತಗೊಳಿಸಿ

VPN ಸರ್ವರ್‌ನಲ್ಲೇ ಚಲಿಸುವ ಸೇವೆಗೆ ಸಂಪರ್ಕ ಸ್ಥಳೀಯ-ಇನ್‌ಪುಟ್ ನೀತಿ. LAN ನಲ್ಲಿ ಇನ್ನೊಂದು ಹೋಸ್ಟ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಆಗುವ ಸಂಪರ್ಕಕ್ಕೆ ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿ ಬೇಕು, ಕರ್ನಲ್‌ನಲ್ಲಿ ಸಕ್ರಿಯಗೊಳಿಸಿದ ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಒಂದು ಪ್ರತ್ಯುತ್ತರ ಮಾರ್ಗ — ಇವು ಮೂರು ಪ್ರತ್ಯೇಕ ಅವಶ್ಯಕತೆಗಳು, ಜನರು ಸಾಮಾನ್ಯವಾಗಿ ಅವನ್ನು ಒಂದಾಗಿ ಸೇರಿಸುತ್ತಾರೆ. ಆಧುನಿಕ firewalld ನೀತಿ ವಸ್ತುಗಳು ಒಳಹರಿವು ವಲಯ ಮತ್ತು ಹೊರಹರಿವು ವಲಯಗಳ ನಡುವಿನ ನಿರ್ದೇಶಿತ ಸಂಚಾರವನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮತ್ತು ಯಾವ VPN ಮೂಲಗಳು ಯಾವ ಖಾಸಗಿ ಸೇವೆಗಳನ್ನು ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ವ್ಯಕ್ತಪಡಿಸಲು ಸರಿಯಾದ ಸ್ಥಳ ಅದೇ.

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

ಇಂಟರ್‌ಫೇಸ್ ಮೇಲೆ ನಂಬಿಕೆ ಇಡುವುದು ಏಕೆ ತಪ್ಪು ಚುಟುಕು

ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಗುರಿ ಎಲ್ಲವನ್ನೂ ಸ್ವೀಕರಿಸುವ ವಲಯಕ್ಕೆ ಹಾಕುವುದು ಹೋಸ್ಟ್ ಒಡ್ಡುವ ಪ್ರತಿ ಸೇವೆಗೂ ಎಲ್ಲಾ ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಸಂಚಾರವನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ನೀವು ಪರಿಶೀಲಿಸದ ಸೇವೆಗಳೂ ಸೇರಿದಂತೆ. ಚಾಲನೆಯಲ್ಲಿರುವ ಯಂತ್ರದಲ್ಲಿ ವಿಶ್ವಾಸಾರ್ಹ ವಲಯವನ್ನು ನಿರ್ಬಂಧಕವಾಗಿ ಮರುಗುರಿಪಡಿಸುವುದು ಇನ್ನೂ ಕೆಟ್ಟದು, ಏಕೆಂದರೆ ಇತರ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಮತ್ತು ಮೂಲ ಶ್ರೇಣಿಗಳು ಈಗಾಗಲೇ ಅದರ ಅರ್ಥವನ್ನು ಅವಲಂಬಿಸಿರಬಹುದು ಮತ್ತು ನೀವು ಸಂಪಾದಿಸಿದಾಗ ವರ್ತನೆ ಬದಲಾಗುತ್ತದೆ. ಸಂಕುಚಿತ ನೀತಿ ಬೇಕಿದ್ದರೆ ಒಂದನ್ನು ರಚಿಸಿ; ಹಂಚಿದ ವಲಯವನ್ನು ಮರುಬಳಕೆ ಮಾಡಬೇಡಿ.

ಟನೆಲ್‌ನ ವಲಯ ನಿಗದಿಯನ್ನು ಆ ಸಂರಚನೆಯನ್ನು ಹೊಂದಿರುವ ಯಾವುದೇ ಘಟಕದ ಮೂಲಕ ಸ್ಥಿರವಾಗಿ ಇರಿಸಿ. ಮರುಪ್ರಾರಂಭದಲ್ಲಿ ನಿಗದಿ ಕಳೆದುಕೊಳ್ಳುವುದು ಫೈರ್‌ವಾಲ್ ನಿಯಮದ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುವ ಆದರೆ ವಾಸ್ತವವಾಗಿ ಸ್ಥಿರತೆಯ ಸಮಸ್ಯೆಯಾದ ವೈಫಲ್ಯವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಮೂರು ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಅವುಗಳಲ್ಲಿ ಒಂದು ನಿರಾಕರಣೆ

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

ಸರ್ವರ್‌ನ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ವಲಯ, ಪೋರ್ಟ್, ಸಾಗಣೆ ಮತ್ತು ನೀತಿ ವಸ್ತುವನ್ನು ದಾಖಲಿಸಿ. ಇಲ್ಲದಿದ್ದರೆ ಈ ಹೋಸ್ಟ್‌ನ ಮುಂದಿನ ಬದಲಾವಣೆ ಅದೇ ಊಹೆಯಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.