Windows ਕੰਟੇਨਰਾਂ ਵਿੱਚ UNC ਪਹੁੰਚ: ਪਹਿਲਾਂ ਨਾਮ, ਫਿਰ ਪਛਾਣ

ਤੁਹਾਡੀ ਸੁਰੰਗ ਦੇ ਦੂਜੇ ਪਾਸੇ ਸ਼ੇਅਰ ਦੀ ਲੋੜ ਵਾਲਾ Windows ਕੰਟੇਨਰ ਦੋ ਸੁਤੰਤਰ ਢੰਗਾਂ ਨਾਲ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਹੋਸਟ ਦਾ Explorer ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਕੰਟੇਨਰ ਦਾ ਆਪਣਾ ਨੈੱਟਵਰਕ ਐਂਡਪੁਆਇੰਟ ਅਤੇ ਆਪਣੀ ਪ੍ਰੋਸੈਸ ਪਛਾਣ ਹੈ। ਡੈਸਕਟਾਪ ਉੱਤੇ ਹੱਲ ਹੋਣ ਵਾਲਾ ਨਾਮ ਅਤੇ ਫਾਈਲ ਸਰਵਰ ਉੱਥੇ ਜੋ ਸੈਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਡੈਸਕਟਾਪ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ, ਵਰਕਲੋਡ ਦਾ ਨਹੀਂ।

ਹੋਸਟ ਦਾ Explorer ਸਬੂਤ ਨਹੀਂ

ਹੋਸਟ ਉੱਤੇ ਸ਼ੇਅਰ ਖੋਲ੍ਹਣਾ ਹੋਸਟ ਦਾ DNS ਕਲਾਇੰਟ, ਹੋਸਟ ਦੀ ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਅਤੇ ਹੋਸਟ ਉੱਤੇ ਲੌਗ-ਇਨ ਖਾਤਾ ਵਰਤਦਾ ਹੈ। ਕੰਟੇਨਰ ਪ੍ਰੋਸੈਸ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਲੁਕਵੇਂ ਰੂਪ ਵਿੱਚ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ ਲੈਂਦੀ, ਉਦੋਂ ਵੀ ਜਦੋਂ ਕੰਟੇਨਰ ਉਸੇ ਮਸ਼ੀਨ ਉੱਤੇ ਚੱਲਦਾ ਹੈ ਅਤੇ VPN ਕਲਾਇੰਟ ਵੀ ਉੱਥੇ ਚੱਲਦਾ ਹੈ। ਪਹਿਲੀ ਹੱਦ ਨੈੱਟਵਰਕ ਰਾਹ ਹੈ: ਕੀ ਕੰਟੇਨਰ ਨਾਮ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ SMB ਪੋਰਟ ਤੱਕ TCP ਸੈਸ਼ਨ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ। ਦੂਜੀ ਪਛਾਣ ਹੈ: ਕੀ ਫਾਈਲ ਸਰਵਰ ਕੰਟੇਨਰ ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤਾ, ਵਰਕਲੋਡ ਨੂੰ ਲੋੜੀਂਦੇ ਅਧਿਕਾਰਾਂ ਨਾਲ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ।

ਦੋਹਾਂ ਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਮੰਨਣ ਨਾਲ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਚੱਕਰ ਬਣਦਾ ਹੈ—ਸੱਚਮੁੱਚ ਸ਼ੇਅਰ ਤੋਂ ਆਉਣ ਵਾਲੇ ਪਹੁੰਚ-ਇਨਕਾਰ ਜਵਾਬ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਫਾਇਰਵਾਲ ਨਿਯਮ ਚੌੜੇ ਕਰਨਾ।

ਕੰਟੇਨਰ ਦੀ ਆਪਣੀ ਬੇਨਤੀ ਦਾ ਪਿੱਛਾ ਕਰੋ

Windows ਕੰਟੇਨਰ ਨੈੱਟਵਰਕਿੰਗ Host Networking Service ਸੰਭਾਲਦੀ ਹੈ, ਜੋ ਆਪਣੇ ਨੈੱਟਵਰਕ ਨਾਮ-ਥਾਂ ਵਾਲੇ ਐਂਡਪੁਆਇੰਟ ਬਣਾਉਂਦੀ ਹੈ। ਤੁਹਾਡੇ ਚੁਣੇ ਮੋਡ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਐਂਡਪੁਆਇੰਟ ਅਨੁਵਾਦਿਤ, ਬ੍ਰਿਜਡ, ਜਾਂ ਹੋਸਟ ਨਾਲ ਸਾਂਝੇ ਨੈੱਟਵਰਕ ਨਾਲ ਜੁੜਿਆ ਹੈ। ਇਹ ਫੈਸਲਾ ਇੱਕੋ ਸਮੇਂ ਦੋ ਚੀਜ਼ਾਂ ਬਦਲਦਾ ਹੈ: ਕੰਟੇਨਰ ਕੀ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਾਈਲ ਸਰਵਰ ਕਿਹੜਾ ਸਰੋਤ ਪਤਾ ਦੇਖਦਾ ਹੈ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ ਕਿ ਕੰਟੇਨਰ ਆਪ ਕੀ ਦੇਖਦਾ ਹੈ। ਬਾਹਰ ਹੱਲ ਹੋਣ ਵਾਲਾ ਨਾਮ ਅੰਦਰ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੰਟੇਨਰ ਦੀ DNS ਸੰਰਚਨਾ ਹੋਸਟ ਦੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਅਨੁਵਾਦਿਤ ਐਂਡਪੁਆਇੰਟ ਅਜਿਹਾ ਸਰੋਤ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਦੀ ਫਾਈਲ ਸਰਵਰ ਦੇ ਨਿਯਮ ਉਮੀਦ ਨਹੀਂ ਕਰਦੇ।

docker exec -it app powershell -Command "Resolve-DnsName files.corp.example"
docker exec -it app powershell -Command "Test-NetConnection files.corp.example -Port 445"
docker exec -it app powershell -Command "Get-NetIPConfiguration"

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

ਪਛਾਣ ਇੱਕ ਵੱਖਰਾ ਫੈਸਲਾ ਹੈ

ਇੰਟਰਐਕਟਿਵ ਵਰਤੋਂਕਾਰ ਵੱਲੋਂ ਮੈਪ ਕੀਤਾ ਡਰਾਈਵ ਅੱਖਰ ਐਪਲੀਕੇਸ਼ਨ ਇੰਟਰਫੇਸ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਲੌਗ-ਆਨ ਸੈਸ਼ਨ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕੰਟੇਨਰ ਪ੍ਰੋਸੈਸ ਉਸ ਦਾ ਹਿੱਸਾ ਨਹੀਂ ਹੈ। UNC ਰਾਹ ਵਰਤੋ ਅਤੇ ਵਰਕਲੋਡ ਨੂੰ ਉਹ ਪਛਾਣ ਦਿਓ ਜੋ ਤੈਨਾਤੀ ਮਾਡਲ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਜਿੱਥੇ ਡੋਮੇਨ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ, ਉੱਥੇ ਗਰੁੱਪ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾ ਖਾਤਾ (gMSA) ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵਿਸ਼ੇਸ਼ਤਾ ਰਾਹੀਂ ਪ੍ਰਬੰਧਿਤ ਪਛਾਣ ਦਿੰਦਾ ਹੈ।

Microsoft ਦੀ ਕੰਟੇਨਰ gMSA ਗਾਈਡ ਉਸ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਵਿਵਸਥਾ ਅਤੇ ਉਸ ਦੀਆਂ ਪੂਰਵ-ਸ਼ਰਤਾਂ ਦੱਸਦੀ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਡੋਮੇਨ ਮੈਂਬਰਸ਼ਿਪ ਅਤੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਲੈ ਸਕਣ ਵਾਲਾ ਹੋਸਟ ਸ਼ਾਮਲ ਹੈ। ਖਾਤਾ, ਪ੍ਰਾਪਤੀ, ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਪ੍ਰੋਸੈਸ ਪਛਾਣ ਅਤੇ ਸ਼ੇਅਰ ਅਧਿਕਾਰ—ਸਭ ਮੇਲ ਖਾਣੇ ਚਾਹੀਦੇ ਹਨ। VPN ਲੌਗਇਨ ਉਹ ਪਛਾਣ ਨਹੀਂ ਹੈ, ਅਤੇ ਹੋਸਟ ਵਰਤੋਂਕਾਰ ਦਾ ਸੈਸ਼ਨ ਦੁਹਰਾਉਣ ਲਈ ਇਮੇਜ ਵਿੱਚ ਪਾਸਵਰਡ ਪਕਾਉਣਾ ਸਥਾਈ ਖ਼ਤਰਾ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਫੇਲ ਹੋਣ ਵਾਲਾ ਪੜਾਅ ਦਿਖਾਈ ਦਿੰਦਾ ਰੱਖੋ

ਹੱਲ ਫੇਲ ਹੋਣਾ, ਕਨੈਕਸ਼ਨ ਇਨਕਾਰ ਅਤੇ ਪਹੁੰਚ ਇਨਕਾਰ ਲਈ ਵੱਖਰੇ ਸਬੂਤ ਚਾਹੀਦੇ ਹਨ। ਇਹ ਕ੍ਰਮਵਾਰ DNS ਸਵਾਲ, ਰਾਊਟਿੰਗ ਜਾਂ ਫਿਲਟਰਿੰਗ ਸਵਾਲ, ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ ਅਧਿਕਾਰ ਸਵਾਲ ਹਨ। ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਮ ਗਲਤੀ ਦੀ ਥਾਂ ਕੰਟੇਨਰ ਨੂੰ ਮਿਲਿਆ ਜਵਾਬ ਪੜ੍ਹੋ।

ਵਰਕਲੋਡ ਦੀ ਆਪਣੀ ਪਛਾਣ ਨਾਲ ਜਾਂਚ ਕਰੋ ਅਤੇ ਇਨਕਾਰ ਦੀ ਵੀ ਜਾਂਚ ਕਰੋ।

ਮੁੜ-ਕਨੈਕਟ ਦੀ ਯੋਜਨਾ ਬਣਾਓ

VPN ਰਾਹ ਡਿੱਗਦੇ ਹਨ। ਜਦੋਂ ਸੁਰੰਗ ਵਾਪਸ ਆਉਂਦੀ ਹੈ, ਐਂਡਪੁਆਇੰਟ ਕਿਸੇ ਹੋਰ ਅਨੁਵਾਦਿਤ ਪਤੇ ਨਾਲ ਵਾਪਸ ਆ ਸਕਦਾ ਹੈ, ਅਤੇ ਮੌਜੂਦਾ SMB ਸੈਸ਼ਨ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਪਤਾ ਲੱਗੇ ਬਿਨਾਂ ਮਰਿਆ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਸੰਭਾਲੋ: ਰਾਹ ਅਤੇ ਪਛਾਣ ਮੁੜ ਸਥਾਪਿਤ ਕਰੋ, ਕਾਰਵਾਈ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਅਤੇ ਕੁਝ ਨਾ ਹੋਣ ਦਾ ਮੰਨਣ ਦੀ ਥਾਂ ਅਣਜਾਣ ਨਤੀਜੇ ਵਾਲੀ ਫਾਈਲ ਕਾਰਵਾਈ ਮਿਲਾਓ।

ਨੈੱਟਵਰਕ ਮੋਡ, DNS ਸਰੋਤ ਅਤੇ ਪਛਾਣ ਦੀ ਵਿਵਸਥਾ ਤੈਨਾਤੀ ਨੋਟਾਂ ਵਿੱਚ ਦਰਜ ਕਰੋ। ਅਗਲੀ ਫੇਲ੍ਹ ਠੀਕ ਇਹਨਾਂ ਤਿੰਨ ਤੱਥਾਂ ਬਾਰੇ ਹੋਵੇਗੀ।