Windows ਕੰਟੇਨਰ ਅਤੇ VPN: ਸਥਾਨਕ ਨੈੱਟਵਰਕਿੰਗ ਕਿਉਂ ਟੁੱਟਦੀ ਹੈ
Windows ਕੰਟੇਨਰ ਹੋਸਟ ਦੀ ਰੂਟ ਟੇਬਲ ਵਰਤਦਾ ਹੈ, ਇਸ ਲਈ ਸਥਾਨਕ ਸਬਨੈੱਟ ਨੂੰ ਬਲੌਕ ਕਰਨ ਵਾਲਾ VPN ਕੰਟੇਨਰ ਦਾ ਪ੍ਰੀਫਿਕਸ ਵੀ ਨਾਲ ਲੈ ਜਾਂਦਾ ਹੈ। Linux ਮੋਡ ਦੂਜਾ ਰਾਹ ਲੈਂਦਾ ਹੈ।
ਇੱਕ ਲੈਪਟਾਪ 'ਤੇ, ਇੱਕ VPN ਕਲਾਇੰਟ ਜੁੜਿਆ ਹੋਣ ਸਮੇਂ, Linux ਕੰਟੇਨਰ ਆਪਸ ਵਿੱਚ ਗੱਲ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ Windows ਕੰਟੇਨਰ ਰੁਕ ਜਾਂਦੇ ਹਨ। ਬਦਲਣ ਵਾਲੀ ਚੀਜ਼ ਇਮੇਜ ਨਹੀਂ; ਪੈਕਟ ਹੋਸਟ ਤੱਕ ਜਿਸ ਰਾਹ ਜਾਂਦੇ ਹਨ ਉਹ ਹੈ। ਡਿਫਾਲਟ ਨੈੱਟਵਰਕ 'ਤੇ Windows ਕੰਟੇਨਰ ਹੋਸਟ ਦੀ ਰੂਟ ਟੇਬਲ ਅਤੇ ਅਨੁਵਾਦ ਉਧਾਰ ਲੈਂਦੇ ਹਨ, ਇਸ ਲਈ ਹੋਸਟ ਦੀ ਰੂਟਿੰਗ ਬਦਲਣ ਵਾਲੀ ਨੀਤੀ ਉਹਨਾਂ ਨੂੰ ਵੀ ਬਦਲਦੀ ਹੈ। ਕੁਝ ਵੀ ਦੁਬਾਰਾ ਸਥਾਪਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੂਟ ਖੋਜ ਨਾਲ ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
Windows ਕੰਟੇਨਰ ਦੇ ਪੈਕਟ ਹੋਸਟ ਵਿੱਚ ਕਿੱਥੇ ਦਾਖਲ ਹੁੰਦੇ ਹਨ
ਡਿਫਾਲਟ nat ਨੈੱਟਵਰਕ 'ਤੇ ਕੰਟੇਨਰ Host Networking Service ਦੇ ਪ੍ਰੀਫਿਕਸ ਤੋਂ ਪਤਾ ਲੈਂਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ 172.16.0.0/12 ਦੇ ਅੰਦਰ ਕਿਤੇ, ਅਤੇ ਵਰਚੁਅਲ ਅਡੈਪਟਰ ਰਾਹੀਂ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਹੋਸਟ ਉਸ ਪ੍ਰੀਫਿਕਸ ਦੀ ਰੂਟ ਰੱਖਦਾ ਹੈ ਅਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਉਸ ਅਡੈਪਟਰ ਵੱਲ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ ਜੋ ਇਸ ਸਮੇਂ ਸਰਗਰਮ ਹੈ। ਉਸ ਰਾਹ ਦੇ ਵਿਚਕਾਰ ਕੋਈ ਵੱਖਰੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨਹੀਂ ਹੈ।
ਇਹੀ ਡਿਜ਼ਾਈਨ ਅਸਫਲਤਾ ਨੂੰ ਮਸ਼ੀਨੀ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਕੰਟੇਨਰ ਪੈਕਟ ਭੇਜਦਾ ਹੈ, ਹੋਸਟ ਕੰਟੇਨਰ ਪ੍ਰੀਫਿਕਸ ਲਈ ਰੂਟ ਖੋਜ ਕਰਦਾ ਹੈ। ਜੋ ਵੀ ਰੂਟ ਜਿੱਤਦੀ ਹੈ ਪੈਕਟ ਉੱਥੇ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕੰਟੇਨਰ ਦਾ ਇਸ ਵਿੱਚ ਕੋਈ ਮੱਤ ਨਹੀਂ।
VPN ਕਲਾਇੰਟ ਉਸ ਰਾਹ 'ਤੇ ਕੀ ਬਦਲਦਾ ਹੈ
ਕਾਰਪੋਰੇਟ ਕਲਾਇੰਟ ਅਕਸਰ ਬਹੁਤ ਸਾਰੀਆਂ ਰੂਟਾਂ ਅਤੇ ਇੱਕ ਫਿਲਟਰ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਜੋ ਟਨਲ ਚਾਲੂ ਹੋਣ ਸਮੇਂ ਸਥਾਨਕ ਸਬਨੈੱਟ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ। ਮਕਸਦ ਬਚਾਅ ਵਾਲਾ ਹੈ: ਸਮਝੌਤਾ ਹੋਏ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਨੂੰ ਸੁਰੱਖਿਅਤ ਮਸ਼ੀਨ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ। ਮਾੜਾ ਅਸਰ ਇਹ ਹੈ ਕਿ ਹੋਸਟ ਦੀ ਰੂਟ ਕੰਟੇਨਰ ਪ੍ਰੀਫਿਕਸ ਤੱਕ ਹੁਣ ਸਥਾਨਕ NAT ਨੈੱਟਵਰਕ ਨਹੀਂ ਹੈ।
ਇਸ ਦੀ ਬਜਾਏ ਖੋਜ ਟਨਲ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ ਅਤੇ ਪੈਕਟ ਉਸ ਗੇਟਵੇ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜਿਸਨੇ ਉਹ ਕੰਟੇਨਰ ਪਤਾ ਕਦੇ ਨਹੀਂ ਸੁਣਿਆ। Ping ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਸਮਾਂ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ, ਅਤੇ VPN ਆਇਕਨ ਚਮਕਦੇ ਹੋਏ ਕੰਟੇਨਰ ਟੁੱਟਿਆ ਦਿਸਦਾ ਹੈ। ਜੁੜੇ ਹੋਣ ਸਮੇਂ ਹੋਸਟ ਦੀ ਟੇਬਲ ਵੇਖੋ ਅਤੇ ਮੁਕਾਬਲਾਵਾਦੀ ਰੂਟ ਦਿਸਦੀ ਹੈ।
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Linux ਕੰਟੇਨਰ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਿਉਂ ਕਰਦੇ ਹਨ
Linux ਇੰਜਣ ਕੰਟੇਨਰਾਂ ਨੂੰ ਹਲਕੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੇ ਅੰਦਰ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਸ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਕੰਟੇਨਰ ਵੱਲੋਂ ਹੋਸਟ ਪਾਸੇ ਦਾ ਪ੍ਰੌਕਸੀ ਖੋਲ੍ਹਦਾ ਹੈ। ਸੌਕਟ ਹੋਸਟ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਕੰਟੇਨਰ ਪ੍ਰੀਫਿਕਸ ਬਾਰੇ VPN ਦਾ ਨਿਯਮ ਉਸ 'ਤੇ ਉਸੇ ਤਰ੍ਹਾਂ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਕੰਮ ਦਾ ਭਾਰ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚਦਾ ਰਹਿੰਦਾ ਹੈ।
ਇਹ ਫ਼ਰਕ ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ Linux ਦੇ ਤਰੀਕੇ ਕਿਉਂ ਨਹੀਂ ਲੰਘਦੇ। ਜਿਸ Linux ਕੰਟੇਨਰ ਨੂੰ ਆਪਣੀ ਟਨਲ ਚਾਹੀਦੀ ਹੈ ਉਸਨੂੰ TUN ਜੰਤਰ ਅਤੇ NET_ADMIN ਸਮਰੱਥਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। Windows ਕੰਟੇਨਰ ਕਿਸੇ ਇੰਟਰਫੇਸ ਨੂੰ ਜੰਤਰ ਵਜੋਂ ਨਹੀਂ ਦਰਸਾਉਂਦੇ, ਇਸ ਲਈ ਉਸ ਪੈਟਰਨ ਦਾ ਉਸ ਪਾਸੇ ਕੋਈ ਬਰਾਬਰ ਨਹੀਂ।
ਰੂਟ ਸਾਬਤ ਕਰੋ, ਫਿਰ ਡਿਜ਼ਾਈਨ ਚੁਣੋ
ਸਬੂਤ ਹੋਸਟ ਤੋਂ ਇਕੱਠੇ ਕਰੋ, ਕੰਟੇਨਰ ਤੋਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਖੋਜ ਹੋਸਟ ਕਰਦਾ ਹੈ:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"VPN ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਵਾਰ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਵਾਰ ਰੂਟ ਆਉਟਪੁੱਟ ਚਲਾਓ। ਜੇ ਦੂਜੇ ਆਉਟਪੁੱਟ ਵਿੱਚ ਕੰਟੇਨਰ ਪ੍ਰੀਫਿਕਸ ਟਨਲ ਅਡੈਪਟਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਨਿਦਾਨ ਪੂਰਾ ਹੈ ਅਤੇ ਕੰਟੇਨਰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਮਦਦ ਨਹੀਂ ਮਿਲੇਗੀ।
ਪਹਿਲਾ ਵਿਕਲਪ ਨੀਤੀ ਦਾ ਫੈਸਲਾ ਹੈ: ਨੈੱਟਵਰਕ ਦੇ ਮਾਲਕ ਨੂੰ ਪੁੱਛੋ ਕਿ ਇਸ ਡਿਵਾਈਸ ਲਈ ਸਥਾਨਕ LAN ਪਹੁੰਚ ਦੀ ਆਗਿਆ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਕਈ ਕਾਰਪੋਰੇਟ ਕਲਾਇੰਟ ਇਸਨੂੰ ਸੈਟਿੰਗ ਵਜੋਂ ਦਿੰਦੇ ਹਨ, ਪਰ ਇਹ ਜਾਣ-ਬੁੱਝ ਕੇ ਬਣਾਈ ਸੀਮਾ ਨੂੰ ਕਮਜ਼ੋਰ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਮਾਲਕ ਅਤੇ ਸਮੀਖਿਆ ਤਾਰੀਖ਼ ਸਮੇਤ ਦਸਤਾਵੇਜ਼ੀ ਛੋਟ ਵਜੋਂ ਮੰਗੋ। ਹਰ ਡਿਵਾਈਸ ਲਈ ਟੌਗਲ ਜਿਸ ਵੱਲ ਕੋਈ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ, ਉਹੀ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਬਚਾਅ ਵਾਲੀ ਨੀਤੀ ਚੁੱਪਚਾਪ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ।
ਜਿੱਥੇ ਨੀਤੀ ਟਿਕਣੀ ਲਾਜ਼ਮੀ ਹੈ, ਉੱਥੇ ਰੂਟ ਨਾਲ ਲੜਨ ਦੀ ਬਜਾਏ ਕੰਮ ਦਾ ਭਾਰ ਹਿਲਾਓ। ਸਪਸ਼ਟ ਸਬਨੈੱਟ ਅਤੇ ਗੇਟਵੇ ਵਾਲਾ ਪਾਰਦਰਸ਼ੀ ਨੈੱਟਵਰਕ ਕੰਟੇਨਰਾਂ ਨੂੰ ਸਥਾਨਕ ਲਿੰਕ 'ਤੇ ਰੱਖਦਾ ਹੈ, Linux ਕੰਮ ਦਾ ਭਾਰ VM ਪ੍ਰੌਕਸੀ ਪਿੱਛੇ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਆਪਣੇ ਕਲਾਇੰਟ ਵਾਲੀ ਵੱਖਰੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਆਪਣੀ ਨੀਤੀ ਬਣਾਈ ਰੱਖਦੀ ਹੈ। ਇੱਕ ਜਾਣ-ਬੁੱਝ ਕੇ ਚੁਣੋ ਅਤੇ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰੋਂ ਇਸਦੀ ਜਾਂਚ ਕਰੋ, ਕਿਉਂਕਿ ਵਰਤੋਂਕਾਰ ਦੀ ਬੇਨਤੀ ਉੱਥੋਂ ਹੀ ਪੈਦਾ ਹੁੰਦੀ ਹੈ।