Docker ಕಂಟೇನರ್ VPN ಹಿಂದಿನ ಹೋಸ್ಟ್ಗಳನ್ನು ತಲುಪದಿರುವುದೇಕೆ

ಕಾರ್ಪೊರೇಟ್ VPN ಹಿಂದೆ ಯಾವುದಕ್ಕೂ ತಲುಪದ ಕಂಟೇನರ್ ಸಾಮಾನ್ಯವಾಗಿ ಟನೆಲ್ಗಿಂತ ಬೇರೆ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ. ಹೋಸ್ಟ್ ಕ್ಲೈಂಟ್ನ ರೂಟ್ಗಳು, DNS ಸರ್ವರ್ಗಳು ಮತ್ತು ಫೈರ್ವಾಲ್ ಗುರುತುಗಳು ಹೋಸ್ಟ್ನ ಸ್ಟ್ಯಾಕ್ಗೆ ಸೇರಿವೆ; ಬ್ರಿಡ್ಜ್ ನೆಟ್ವರ್ಕ್ ಕಂಟೇನರ್ಗೆ ತನ್ನದೇ ಸ್ಟ್ಯಾಕ್ ಇರುತ್ತದೆ. ಈ ಒಂದು ಸತ್ಯವೇ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ತಂಡಕ್ಕೆ ಬರುವ ಹೆಚ್ಚಿನ ವರದಿಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು «VPN ಮುರಿದಿದೆ» ಹಾಗೂ «Docker VPN ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡುತ್ತದೆ» ಎರಡೂ ಒಂದೇ ಸಮಯದಲ್ಲಿ ತಪ್ಪಾಗಿರಬಹುದು ಎಂಬುದಕ್ಕೂ ಇದೇ ಕಾರಣ. ಒಂದು ಲಕ್ಷಣದ ಹಿಂದೆ ಎರಡು ಸಂಪೂರ್ಣ ಭಿನ್ನ ಸಂರಚನೆಗಳು ಅಡಗಿವೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸುವ ಮೊದಲು ನಿಮ್ಮದು ಯಾವುದೆಂದು ಗುರುತಿಸಿ.

ಟನೆಲ್ ಯಾರ ನೇಮ್ಸ್ಪೇಸ್ನದು ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ

macOS ಅಥವಾ Windows ಗಾಗಿ Docker Desktop ನಲ್ಲಿ ಕಂಟೇನರ್ಗಳು Linux ವರ್ಚುವಲ್ ಯಂತ್ರದ ಒಳಗೆ ಚಲಿಸುತ್ತವೆ. ಡೆಸ್ಕ್ಟಾಪ್ನಲ್ಲಿ ಸ್ಥಾಪಿಸಿದ VPN ಕ್ಲೈಂಟ್ ಡೆಸ್ಕ್ಟಾಪ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಟನೆಲ್ ರಚಿಸುತ್ತದೆ, ಮತ್ತು ವರ್ಚುವಲ್ ಯಂತ್ರ ಅದನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ. ಯಾವುದೇ ಕಂಟೇನರ್ ಸಂರಚನೆ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಕಂಟೇನರ್ಗೆ ಬೇಕಾದ ಇಂಟರ್ಫೇಸ್ ಅದರ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಇಲ್ಲ.

Linux ಹೋಸ್ಟ್ನಲ್ಲಿ ಟನೆಲ್ ಹೋಸ್ಟ್ನ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ, ಮತ್ತು ಬ್ರಿಡ್ಜ್ ಕಂಟೇನರ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಹೊರಹೋಗುವಾಗ ಮೂಲ NAT ಅನ್ವಯಿಸಿದ ಹೋಸ್ಟ್ನ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದ ಮೂಲಕ ಅದನ್ನು ತಲುಪುತ್ತವೆ. ಆ ಮಾರ್ಗ ವಿಫಲವಾದಾಗ, ಕಾರಣ ಸಾಮಾನ್ಯವಾಗಿ ಕಾಣೆಯಾದ ರೂಟ್ ಅಲ್ಲ, ಬದಲಾಗಿ ಫಾರ್ವರ್ಡಿಂಗ್ ನೀತಿ, ರಿವರ್ಸ್-ಪಾತ್ ಫಿಲ್ಟರಿಂಗ್ ಅಥವಾ ಅತಿಪಾತ್ರೆಯ ಸಬ್ನೆಟ್. ಮುಂದೆ ಓದುವ ಮೊದಲು ನೀವು ಎರಡು ಜಗತ್ತುಗಳಲ್ಲಿ ಯಾವುದರಲ್ಲಿದ್ದೀರಿ ಎಂದು ದೃಢೀಕರಿಸಿ:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

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

ಹೋಸ್ಟ್ ನೆಟ್ವರ್ಕಿಂಗ್ ಪರೀಕ್ಷೆ, ವಿನ್ಯಾಸವಲ್ಲ

ಕಂಟೇನರ್ ಅನ್ನು ಹೋಸ್ಟ್ ನೆಟ್ವರ್ಕಿಂಗ್ನೊಂದಿಗೆ ಚಲಾಯಿಸುವುದು, ಅದನ್ನು Docker ಹೋಸ್ಟ್ನ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ಹಂಚಿಕೆ ಎಂದು ದಾಖಲಿಸುತ್ತದೆ, ಅದಕ್ಕೆ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಅದರ ರೂಟ್ಗಳನ್ನು ನೇರವಾಗಿ ಆನುವಂಶಿಕವಾಗಿ ನೀಡುತ್ತದೆ. ಅದೇ ವಿನಂತಿ ನಂತರ ಯಶಸ್ವಿಯಾದರೆ, ರೂಟ್ ಸಿದ್ಧಾಂತ ದೃಢೀಕರಣಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ವೈಫಲ್ಯ ನೇಮ್ಸ್ಪೇಸ್ ಪ್ರತ್ಯೇಕತೆ, ರುಜುವಾತುಗಳು, DNS ಅಥವಾ ಪ್ರವೇಶ ನಿಯಮವಲ್ಲ.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

ಅದನ್ನು ರೋಗನಿರ್ಣಯವಾಗಿ ಇರಿಸಿ. ಹೋಸ್ಟ್ ನೆಟ್ವರ್ಕಿಂಗ್ ಪೋರ್ಟ್ ಪ್ರಕಟಣೆ ಮತ್ತು ಕಂಟೇನರ್ನಿಂದ ನೀವು ಬಯಸಿದ ಪ್ರತ್ಯೇಕತೆಯ ಹೆಚ್ಚಿನ ಭಾಗವನ್ನು ಬಿಟ್ಟುಕೊಡುತ್ತದೆ, ಮತ್ತು Docker Desktop ನಲ್ಲಿ «host» ಎಂದರೆ ವರ್ಚುವಲ್ ಯಂತ್ರ, ಡೆಸ್ಕ್ಟಾಪ್ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಯಾವ ಹೋಸ್ಟ್ ಅನ್ನು ಸಂಬೋಧಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಮರೆತರೆ ಅಲ್ಲಿನ ಯಶಸ್ಸು ಅಥವಾ ವೈಫಲ್ಯ ನಿಮ್ಮನ್ನು ದಾರಿತಪ್ಪಿಸಬಹುದು.

tun ಸಾಧನ ಮತ್ತು ಅದರೊಂದಿಗೆ ಬರುವ ಸವಲತ್ತುಗಳು

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

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

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

ಈ ವಿನ್ಯಾಸವು ಕ್ಲೈಂಟ್ ಪ್ರತಿ ಕಂಟೇನರ್ಗೆ ಚಲಿಸುತ್ತದೆ ಎಂದೂ ಅರ್ಥ. ಪ್ರತಿ ವರ್ಕ್ಲೋಡ್ಗೆ ತನ್ನದೇ ಟನೆಲ್ ಬೇಕಾದಾಗ ಇದು ಸರಿಯಾದ ಉತ್ತರ, ಮತ್ತು ನೀವು ಹೋಸ್ಟ್ನ ಟನೆಲ್ ಕಾಣುವಂತೆ ಮಾಡಲು ಬಯಸಿದ್ದರೆ ತಪ್ಪು ಉತ್ತರ — ಪ್ಲಾಟ್ಫಾರ್ಮ್ ತಂಡವು ನೀವು ಹಾಗೆ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ಊಹಿಸಿತ್ತು.

ಬ್ರಿಡ್ಜ್ NAT VPN ನೋಡುವ ಮೂಲವನ್ನು ಬದಲಿಸುತ್ತದೆ

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

macvlan ಅಥವಾ ipvlan ಬದಲಿಗೆ ಕಂಟೇನರ್ಗೆ LAN ವಿಳಾಸ ನೀಡುತ್ತದೆ, ಅದು LAN ಶೋಧನೆಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕಂಟೇನರ್ ಅನ್ನು ವಿಭಾಗದಲ್ಲಿ ಸಮಾನನಂತೆ ತೋರಿಸುತ್ತದೆ. ಅದು ಹೋಸ್ಟ್ನ ಟನೆಲ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೈಪಾಸ್ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಂತಹ ಕಂಟೇನರ್ VPN-ಮಾತ್ರ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ತಲುಪುವುದಿಲ್ಲ, VPN ಆ LAN ನಿಂದಲೂ ಸುಲಭವಾಗಿಲ್ಲದ ಹೊರತು.

ಎರಡೂ ರೂಪಗಳು ಕಾನೂನುಬದ್ಧ; ಅವು ಬೇರೆ ಬೇರೆ ಅಗತ್ಯಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ. ಅಗತ್ಯ «ಈ ಕಂಟೇನರ್ VPN-ಮಾತ್ರ ಸೇವೆಯನ್ನು ತಲುಪಬೇಕು» ಆಗಿದ್ದರೆ, ನೀವು ಹೋಸ್ಟ್ ಮೂಲಕ ರೂಟಿಂಗ್ ಮತ್ತು ಕಂಟೇನರ್ ಒಳಗೆ ಟನೆಲ್ ಮುಗಿಸುವುದರ ನಡುವೆ ಆಯ್ಕೆ ಮಾಡುತ್ತೀರಿ. ಆ ಆಯ್ಕೆಯನ್ನು ನಿಯೋಜನೆಗೆ ಮೊದಲು ಬರೆಯಿರಿ, ಮೊದಲ ವಿಫಲ ವಿನಂತಿಯ ನಂತರವಲ್ಲ. ಏನೇ ಆರಿಸಿದರೂ, ದೂರದ ತುದಿ ನೋಡುವ ಮೂಲ ವಿಳಾಸವನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಅದರ ಪ್ರವೇಶ ನಿಯಮಗಳು ಮತ್ತು ಅದರ ಲಾಗ್ಗಳು ಅದನ್ನೇ ತೋರಿಸುತ್ತವೆ. ಆ ವಿಳಾಸವನ್ನು ಹೇಳಲಾಗದ ವಿನ್ಯಾಸ ಪೂರ್ಣಗೊಂಡಿಲ್ಲ.

DNS ಡೀಮನ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಟನೆಲ್ ಅನ್ನಲ್ಲ

ಕಂಟೇನರ್ ಪ್ರಾರಂಭವಾದಾಗ ತನ್ನ ರೆಸಾಲ್ವರ್ ಸಂರಚನೆಯನ್ನು ಪಡೆಯುತ್ತದೆ, ಅದು ಡೀಮನ್ ಅಥವಾ ಇಮೇಜ್ನಿಂದ ನಕಲಿಸಲ್ಪಟ್ಟಿರುತ್ತದೆ. VPN ಸಂಪರ್ಕಗೊಂಡ ನಂತರ ತಳ್ಳುವ ವಿಳಾಸಗಳು ಆ ನಕಲಿಗೆ ತುಂಬಾ ತಡವಾಗಿ ಬರುತ್ತವೆ, ಮತ್ತು ಅವು ಕಂಟೇನರ್ಗೆ ಅಲ್ಲ, ಹೋಸ್ಟ್ ರೆಸಾಲ್ವರ್ಗೆ ತಳ್ಳಲ್ಪಡುತ್ತವೆ.

ಸೇವೆಗಾಗಿ ರೆಸಾಲ್ವರ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೊಂದಿಸಿ, ಅಥವಾ ಟನೆಲ್ ಮೂಲಕ ಸುಲಭವಾಗಿರುವ ಆಂತರಿಕ ರೆಸಾಲ್ವರ್ಗೆ ತೋರಿಸಿ. ಖಾಸಗಿ ಹೆಸರನ್ನು ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುವ ಕಂಟೇನರ್ ಸಾಮಾನ್ಯವಾಗಿ ಸಾರ್ವಜನಿಕ ರೆಸಾಲ್ವರ್ ಬಳಸುತ್ತದೆ, ಮುರಿದ ರೂಟ್ನಿಂದ ಬಳಲುತ್ತಿಲ್ಲ, ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆ compose ಫೈಲ್ ಅಥವಾ ಡೀಮನ್ ಸಂರಚನೆಗೆ ಸೇರುತ್ತದೆ.

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

ಟಿಕೆಟ್ ಮುಚ್ಚುವ ಮೊದಲು ಪರಿಶೀಲನಾ ಪಟ್ಟಿ: ಟನೆಲ್ ಹೊಂದಿರುವ ನೇಮ್ಸ್ಪೇಸ್ ಗುರುತಿಸಿ, ಹೋಸ್ಟ್ ನೆಟ್ವರ್ಕಿಂಗ್ನಿಂದ ಮಾರ್ಗ ಸಾಬೀತುಪಡಿಸಿ, ಬೇಕಾದ tun ಸಾಧನವನ್ನು ಮಾತ್ರ ನಕ್ಷೆ ಮಾಡಿ, NAT ನಂತರದ ಮೂಲ ವಿಳಾಸ ನೆನಪಿಡಿ, ರೆಸಾಲ್ವರ್ ಸ್ಪಷ್ಟವಾಗಿ ಹೊಂದಿಸಿ ಮತ್ತು ಪ್ರತಿ-ಕಂಟೇನರ್ ನಿರ್ಗಮನ ವಿಳಾಸಗಳನ್ನು ಫ್ಲ್ಯಾಗ್ ಅಲ್ಲ, ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರವಾಗಿ ಪರಿಗಣಿಸಿ.