Dev Container ਸਿਰਫ਼ 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 ਸੰਰਚਨਾ ਹੈ। ਜੋ VPN ਕਲਾਇੰਟ ਰੂਟ ਸਥਾਪਤ ਕਰਦਾ ਹੈ ਪਰ DNS ਨਹੀਂ, ਜਾਂ ਅਜਿਹਾ DNS ਸਰਵਰ ਧੱਕਦਾ ਹੈ ਜਿਸ ਤੱਕ VM ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ, ਉਹ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਨਾਮ ਖੋਜ ਅਸਫਲਤਾ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਹੋਸਟ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਉਸ ਕੋਲ ਵਾਧੂ 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, ਐਡੀਟਰ ਅਤੇ ਇੰਜਣ ਨੂੰ ਵਾਰੀ-ਵਾਰੀ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਲੱਛਣ ਬਦਲ ਸਕਦਾ ਹੈ, ਪਰ ਅਗਲੇ ਵਿਅਕਤੀ ਦੇ ਕੰਮ ਆਉਣ ਵਾਲਾ ਕੁਝ ਨਹੀਂ ਛੱਡਦਾ।