Docker ಪೋರ್ಟ್ ಪ್ರಕಟಣೆ ಮತ್ತು VPN ಮೂಲಗಳು: ನೀವು ತಪ್ಪಿಸಿಕೊಳ್ಳುವ ಎರಡು ಹೊಂದಾಣಿಕೆಗಳು

ನಿಯಮವು VPN ಸರ್ವರ್‌ನ ವಿಳಾಸವನ್ನು ಪ್ರಕಟಿತ ಸೇವೆಗೆ ಅನುಮತಿಸಿ ಎಂದು ಹೇಳುತ್ತದೆ, ಆದರೂ ಸಂಪರ್ಕ ಕಡಿತಗೊಳ್ಳುತ್ತದೆ. ಈ ಫಲಿತಾಂಶ ಸಾಮಾನ್ಯವಾದದ್ದು, ಮತ್ತು ಅದು Docker ದೋಷವಲ್ಲ. ಎರಡು ಪ್ರತ್ಯೇಕ ಹೊಂದಾಣಿಕೆಗಳು ತಪ್ಪಾಗಿವೆ: ನೀವು ಬರೆದ ಮೂಲವು ಹೋಸ್ಟ್ ಸ್ವೀಕರಿಸುವ ಮೂಲವಾಗಿರದಿರಬಹುದು, ಮತ್ತು ನೀವು ಬರೆದ ಪೋರ್ಟ್ ಫಿಲ್ಟರ್ ನೋಡುವ ಪೋರ್ಟ್ ಆಗಿರದಿರಬಹುದು. ಎರಡನ್ನೂ ಸರಿಪಡಿಸಲು ಸೇವೆಯ ರೇಖಾಚಿತ್ರದ ಬದಲು ಪ್ಯಾಕೆಟ್‌ನ ಮಾರ್ಗವನ್ನು ನೋಡಬೇಕು.

ಕಟ್ಟುಕಥೆ: VPN ಸರ್ವರ್‌ಗೆ ಅನುಮತಿಸಿ, ಕೆಲಸ ಮುಗಿಯಿತು

ರೂಟ್ ಮಾಡಿದ VPN ಕ್ಲೈಂಟ್‌ನ ಟನಲ್ ವಿಳಾಸವನ್ನು Docker ಹೋಸ್ಟ್‌ವರೆಗೆ ಉಳಿಸಿಕೊಳ್ಳಬಹುದು. ಮೂಲ ಅನುವಾದ ಮಾಡುವ ಗೇಟ್‌ವೇ ಆ ವಿಳಾಸವನ್ನು ತನ್ನದರಿಂದ ಬದಲಾಯಿಸಬಹುದು. ಎರಡೂ ವಿನ್ಯಾಸಗಳು ಸರಿಯಾದವು, ಮತ್ತು ಅವು ಒಂದೇ ಬಳಕೆದಾರ ಕ್ರಿಯೆಗೆ ಬೇರೆ ಬೇರೆ ಮೂಲಗಳನ್ನು ನೀಡುತ್ತವೆ.

ಹಾಗಾಗಿ VPN ಸರ್ವರ್ IP ಎಂಬ ಪದಗುಚ್ಛವು ಊಹೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ವೀಕ್ಷಣೆಯನ್ನಲ್ಲ. ನಿಮ್ಮ ಮುಂದೆ ಎರಡು ವಿನ್ಯಾಸಗಳಲ್ಲಿ ಯಾವುದು ಇದೆ ಎಂದು ತಿಳಿಯುವವರೆಗೆ, ನಿಯಮವು ಒಂದು ಊಹೆ.

ಮೂಲ: ಕ್ಲೈಂಟ್ ಪೂಲ್ ಅಥವಾ ಅನುವಾದಿತ ಗೇಟ್‌ವೇ

ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ಕ್ರಮವಾಗಿ ಪರಿಶೀಲಿಸಿ. ಮೊದಲನೆಯದು, ಕ್ಲೈಂಟ್ ವಿಳಾಸ ಪೂಲ್, ಉದಾಹರಣೆಗೆ 10.90.0.0/24. ಎರಡನೆಯದು, ಗೇಟ್‌ವೇ ಆ ಪೂಲ್ ಅನ್ನು ಹೋಸ್ಟ್‌ಗೆ ತಲುಪುವ ಮೊದಲು ಅನುವಾದಿಸುತ್ತದೆಯೇ. ಮೂರನೆಯದು, ಒಂದು ಹೊಸ ಸಂಪರ್ಕಕ್ಕೆ ಹೋಸ್ಟ್ ನಿಜವಾಗಿ ವೀಕ್ಷಿಸುವ ಮೂಲ. ನಾಲ್ಕನೆಯದು, ಅಪ್ಲಿಕೇಶನ್ ದೃಢೀಕರಣವು ವೈಯಕ್ತಿಕ ಬಳಕೆದಾರರನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆಯೇ, ಏಕೆಂದರೆ ಹಂಚಿದ ಅನುವಾದಿತ ವಿಳಾಸವು ಅದನ್ನು ಮಾಡಲಾರದು.

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

ಪೋರ್ಟ್: DNAT ನೀವು ಹೊಂದಿಸುವ ಸಂಖ್ಯೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ

Docker iptables ಜೊತೆಗಿನ ಸಾಮಾನ್ಯ Linux ಸೇತುವೆ ಪ್ರಕಟಣೆಯಲ್ಲಿ, 8443 ರಿಂದ ಕಂಟೇನರ್ ಪೋರ್ಟ್ 443 ಗೆ ಹೋಸ್ಟ್ ಮ್ಯಾಪಿಂಗ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಫಿಲ್ಟರ್ ಚಾಲನೆಯ ಮೊದಲೇ ಅನುವಾದಗೊಳ್ಳುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ಫಿಲ್ಟರ್‌ಗೆ ಗಮ್ಯ ಪೋರ್ಟ್ 443 ಜೊತೆಗೆ ತಲುಪುತ್ತದೆ. ಆ ಹಂತದಲ್ಲಿ 8443 ಗೆ ಹೊಂದುವ ನಿಯಮ ಎಂದಿಗೂ ಸಕ್ರಿಯಗೊಳ್ಳುವುದಿಲ್ಲ, ಕ್ಲೈಂಟ್ ಟೈಪ್ ಮಾಡಿದ್ದು 8443 ಆಗಿದ್ದರೂ.

ಪ್ರಕಟಿತ ಪೋರ್ಟ್ ಇನ್ನೂ ಸಂಪರ್ಕ ಟ್ರ್ಯಾಕಿಂಗ್‌ನಲ್ಲಿ ಇದೆ, ಆದ್ದರಿಂದ ನಿಜವಾಗಿ ಬೇಕಾದಾಗ ಮೂಲ ಗಮ್ಯವನ್ನು ಅಲ್ಲಿ ಹೊಂದಿಸಬಹುದು.

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

ಸರಪಳಿ: DOCKER-USER, INPUT ಅಲ್ಲ

Docker ನ iptables ಮಾರ್ಗದರ್ಶಿಯು ಬಳಕೆದಾರ ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿಯನ್ನು DOCKER-USER ಸರಪಳಿಯಲ್ಲಿ ಇಡುತ್ತದೆ, ಅದು Docker ನ ಸ್ವಂತ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮಗಳ ಮೊದಲು ಮೌಲ್ಯಮಾಪನಗೊಳ್ಳುತ್ತದೆ. ಹೋಸ್ಟ್ ಸೇವೆಯಿಂದ INPUT ಸರಪಳಿಗೆ ನಕಲಿಸಿದ ನಿಯಮವು ಹೋಸ್ಟ್‌ಗೆ ಉದ್ದೇಶಿಸಿದ ಸಂಚಾರವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ, ಕಂಟೇನರ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಆಗುವ ಸಂಚಾರವನ್ನಲ್ಲ. ಆ ತಪ್ಪು ಸರಿಯಾಗಿ ಕಾಣುವ ಮತ್ತು ಕಂಟೇನರ್ ಮಾರ್ಗದ ಮೇಲೆ ಯಾವುದೇ ಪರಿಣಾಮವಿಲ್ಲದ ನಿಯಮವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

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

ಹೊಸ ಸಂಪರ್ಕಗಳಿಂದ ಪರಿಶೀಲಿಸಿ

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

ಈ ಪರಿಶೀಲನೆಗಳ ಹಿಂದಿನ ಸರಪಳಿ ಕ್ರಮ ಮತ್ತು ಪೋರ್ಟ್ ಅನುವಾದದ ವರ್ತನೆಯನ್ನು Docker ನ iptables ಮಾರ್ಗದರ್ಶಿ ದಾಖಲಿಸುತ್ತದೆ. ಯಾವುದೇ ಪಾಕವಿಧಾನವನ್ನು ನಕಲಿಸುವ ಮೊದಲು ಅದನ್ನು ಓದಿ, ಮತ್ತು ಸ್ಥಾಪಿತ Docker ಯಾವ ಬ್ಯಾಕೆಂಡ್ ಬಳಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ nftables ಬ್ಯಾಕೆಂಡ್ ನೀತಿಯನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಸಂಯೋಜಿಸುತ್ತದೆ.