VPN ಕಂಟೇನರ್ನಲ್ಲಿ DNAT: INPUT ಅಲ್ಲ, ಫಾರ್ವರ್ಡಿಂಗ್

ಬೇಡಿಕೆ ಟನೆಲ್ IP ವಿಳಾಸಕ್ಕೆ ಬಂದು ಅದೇ ಕಂಟೇನರ್ನಿಂದ ನೆರೆಯ ಸೇವೆಯ ವಿಳಾಸಕ್ಕೆ ಹೊರಡುತ್ತದೆ. ಈ ಎರಡು ಕ್ಷಣಗಳ ನಡುವೆ DNAT ಗಮ್ಯವನ್ನು ಮತ್ತೆ ಬರೆದಿದೆ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ VPN ಕಂಟೇನರ್ಗೆ ಇನ್ಪುಟ್ ಆಗಿರುವುದನ್ನು ನಿಲ್ಲಿಸಿತು. ಈಗ ಅದು ಫಾರ್ವರ್ಡ್ ಆದ ಸಂಚಾರ, ಬೇರೆ ನಿಯಮದಿಂದ ನಿರ್ಣಯಿಸಲ್ಪಡುತ್ತದೆ. ಈ ಬದಲಾವಣೆಯೇ ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಸರಿಯಾಗಿ ಕಾಣುವ ಫೈರ್ವಾಲ್ ನಿಯಮವು ಅನುವಾದಿತ ಸಂಪರ್ಕದ ಮೇಲೆ ಯಾಕೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಅನುವಾದದ ನಂತರ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅನುಸರಿಸಿ

10.90.0.0/24 ಕ್ಲೈಂಟ್ ಪೂಲ್ ಮತ್ತು 10.90.0.1 ಟನೆಲ್ ವಿಳಾಸವನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ. ಒಂದೇ ಸೇತುವೆಯ ಮೇಲೆ ಎರಡು ಕಂಟೇನರ್ಗಳಿವೆ: 192.0.2.2 VPN ಅನ್ನು, 192.0.2.3 ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಡೆಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ 10.90.0.1:8080 ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಮತ್ತು VPN ಕಂಟೇನರ್ನ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿರುವ DNAT ನಿಯಮ ಅದನ್ನು ಅಪ್ಲಿಕೇಶನ್ನ ನಿಜವಾದ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ಗೆ ಮತ್ತೆ ಬರೆಯುತ್ತದೆ. ನಂತರ ಮಾರ್ಗವು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸೇತುವೆಯ ಮೇಲೆ ಕಳುಹಿಸುತ್ತದೆ. ಈ ವಿಳಾಸಗಳು ಉದಾಹರಣೆಗಾಗಿ, ನಿಯೋಜನೆ ಪಾಕವಿಧಾನವಲ್ಲ.

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

ಅನುಮತಿ ಫಾರ್ವರ್ಡ್ ಮಾರ್ಗದಲ್ಲಿದೆ

VPN ಕಂಟೇನರ್ಗೆ IP ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಪೂಲ್, ಅಪ್ಲಿಕೇಶನ್ ವಿಳಾಸ ಮತ್ತು ಉದ್ದೇಶಿತ ಪೋರ್ಟ್ಗೆ ಸೀಮಿತವಾದ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿರ್ಣಯ ಬೇಕು. ಸ್ಥಾಪಿತ ಪ್ರತ್ಯುತ್ತರಗಳಿಗೆ ತಮ್ಮದೇ ಅನುಮತಿ ಬೇಕು. ಮೂಲ ಟನೆಲ್ ವಿಳಾಸಕ್ಕೆ ಹೊಂದುವ ನಿಯಮ DNAT ನಂತರ ಹೊಂದುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಗಮ್ಯ ಈಗಾಗಲೇ ಬದಲಾಗಿದೆ. INPUT ಅನುಮತಿ ಈಗ ಈ ಹೋಸ್ಟ್ಗೆ ಉದ್ದೇಶಿಸದ ಸಂಚಾರಕ್ಕೆ ತಪ್ಪು ಕೊಕ್ಕೆ.

ವ್ಯಾಪ್ತಿಯನ್ನು ಸಂಕುಚಿತವಾಗಿಡಿ: ಒಂದು ಮೂಲ ಶ್ರೇಣಿ, ಒಂದು ಗಮ್ಯ, ಒಂದು ಸೇವೆ. ಸಡಿಲವಾದ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮವನ್ನು ಬರೆಯುವುದು ಸುಲಭ ಮತ್ತು ನಂತರ ಸಮರ್ಥಿಸುವುದು ಬಹಳ ಕಷ್ಟ.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Docker ನ ಸರಣಿಗಳು ನಿಮ್ಮ ಕಂಟೇನರ್ನ ಸರಣಿಗಳಲ್ಲ

ಕಂಟೇನರ್ ನೇಮ್ಸ್ಪೇಸ್ ಒಳಗಿನ ನಿಯಮಗಳು Docker ಹೋಸ್ಟ್ನ ನಿಯಮಗಳಲ್ಲ. ಸಂಚಾರ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ನಿಂದ ಸೇತುವೆಗೆ ದಾಟುವಾಗ, ಹೋಸ್ಟ್ನ ಸೇತುವೆ ಫೈರ್ವಾಲ್ ಬೇರೆ ನಿರ್ಣಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. Docker ನ iptables ಬ್ಯಾಕೆಂಡ್ನೊಂದಿಗೆ, ದಾಖಲಿತ ಫಾರ್ವರ್ಡಿಂಗ್ ಸರಣಿಗಳು ಮತ್ತು DNAT ನಂತರದ ಹೊಂದಾಣಿಕೆ ಬಿಂದುಗಳು ಆ ನಿರ್ಣಯ ಕಾಣಿಸುವ ಸ್ಥಳ.

Docker ಫೈರ್ವಾಲ್ ಉಲ್ಲೇಖ ಆ ಸರಣಿಗಳನ್ನು ಮತ್ತು DNAT ನಂತರದ ಹೊಂದಾಣಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. Docker ನ ಫೈರ್ವಾಲ್ ನಿರ್ವಹಣೆಯನ್ನು ಆಫ್ ಮಾಡಿ ಅಥವಾ ಪ್ರತಿ ಸರಣಿಯನ್ನು ಸಡಿಲಗೊಳಿಸಿ ಕಾಣೆಯಾದ ಒಪ್ಪಿಗೆಯನ್ನು ಸರಿಪಡಿಸಬೇಡಿ, ಏಕೆಂದರೆ ಅದು ನೀವು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಗಡಿಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕ ಆಯ್ಕೆಯಾಗಿಸಿ

ಮೂಲ ವಿಳಾಸವನ್ನು ಉಳಿಸಿಕೊಂಡರೆ, ಅಪ್ಲಿಕೇಶನ್ 10.90.0.x ಅನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಪ್ರತ್ಯುತ್ತರಗಳನ್ನು VPN ಕಂಟೇನರ್ ಮೂಲಕ ಹಿಂತಿರುಗಿಸಬೇಕು. ಇಲ್ಲದಿದ್ದರೆ ಅದರ ಸಾಮಾನ್ಯ Docker ಗೇಟ್ವೇ ಅವುಗಳನ್ನು ಹೋಸ್ಟ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಅದು ಟನೆಲ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ. ಪರ್ಯಾಯವೆಂದರೆ VPN ಕಂಟೇನರ್ನಲ್ಲಿ ಸಂಕುಚಿತ ಮೂಲ ಅನುವಾದ, ಅದು ಪ್ರತ್ಯುತ್ತರವನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ನಿಂದ ಕ್ಲೈಂಟ್ ಅನ್ನು ಮರೆಮಾಡುತ್ತದೆ. ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆರಿಸಿ ಮತ್ತು ಯಾವುದನ್ನು ಆರಿಸಿದಿರಿ ಎಂದು ಬರೆಯಿರಿ.

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

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