ਹੋਸਟ VPN ਨੂੰ ਅਣਡਿੱਠਾ ਕਰਨ ਵਾਲੇ Docker ਅਤੇ WSL ਟ੍ਰੈਫਿਕ ਨੂੰ ਠੀਕ ਕਰੋ

ਇਸ ਬਸੰਤ ਮੈਂ ਇੱਕ ਸਵੇਰ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਇੱਕ ਕੰਟੇਨਰ ਦੇ ਪਿੱਛੇ ਲੱਗ ਕੇ ਲੰਘਾਇਆ ਜੋ ਇੱਕ ਵੀ ਅੰਦਰੂਨੀ ਨਾਮ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ, ਜਦਕਿ ਨਾਲ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਬਿਨਾਂ ਕਿਸੇ ਸ਼ਿਕਾਇਤ ਦੇ ਵਿਕੀ ਖੋਲ੍ਹ ਰਿਹਾ ਸੀ। ਟਨਲ ਚਾਲੂ ਸੀ, ਬ੍ਰਾਊਜ਼ਰ ਇਸ ਨੂੰ ਸਾਬਤ ਕਰ ਰਿਹਾ ਸੀ, ਅਤੇ ਕੰਟੇਨਰ ਕਿਸੇ ਹੋਰ ਰੂਟ ਟੇਬਲ ਅਤੇ ਹੋਰ ਰਿਜ਼ਾਲਵਰ ਵਾਲੇ ਦੂਜੇ ਨੈੱਟਵਰਕ ਨਾਮ-ਸਥਾਨ ਵਿੱਚ ਸੀ. ਅੱਗੇ ਜੋ ਹੈ ਉਹ ਮੇਰਾ ਹੁਣ ਜਾਂਚਿਆ ਜਾਣ ਵਾਲਾ ਕ੍ਰਮ ਹੈ: ਪਹਿਲਾਂ ਰੂਟ ਟੇਬਲ, ਦੂਜਾ ਨਾਮ ਹੱਲ, ਤੀਜਾ ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਆਖਰ ਵਿੱਚ ਹੋਸਟ ਪਲੇਟਫਾਰਮ। ਪਹਿਲਾਂ ਹੀ ਫੇਲ੍ਹ ਹੋ ਚੁੱਕੇ ਕਦਮ 'ਤੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਸਟੈਕ ਵਿੱਚ ਹੇਠਾਂ ਨਿਯਮ ਜੋੜਨਾ ਹੱਦ ਨੂੰ ਹਿਲਾਉਣ ਦੀ ਥਾਂ ਲੁਕਾਉਂਦਾ ਹੈ।

ਕੋਈ ਨਿਯਮ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨੇ ਰੂਟ ਟੇਬਲ ਤੁਲਨਾ ਕਰੋ

Docker ਦੇ ਡਿਫਾਲਟ ਬ੍ਰਿਜ 'ਤੇ ਕੰਟੇਨਰ ਕੋਲ docker0 ਗੇਟਵੇ ਵੱਲ ਜਾਂਦਾ ਇੱਕ ਡਿਫਾਲਟ ਰੂਟ ਹੈ, ਅਤੇ ਉਸਨੂੰ ਪਤਾ ਨਹੀਂ ਕਿ tun0 ਮੌਜੂਦ ਹੈ। ਹੋਸਟ ਕੋਲ tun0, VPN ਵੱਲੋਂ ਧੱਕੇ ਗਏ ਰੂਟ, ਅਤੇ ਸ਼ਾਇਦ ਇੱਕ ਨੀਤੀ ਨਿਯਮ ਵੀ ਹੈ ਜੋ ਜਾਂਚ ਟ੍ਰੈਫਿਕ ਨੂੰ ਤੁਹਾਡੀ ਉਮੀਦ ਨਾਲੋਂ ਵੱਖਰੇ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ। WSL ਆਪਣੇ ਵਰਚੁਅਲ ਅਡਾਪਟਰ ਦੇ ਪਿੱਛੇ ਤੀਜੀ ਟੇਬਲ ਜੋੜਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨੇ ਛਾਪੋ।

ਜੇ ਕੰਟੇਨਰ ਦਾ ਇੱਕੋ-ਇੱਕ ਰੂਟ ਬ੍ਰਿਜ ਹੈ ਅਤੇ tun0 ਉਸਦੇ ਨਾਮ-ਸਥਾਨ ਵਿੱਚ ਕਦੇ ਨਹੀਂ ਦਿਸਦਾ, ਤਾਂ ਹੇਠਾਂ ਦਾ ਕੁਝ ਵੀ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ: ਕੋਈ ਨੇਮਸਰਵਰ ਬਦਲਾਅ ਰੂਟ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਅਤੇ ਕੋਈ ਰੂਟ ਅਜਿਹੀ ਟਨਲ ਪਛਾਣ ਨਹੀਂ ਬਣਾਉਂਦਾ ਜੋ ਪੀਅਰ ਸਵੀਕਾਰ ਕਰੇ। ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ DNS ਫੇਲ੍ਹ ਅਤੇ ਰੂਟ ਫੇਲ੍ਹ ਸ਼ੈੱਲ ਦੇ ਅੰਦਰੋਂ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ।

ਰਿਜ਼ਾਲਵਰ ਨੂੰ ਸਾਂਝੇ ਵੱਲ ਨਹੀਂ, ਟਨਲ ਵੱਲ ਸੇਧਿਤ ਕਰੋ

ਹੋਸਟ 'ਤੇ, resolvectl status ਹਰ ਲਿੰਕ ਲਈ DNS ਸਰਵਰ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ readlink -f /etc/resolv.conf ਦੱਸਦਾ ਹੈ ਕਿ ਫਾਈਲ systemd ਸਟਬ ਹੈ, NetworkManager ਫਾਈਲ ਹੈ, ਜਾਂ ਵਿਕਰੇਤਾ ਦੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਦੁਬਾਰਾ ਲਿਖੀ ਗਈ ਕੋਈ ਚੀਜ਼ ਹੈ। ਵਰਤੋਂਕਾਰ ਵੱਲੋਂ ਪਰਿਭਾਸ਼ਿਤ ਨੈੱਟਵਰਕ 'ਤੇ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ, /etc/resolv.conf ਨਾਮ ਦਿੰਦਾ ਹੈ 127.0.0.11, Docker ਦੇ ਅੰਦਰੂਨੀ ਰਿਜ਼ਾਲਵਰ ਨੂੰ, ਜੋ ਉਸ upstream ਵੱਲ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ ਜਿਸ ਨਾਲ ਡੈਮਨ ਸੰਰਚਿਤ ਸੀ। ਪਰ ਡਿਫਾਲਟ ਬ੍ਰਿਜ ਵਾਲੇ ਕੰਟੇਨਰ ਨੂੰ ਬਣਨ ਵੇਲੇ ਹੋਸਟ ਫਾਈਲ ਦੀ ਨਕਲ ਮਿਲੀ ਸੀ, ਅਤੇ ਉਹ ਉਸਨੂੰ ਰੱਖਦਾ ਹੈ।

ਉਹੀ ਨਕਲ ਕਾਰਨ ਹੈ ਕਿ ਕੰਟੇਨਰ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਉੱਠਣ ਵਾਲੀ ਟਨਲ ਕੰਟੇਨਰ ਨੂੰ ਪੁਰਾਣੇ upstream ਨੂੰ ਪੁੱਛਦਾ ਛੱਡ ਦਿੰਦੀ ਹੈ। ਜਾਂ ਤਾਂ VPN ਰਿਜ਼ਾਲਵਰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਇਸ ਨਾਲ ਪਾਸ ਕਰੋ docker run --dns 10.8.0.53, ਜਾਂ "dns": ["10.8.0.53"] ਵਿੱਚ /etc/docker/daemon.json ਸੈੱਟ ਕਰਕੇ ਡੈਮਨ ਮੁੜ ਸ਼ੁਰੂ ਕਰੋ, ਜਾਂ ਟਨਲ ਉੱਠਣ ਤੋਂ ਬਾਅਦ ਕੰਟੇਨਰ ਦੁਬਾਰਾ ਬਣਾਓ। ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਘੰਟਾ ਪਹਿਲਾਂ ਸਹੀ ਸੀ ਅਜਿਹੇ ਰਿਜ਼ਾਲਵਰ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਨਾਲੋਂ ਸਸਤਾ ਹੈ।

ਸਾਂਝਾ ਰਿਜ਼ਾਲਵਰ ਲਾਉਣਾ ਉਹ ਮੁਰੰਮਤ ਹੈ ਜੋ ਲੱਛਣ ਬਣਾਈ ਰੱਖਦੀ ਹੈ। ਇਹ ਇੰਟਰਨੈੱਟ ਹੱਲ ਕਰਦਾ ਹੈ ਪਰ ਹਰ ਪ੍ਰਾਈਵੇਟ ਜ਼ੋਨ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਉਸ ਫਿਲਟਰਿੰਗ ਨੂੰ ਚੁੱਪਚਾਪ ਬਾਈਪਾਸ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਲਈ ਟਨਲ ਮੌਜੂਦ ਹੈ। ਜੇ ਤੁਸੀਂ ਚੱਲ ਰਹੇ ਕੰਟੇਨਰ ਦੇ /etc/resolv.conf ਅੰਦਰ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਤਾਂ ਉਮੀਦ ਰੱਖੋ Device or resource busy: Docker ਉਸ ਫਾਈਲ ਨੂੰ bind-mount ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸੋਧ ਲਈ ਪਹਿਲਾਂ ਅਨਮਾਊਂਟ ਚਾਹੀਦਾ ਹੈ। --dns ਨੂੰ ਬਣਾਉਣ ਵੇਲੇ ਸੈੱਟ ਕਰਨਾ ਉਹ ਕ੍ਰਮ ਹੈ ਜੋ ਮੁੜ ਚਾਲੂ ਹੋਣ 'ਤੇ ਟਿਕਦਾ ਹੈ।

ਜਦੋਂ ਕੰਟੇਨਰ ਟਨਲ ਉਧਾਰ ਲੈਣ ਤਾਂ ਫਾਰਵਰਡ ਕਰੋ ਅਤੇ ਅਨੁਵਾਦ ਕਰੋ

ਡਿਫਾਲਟ ਬ੍ਰਿਜ ਨਾਲ, ਹੋਸਟ docker0 ਅਤੇ tun0 ਵਿਚਕਾਰ ਰਾਊਟਰ ਹੈ, ਅਤੇ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਇਹ ਦੋਵੇਂ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ ਕਰੋ ਅਤੇ ਸਰੋਤ ਪਤੇ ਦਾ ਅਨੁਵਾਦ ਕਰੋ ਤਾਂ ਜੋ ਪੀਅਰ ਨੂੰ ਵਾਪਸੀ ਰੂਟ ਤੋਂ ਬਿਨਾਂ ਪਤੇ ਦੀ ਥਾਂ ਹੋਸਟ ਦਾ ਟਨਲ ਪਤਾ ਦਿਸੇ (tun0 ਨੂੰ ਉਸ ਨਾਮ ਨਾਲ ਬਦਲੋ ਜੋ ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਇੰਟਰਫੇਸ ਨੂੰ ਦਿੰਦਾ ਹੈ):

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A FORWARD -i docker0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o docker0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

FORWARD ਨਿਯਮ ਉਨ੍ਹਾਂ ਹੋਸਟਾਂ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਫਾਰਵਰਡ ਨੀਤੀ DROP ਹੈ। Docker ਆਪਣੀਆਂ ਚੇਨਾਂ ਪਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਪੜ੍ਹਨ ਦੀ ਥਾਂ ਪੈਕੇਟ ਨਾਲ ਜਾਂਚੋ iptables -S: ਕੰਟੇਨਰ ਤੋਂ, ip route get 10.8.0.20 ਬ੍ਰਿਜ ਗੇਟਵੇ ਦਾ ਨਾਮ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ nc -vz 10.8.0.20 443 ਰਿਜ਼ਾਲਵਰ 'ਤੇ ਨਹੀਂ ਸਗੋਂ ਟਨਲ 'ਤੇ ਜੁੜਨਾ ਜਾਂ ਸਮਾਂ ਖਤਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

MASQUERADE ਤੋਂ ਬਿਨਾਂ ਪੀਅਰ ਨੂੰ 172.17.0.0/16 ਵੱਲ ਵਾਪਸੀ ਰੂਟ ਚਾਹੀਦਾ ਹੈ, ਜੋ ਜ਼ਿਆਦਾਤਰ ਰਿਮੋਟ-ਐਕਸੈਸ VPN ਨਹੀਂ ਧੱਕਣਗੇ। ਇੱਥੇ ਹੀ ਨੀਤੀ-ਆਧਾਰਿਤ ਕਲਾਇੰਟ ਯੋਜਨਾ ਤੋੜਦਾ ਹੈ: ਜੇ ਇਹ ਸਿਰਫ਼ ਖਾਸ UID ਜਾਂ cgroups ਦਾ ਟ੍ਰੈਫਿਕ ਫੜਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਫਾਰਵਰਡ ਨਿਯਮ ਟਨਲ ਦੇ ਅੰਦਰ ਪੈਕੇਟ ਕਦੇ ਨਹੀਂ ਦੇਖਦੇ, ਅਤੇ ਸੁਧਾਰ iptables ਵਿੱਚ ਨਹੀਂ ਸਗੋਂ ਕਲਾਇੰਟ ਦੀ ਰਾਊਟਿੰਗ ਨੀਤੀ ਵਿੱਚ ਹੈ। ਹੱਥ ਨਾਲ ਜੋੜੇ ਨਿਯਮ ਰੀਬੂਟ 'ਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ systemd ਯੂਨਿਟ ਜਾਂ netfilter-persistent ਟੇਬਲ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਦੇਰ ਨਾਲ ਉੱਠਣ ਵਾਲੀ ਟਨਲ ਉਨ੍ਹਾਂ ਨੂੰ ਵਹਾ ਸਕਦੀ ਹੈ।

ਜਦੋਂ ਟੀਚਾ ਅਲੱਗਾਅ ਹੋਵੇ ਤਾਂ ਟਨਲ ਨੂੰ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਰੱਖੋ

ਜੇ ਇੱਕ ਕੰਟੇਨਰ ਨੂੰ ਖਾਸ ਨੋਡ ਰਾਹੀਂ ਬਾਹਰ ਜਾਣਾ ਹੈ, ਤਾਂ ਉਸ ਕੰਟੇਨਰ ਵਿੱਚ ਕਲਾਇੰਟ ਚਲਾਓ. ਇਸਨੂੰ --cap-add NET_ADMIN ਅਤੇ --device /dev/net/tun ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਇਹ ਆਪਣਾ tun0, ਰੂਟ ਅਤੇ ਫਾਇਰਵਾਲ ਰੱਖਦਾ ਹੈ। ਜੇ ਹੋਰ ਕੰਟੇਨਰ ਇਸ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਨ, ਤਾਂ ਇਸਨੂੰ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਫਾਰਵਰਡਿੰਗ ਅਤੇ MASQUERADE ਨਿਯਮ ਵੀ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਪੀਅਰਾਂ ਨੂੰ ਇਸ ਵੱਲ ਦਿਸਦਾ ਸਪਸ਼ਟ ਰੂਟ ਜਾਂ ਪ੍ਰੌਕਸੀ ਚਾਹੀਦਾ ਹੈ; Docker ਦਾ ਡਿਫਾਲਟ ਬ੍ਰਿਜ ਤੁਹਾਡੇ ਲਈ ਉਹ ਰੂਟ ਨਹੀਂ ਜੋੜਦਾ।

ਹੋਸਟ ਨੈੱਟਵਰਕਿੰਗ, docker run --network host, ਸਸਤਾ ਸੰਸਕਰਣ ਹੈ: ਕੰਟੇਨਰ ਹੋਸਟ ਦੇ ਨਾਮ-ਸਥਾਨ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਟਨਲ ਦੇ ਰੂਟ ਸਿੱਧੇ ਦੇਖਦਾ ਹੈ। ਇਹ ਨੈੱਟਵਰਕ ਅਲੱਗਾਅ ਵੀ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਪੋਰਟ ਟਕਰਾਅ ਨੂੰ ਸੱਦਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਅਮਲ ਵਿੱਚ ਇਹ Linux ਚੋਣ ਹੈ। ਪ੍ਰਕਾਸ਼ਿਤ ਪੋਰਟ ਇਸਦਾ ਬਦਲ ਨਹੀਂ ਹੈ। -p 8080:80 ਸੇਵਾ ਨੂੰ ਹੋਸਟ ਤੋਂ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦਾ ਹੈ; ਇਹ ਅੰਦਰੂਨੀ 10.x ਪਤਿਆਂ ਨੂੰ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰੋਂ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਅਤੇ ਦੋਵਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਰਾਊਟਿੰਗ ਸਮੱਸਿਆ ਖੁੱਲ੍ਹਾ ਡਾਟਾਬੇਸ ਪੋਰਟ ਬਣ ਜਾਂਦੀ ਹੈ।

ਨਾਮ ਫੇਲ੍ਹ ਨੂੰ ਓਵਰਲੈਪਿੰਗ ਸਬਨੈੱਟ ਤੋਂ ਵੱਖ ਕਰੋ

Docker ਦਾ ਡਿਫਾਲਟ ਬ੍ਰਿਜ 172.17.0.0/16 ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਕਾਰਪੋਰੇਟ VPN ਪੂਲ 172.16.0.0/12 ਦੇ ਅੰਦਰ ਹਨ। ਜਦੋਂ ਟਨਲ ਉਸ ਰੇਂਜ ਦੀ ਮਾਲਕ ਬਣ ਜਾਂਦੀ ਹੈ, ਕੰਟੇਨਰ ਲਈ ਭੇਜਿਆ ਟ੍ਰੈਫਿਕ ਇਸਦੀ ਥਾਂ ਟਨਲ ਵਿੱਚ ਰਾਊਟ ਹੋ ਸਕਦਾ ਹੈ। ਨਾਮ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ, ਗਲਤੀ DNS ਵਰਗੀ ਦਿਸਦੀ ਹੈ, ਅਤੇ ਸਮੱਸਿਆ ਪਤਿਆਂ ਵਿੱਚ ਹੈ। ਮੰਜ਼ਿਲ ਜਾਂਚੋ, ਰਿਜ਼ਾਲਵਰ ਨਹੀਂ: ip route get 172.17.0.5 ਹੋਸਟ 'ਤੇ, ਫਿਰ ਬ੍ਰਿਜ ਪ੍ਰੀਫਿਕਸ ਦੀ VPN ਪੂਲ ਅਤੇ docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}' ਨਾਲ ਤੁਲਨਾ ਕਰੋ।

ਮੁਰੰਮਤ ਇਹ ਹੈ ਕਿ ਰੇਂਜਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਹਿਲਾਇਆ ਜਾਵੇ: ਜਾਂ ਤਾਂ daemon.json ਵਿੱਚ Docker ਲਈ ਹੋਰ ਡਿਫਾਲਟ ਪਤਾ ਪੂਲ, ਜਾਂ ਕੰਸਨਟ੍ਰੇਟਰ 'ਤੇ ਹੋਰ ਪੂਲ। ਇੱਥੇ ਹੋਰ ਨੇਮਸਰਵਰ ਜੋੜਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ssh -b ਨਾਲ ਵੀ ਨਹੀਂ: ਕਲਾਇੰਟ ਨੂੰ ਇੰਟਰਫੇਸ ਨਾਲ ਬੰਨ੍ਹਣਾ ਸਰੋਤ ਪਤਾ ਬਦਲਦਾ ਹੈ, ਟਨਲ ਵੱਲ ਦਿਸਦਾ ਮੰਜ਼ਿਲ ਰੂਟ ਨਹੀਂ। ਤੇਜ਼ ਕੰਮ-ਵੰਡ: ਹੋਸਟ 'ਤੇ ਹੱਲ ਹੋਣ ਵਾਲਾ ਪਰ ਕੰਟੇਨਰ ਵਿੱਚ ਨਾ ਹੋਣ ਵਾਲਾ ਨਾਮ ਰਿਜ਼ਾਲਵਰ ਸਮੱਸਿਆ ਹੈ, ਜਦਕਿ ਕੰਟੇਨਰ ਵਿੱਚ ਅਟਕਣ ਵਾਲਾ ਪਰ ਹੋਸਟ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਸਿੱਧਾ IP ਕਨੈਕਸ਼ਨ ਰੂਟ ਜਾਂ ਫਾਰਵਰਡ-ਚੇਨ ਸਮੱਸਿਆ ਹੈ।

WSL ਅਤੇ Docker Desktop Linux ਦੇ ਨਿਯਮ ਨਹੀਂ ਮੰਨਦੇ

ਆਪਣੇ ਡਿਫਾਲਟ NAT ਮੋਡ ਵਿੱਚ, WSL ਆਪਣੇ ਵਰਚੁਅਲ ਅਡਾਪਟਰ ਦੇ ਪਿੱਛੇ ਬੈਠਦਾ ਹੈ ਅਤੇ Windows VPN ਦੇ ਅੰਦਰੂਨੀ ਰੂਟ ਜਾਂ DNS ਸਫਿਕਸ ਨਹੀਂ ਲੈਂਦਾ, ਇਸ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ping ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੇ ਅੰਦਰ ਨਹੀਂ। ਹਾਲੀਆ Windows 11 ਬਿਲਡਾਂ ਵਿੱਚ ਉਪਲਬਧ ਮਿਰਰ ਨੈੱਟਵਰਕਿੰਗ ਇਸਦੀ ਥਾਂ ਹੋਸਟ ਇੰਟਰਫੇਸ ਸਾਂਝੇ ਕਰਦੀ ਹੈ, ਪਰ ਇਸਨੂੰ .wslconfig ਵਿੱਚ ਸਮਰੱਥ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਅਤੇ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਨੂੰ wsl --shutdown ਨਾਲ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਸਰਗਰਮ ਮੋਡ ਦੀ ਪੁਸ਼ਟੀ wslinfo --networking-mode ਨਾਲ ਕਰੋ, ਸੁਧਾਰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਕਿਉਂਕਿ NAT ਦਾ ਜਵਾਬ ਮਿਰਰ ਮੋਡ ਲਈ ਗਲਤ ਹੈ ਅਤੇ ਉਲਟ ਵੀ।

Docker Desktop ਇੱਕ ਹੋਰ ਪਰਤ ਜੋੜਦਾ ਹੈ। Windows 'ਤੇ Linux ਕੰਟੇਨਰ ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ vpnkit ਕਹਾਉਂਦੇ NAT ਲਾਗੂਕਰਨ ਦੇ ਪਿੱਛੇ ਬੈਠਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਦਾ ਰਾਹ ਮੂਲ Linux ਹੋਸਟ ਨਾਲੋਂ ਵੱਖਰਾ ਹੈ। Windows ਕੰਟੇਨਰ Hyper-V ਵਰਚੁਅਲ ਸਵਿੱਚ ਰਾਹੀਂ ਜੁੜਦੇ ਹਨ, ਅਤੇ ਕਾਰਪੋਰੇਟ ਕਲਾਇੰਟ ਉਸ ਸਵਿੱਚ ਤੋਂ ਆਉਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਰੋਕ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕੋ ਮਸ਼ੀਨ 'ਤੇ Linux ਕੰਟੇਨਰ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ ਜਦਕਿ Windows ਕੰਟੇਨਰਾਂ ਕੋਲ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ। ਭੌਤਿਕ ਅਡਾਪਟਰ ਨਾਲ ਬੱਝਾ ਬਾਹਰੀ ਸਵਿੱਚ ਆਮ ਹੱਲ ਹੈ, ਅਤੇ ਇਹ ਕੰਟੇਨਰ ਦੀ ਨੈੱਟਵਰਕ ਪਛਾਣ ਉਨ੍ਹਾਂ ਤਰੀਕਿਆਂ ਨਾਲ ਬਦਲਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਨੀਤੀ ਇਜਾਜ਼ਤ ਨਾ ਦੇਵੇ।

ਹੋਰ ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਚਾਰੇ ਪਰਤਾਂ ਕ੍ਰਮ ਨਾਲ ਚੱਲੋ ਅਤੇ ਜਿੱਥੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਗਲਤ ਹੋਵੇ ਉੱਥੇ ਰੁਕੋ:

• ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ: ਕੀ ip route ਪ੍ਰਾਈਵੇਟ ਪ੍ਰੀਫਿਕਸ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ ਕੀ /etc/resolv.conf ਉਸ upstream ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ?
• ਹੋਸਟ 'ਤੇ: ਕੀ ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ ਹੈ, ਕੀ NAT ਟਨਲ ਇੰਟਰਫੇਸ ਨਾਲ ਬੱਝਾ ਹੈ, ਅਤੇ ਕੀ ਫਾਰਵਰਡ ਚੇਨ ਬ੍ਰਿਜ ਤੋਂ ਟਨਲ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ?
• ਪੀਅਰ 'ਤੇ: ਕੀ ਇਸਨੂੰ ਵਾਪਸੀ ਰਾਹ ਪਤਾ ਹੈ, ਜਾਂ ਤੁਸੀਂ ਕੰਟੇਨਰ ਸਬਨੈੱਟ ਲੁਕਾਉਣ ਲਈ NAT 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋ?
• ਪਲੇਟਫਾਰਮ 'ਤੇ: ਕੀ WSL NAT ਜਾਂ ਮਿਰਰ ਮੋਡ ਵਿੱਚ ਹੈ, ਅਤੇ ਕੰਟੇਨਰ Linux ਹੈ ਜਾਂ Windows?

ਹਰ ਜਾਂਚ ਨੂੰ ਨਵੇਂ ਕੰਟੇਨਰ ਜਾਂ ਸ਼ੈੱਲ ਵਿੱਚ ਦੁਬਾਰਾ ਚਲਾਓ। ਕੈਸ਼ ਕੀਤੇ ਜਵਾਬ ਜਾਂ ਸਥਾਪਿਤ ਕਨੈਕਸ਼ਨ ਵਾਲੀ ਲੰਮੀ ਪ੍ਰਕਿਰਿਆ ਸੰਰਚਨਾ ਸਹੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਰਹੇਗੀ, ਅਤੇ ਉਹ ਫੇਲ੍ਹ ਉਸ ਮੁਰੰਮਤ ਵਰਗੀ ਦਿਸਦੀ ਹੈ ਜੋ ਕੰਮ ਨਹੀਂ ਕੀਤੀ।