Dev Container VPN-only ಹೋಸ್ಟ್ ತಲುಪುತ್ತಿಲ್ಲ: ಎಲ್ಲಿ ನೋಡಬೇಕು

ಬ್ರೌಸರ್ ಮತ್ತು ಕಂಟೇನರ್‌ಗಳ resolver, proxy ಮತ್ತು ಮಾರ್ಗ ಸಂದರ್ಭಗಳು ಬೇರೆ ಬೇರೆ. ಯಾವುದೇ VPN ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸುವ ಮೊದಲು ವಿಫಲವಾಗುತ್ತಿರುವ ಪ್ರಕ್ರಿಯೆ ಯಾವುದನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ.

ಖಾಸಗಿ API ನಿಮ್ಮ ಡೆಸ್ಕ್‌ಟಾಪ್ ಬ್ರೌಸರ್‌ನಲ್ಲಿ ತೆರೆಯುತ್ತದೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಕಂಟೇನರ್‌ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ಇದು ವಿರೋಧಾಭಾಸವಲ್ಲ, ಮತ್ತು ಅಪರೂಪವಾಗಿ VPN ಸ್ವತಃ ಕಾರಣವಾಗಿರುತ್ತದೆ. ಬ್ರೌಸರ್‌ನ ವಿನಂತಿ ಮತ್ತು ವಿಫಲವಾದ ವಿನಂತಿಯನ್ನು ಬೇರೆ ಬೇರೆ ಪ್ರಕ್ರಿಯೆಗಳು ಮಾಡಿವೆ, ಬೇರೆ ಬೇರೆ resolver, proxy ಮತ್ತು ಮಾರ್ಗಗಳೊಂದಿಗೆ, ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ನೆಟ್‌ವರ್ಕ್ ಹೆಸರಿನ ಸ್ಥಳಗಳಿಂದ. “ನನ್ನ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ” ಎಂದರೆ Windows ಹೋಸ್ಟ್, WSL ವಿತರಣೆ, Docker Desktop ವರ್ಚುವಲ್ ಯಂತ್ರ ಮತ್ತು ಆ VM ಒಳಗಿನ ಕಂಟೇನರ್ ಆಗಿರಬಹುದು — ಒಂದೇ ಹೋಸ್ಟ್‌ಹೆಸರಿಗೆ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಉತ್ತರ ನೀಡಬಹುದಾದ ನಾಲ್ಕು ಸಂದರ್ಭಗಳು. ಒಂದೇ ಸೆಟ್ಟಿಂಗ್ ಮುಟ್ಟುವ ಮೊದಲು ವಿಫಲವಾಗುತ್ತಿರುವ ಪ್ರಕ್ರಿಯೆ ಯಾವುದನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ.

ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸುವ ಮೊದಲು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹುಡುಕಿ

VPN ಕ್ಲೈಂಟ್‌ನಿಂದ ಅಲ್ಲ, ಕಂಟೇನರ್ ಎಂಜಿನ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ. ಆದೇಶ ಸಾಲು ಯಾವ ಸಂದರ್ಭದೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಿದೆ ಮತ್ತು ಆ ಎಂಜಿನ್ ಯಾವ ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಎಂದು ಕೇಳಿ, ಏಕೆಂದರೆ ಡೆಸ್ಕ್‌ಟಾಪ್ VM ನಿರ್ವಹಿಸುವ Linux ಕಂಟೇನರ್ ಸ್ಥಳೀಯ ಡೀಮನ್ ನಿರ್ವಹಿಸುವುದಕ್ಕಿಂತ ಬೇರೆ ದಾರಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ:

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Windows ನಲ್ಲಿ, wsl -l -v ವಿತರಣೆಯು WSL 2 ಅಡಿಯಲ್ಲಿ ಚಲಿಸುತ್ತಿದೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ, ಇದು ಅದನ್ನು ತನ್ನದೇ ವರ್ಚುವಲ್ ಸ್ವಿಚ್‌ನ ಹಿಂದೆ ಇಡುತ್ತದೆ. ಆ ವಿವರವೇ ಕಂಟೇನರ್ ಹೋಸ್ಟ್‌ನ ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತದೆಯೇ ಅಥವಾ ಹೋಸ್ಟ್ ತಲುಪಲು ಮುಂದುವರಿಸಿದ ಪೋರ್ಟ್ ಅಥವಾ ಹೋಸ್ಟ್‌ಹೆಸರು ಬೇಕಾದ NAT ಹಿಂದೆ ಕುಳಿತಿದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಒಂದು ವಿನಂತಿಯನ್ನು ಸ್ಥಿರವಾಗಿಡಿ ಮತ್ತು ಹೋಲಿಸಿ

ಖಾಸಗಿ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಒಂದು ನಿರುಪದ್ರವ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಆರಿಸಿ ಮತ್ತು ಪ್ರತಿ ಹೋಲಿಕೆಗೂ ಅದನ್ನೇ ಬಳಸಿ: ಬ್ರೌಸರ್‌ನಿಂದ, ಹೋಸ್ಟ್ ಟರ್ಮಿನಲ್‌ನಿಂದ, WSL ವಿತರಣೆಯಿಂದ ಮತ್ತು ಕಂಟೇನರ್ ಒಳಗಿನಿಂದ. ಪ್ರತಿ ಪ್ರಯತ್ನಕ್ಕೂ ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ದಾಖಲಿಸಿ: ಪರಿಹರಿಸಿದ ವಿಳಾಸ, proxy ಬಳಸಲಾಯಿತೇ, ವೈಫಲ್ಯದ ವರ್ಗ ಮತ್ತು ಕಳೆದ ಸಮಯ. ಹೆಸರು ಹುಡುಕಾಟ, ಸಂಪರ್ಕ ಸ್ಥಾಪನೆ, TLS ಮಾನ್ಯತೆ ಮತ್ತು HTTP ಸ್ಥಿತಿ ನಾಲ್ಕು ಬೇರೆ ಸಮಸ್ಯೆಗಳು, ಮತ್ತು ಅವನ್ನು “ಕೆಲಸ ಮಾಡುತ್ತಿಲ್ಲ” ಎಂದು ಮಿಶ್ರ ಮಾಡುವುದು ಒಂದು ಬೆಳಗ್ಗೆಯನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.

ಹೋಲಿಕೆಯನ್ನು ವಿಫಲವಾಗುತ್ತಿರುವ ಕಂಟೇನರ್ ಒಳಗೇ, ಟೈಮ್‌ಔಟ್‌ನೊಂದಿಗೆ ನಡೆಸಿ, ಮೌನ ಫೈರ್‌ವಾಲ್ ಟರ್ಮಿನಲ್ ಅನ್ನು ನಿಮಿಷಗಳ ಕಾಲ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳದಿರಲಿ. ಹೊಸ ಕಂಟೇನರ್ ಎಂಜಿನ್‌ನ ನೆಟ್‌ವರ್ಕ್ ಸಂದರ್ಭವನ್ನು ಮರುಸೃಷ್ಟಿಸುತ್ತದೆ, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಕಂಟೇನರ್‌ನ ಹೆಸರಿನ ಸ್ಥಳ, proxy ಚರಗಳು ಅಥವಾ resolver ಅನ್ನು ಅಲ್ಲ, ಆದ್ದರಿಂದ ನಿಜವಾದ ಕಂಟೇನರ್‌ಗೆ docker exec ಮಾಡುವುದೇ ಪ್ರಾಮಾಣಿಕ ಪರೀಕ್ಷೆ, ಮತ್ತು ಪಾರ್ಶ್ವ ಕಂಟೇನರ್ ವ್ಯತ್ಯಾಸ ಎಂಜಿನ್‌ನಲ್ಲಿದೆಯೇ ಕಂಟೇನರ್‌ನಲ್ಲಿದೆಯೇ ಎಂದು ಪ್ರತ್ಯೇಕಿಸುವ ಸಾಧನ ಮಾತ್ರ:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

alpine ಮೂಲ ಚಿತ್ರದಲ್ಲಿ busybox ಇದೆ ಮತ್ತು curl ಇಲ್ಲ, ಮತ್ತು ಇದೇ ರೀತಿಯ ವಿವರವೇ ನಕಲಿಸಿದ ರೋಗನಿರ್ಣಯ ಬ್ಲಾಕ್ ವಿಫಲವಾಗಲು ಕಾರಣ: ಕ್ಲೈಂಟ್ ಇರುವ ಚಿತ್ರವನ್ನು ಆರಿಸಿ, ಅಥವಾ ಅದನ್ನು ಅದೇ ರನ್‌ನಲ್ಲಿ ಸೇರಿಸಿ. ಸಂಬಂಧವಿಲ್ಲದ ಸಾರ್ವಜನಿಕ ಸೈಟ್‌ಗಳೊಂದಿಗೆ ಹೋಲಿಕೆ ಏನನ್ನೂ ಪ್ರತ್ಯೇಕಿಸುವುದಿಲ್ಲ. ಕಂಟೇನರ್‌ನಿಂದ https://example.com ಕೆಲಸ ಮಾಡಿದರೆ, ಕಂಟೇನರ್‌ಗೆ ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶ ಇದೆ ಎಂದು ತಿಳಿದೀತು, ಮತ್ತು ಟನೆಲ್ ಮೂಲಕ ಖಾಸಗಿ ವಿಳಾಸ ತಲುಪುತ್ತದೆಯೇ ಎಂಬುದು ತಿಳಿಯದು. ಅದೇ ರೀತಿ, ಹೊಸ ಟರ್ಮಿನಲ್ ತೆರೆಯುವುದು ಹೊಸ ಟರ್ಮಿನಲ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದಷ್ಟೇ ಸಾಬೀತು ಮಾಡುತ್ತದೆ, ವಿಫಲವಾದ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಒಂದೇ ರನ್‌ಟೈಮ್ ಹಂಚಿಕೊಳ್ಳುತ್ತದೆ ಎಂದಲ್ಲ.

Docker Desktop VPN ಜೊತೆ ಕೆಲಸ ಮಾಡಬಹುದು

Docker ನ ಸ್ವಂತ VPN ಮತ್ತು ಹೋಸ್ಟ್ ಸಂಪರ್ಕದ ಕುರಿತ ದಾಖಲೆ ಇದನ್ನು ಬೆಂಬಲಿತ ಸಂರಚನೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರಾಮಾಣಿಕ ಸಾರಾಂಶ ಎಂದರೆ ಅದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮುರಿದಿಲ್ಲ, ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಡೆಸ್ಕ್‌ಟಾಪ್ VM ವಿನ್ಯಾಸದಿಂದಲೇ ಹೋಸ್ಟ್ ಟನೆಲ್ ಬೈಪಾಸ್ ಮಾಡುತ್ತದೆ ಎಂದು ಭಾವಿಸಬೇಡಿ; ಅನೇಕ ಸಂರಚನೆಗಳಲ್ಲಿ ಸಂಚಾರ ಹೋಸ್ಟ್ ಟನೆಲ್ ಅನ್ನು ಸರಿಯಾಗಿ ಅನುಸರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದಲೇ “Docker VPN ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ” ಎಂಬ ಕಟ್ಟುಕಥೆ ಆತ್ಮವಿಶ್ವಾಸದ ಮತ್ತು ತಪ್ಪಾದ ಸಲಹೆ ನೀಡುತ್ತದೆ.

ಇನ್ನೂ ಮುಖ್ಯವಾದುದು ಬಳಸಿದ backend, ಕ್ಲೈಂಟ್‌ನ split-tunnel ನೀತಿ ಮತ್ತು VM ಪಡೆದ resolver ಸಂರಚನೆ. ಮಾರ್ಗಗಳನ್ನು ಸ್ಥಾಪಿಸುವ ಆದರೆ DNS ಅಲ್ಲದ VPN ಕ್ಲೈಂಟ್, ಅಥವಾ VM ತಲುಪಲಾಗದ DNS ಸರ್ವರ್ ಅನ್ನು ತಳ್ಳುವ ಕ್ಲೈಂಟ್, ಕಂಟೇನರ್ ಒಳಗೆ ಹೆಸರು ಹುಡುಕಾಟ ವೈಫಲ್ಯ ಉಂಟುಮಾಡುತ್ತದೆ, ಆದರೆ ಹೋಸ್ಟ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ಅದಕ್ಕೆ ಹೆಚ್ಚುವರಿ resolver ಅಥವಾ ಕ್ಯಾಶ್ ಮಾಡಿದ ಉತ್ತರ ಇದೆ. ಇದು ಕಂಟೇನರ್ ವೇಷದಲ್ಲಿ resolver ಸಮಸ್ಯೆ. ನೀವು ಪ್ರಯತ್ನಿಸುವ ಪ್ರತಿ VPN ಮರುಸಂಪರ್ಕವನ್ನೂ ಇದು ಉಳಿದುಕೊಳ್ಳುತ್ತದೆ, ಏಕೆಂದರೆ ಟನೆಲ್ ಈಗಾಗಲೇ ನೀವು ಕೇಳಿದ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುತ್ತಿದೆ.

ವಿಳಾಸ ಅತಿಕ್ರಮಣ ಮತ್ತು MTU ಬೇರೆ ವೈಫಲ್ಯಗಳು

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

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

ಎರಡನೆಯದು MTU ಸಮಸ್ಯೆ. ಸಂಪರ್ಕ ಸ್ಥಾಪನೆಯಾಗಿ TLS ಪೂರ್ಣಗೊಂಡರೂ ದೊಡ್ಡ ಪ್ರತಿಕ್ರಿಯೆಗಳು ನಿಂತುಕೊಂಡರೆ, ಅದು ಪ್ಯಾಕೆಟ್ ಗಾತ್ರದ ಸಮಸ್ಯೆ, ಅನುಮತಿಯದ್ದಲ್ಲ, ಮತ್ತು DNS ದಾಖಲೆಗಳನ್ನು ಬದಲಿಸುವುದು ಅದನ್ನು ಎಂದಿಗೂ ಸರಿಪಡಿಸುವುದಿಲ್ಲ. ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಸಣ್ಣ ಮತ್ತು ದೊಡ್ಡ ವಿನಂತಿಯೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ, ಎರಡೂ ಫಲಿತಾಂಶಗಳನ್ನು ದಾಖಲಿಸಿ.

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

Proxy ಸಂರಚನೆ ಪ್ರಕ್ರಿಯೆಗೆ, ಯಂತ್ರಕ್ಕಲ್ಲ

ಕಂಟೇನರ್ ಒಳಗೆ, localhost ಆ ಕಂಟೇನರ್‌ನ ಸ್ವಂತ ನೆಟ್‌ವರ್ಕ್ ಸಂದರ್ಭವನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಚಲಿಸುವ proxy ಅಲ್ಲಿಗೆ ಆ ಹೆಸರಿನಲ್ಲಿ ತಲುಪಲಾಗದು. Docker Desktop ಹೋಸ್ಟ್ ಪ್ರವೇಶಕ್ಕಾಗಿ host.docker.internal ಒದಗಿಸುತ್ತದೆ, ಮತ್ತು Linux ನಲ್ಲಿ ನೀವು ಅದನ್ನು --add-host=host.docker.internal:host-gateway ಮೂಲಕ ಸ್ಪಷ್ಟವಾಗಿ ಸೇರಿಸುತ್ತೀರಿ. ಹೇಗಿದ್ದರೂ, ಆ ಹೆಸರು ನಿಮಗೆ ಹೋಸ್ಟ್‌ಗೆ ಮಾರ್ಗ ನೀಡುತ್ತದೆ; ಅದು proxy ಸೇವೆಯನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅದನ್ನು ಬಳಸಲು ಅನುಮತಿ ಕೂಡ ನೀಡುವುದಿಲ್ಲ.

ನಿಜವಾದ ಪರಿಸರಕ್ಕಾಗಿ ಒದಗಿಸಿದ proxy ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಬಳಸಿ, ಮತ್ತು ಅವನ್ನು ಯಾರು ಓದುತ್ತಿದ್ದಾರೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಸಂವಾದಾತ್ಮಕ ಶೆಲ್‌ನಲ್ಲಿ ರಫ್ತು ಮಾಡಿದ ಚರಗಳು ಪ್ರತಿ ಎಡಿಟರ್ ವಿಸ್ತರಣೆ, ಭಾಷಾ ಸರ್ವರ್, ಬಿಲ್ಡ್ ಸಾಧನ ಮತ್ತು ಹಿನ್ನೆಲೆ ಡೀಮನ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಂರಚಿಸುವುದಿಲ್ಲ. ಮುಖ್ಯವಾದುದು ವಿಫಲ ವಿನಂತಿ ಮಾಡಿದ ಪ್ರಕ್ರಿಯೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಟರ್ಮಿನಲ್‌ನದಲ್ಲ, ಅದರ ಪರಿಸರವನ್ನು ಪರಿಶೀಲಿಸಿ.

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

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