Docker: VPN ਸੈਸ਼ਨ ਦੌਰਾਨ ਕੋਈ ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਪਤਾ ਪੂਲ ਬਾਕੀ ਨਹੀਂ

ਨਾਕਾਮੀ ਖਾਸ ਹੈ: Docker ਨੂੰ ਨਵੇਂ ਬ੍ਰਿਜ ਨੈੱਟਵਰਕ ਲਈ ਸਵੀਕਾਰਯੋਗ ਸਵੈਚਾਲਿਤ ਸਬਨੈੱਟ ਨਹੀਂ ਮਿਲਦਾ। ਇਸਦਾ ਅਰਥ ਇਹ ਨਹੀਂ ਕਿ ਮਸ਼ੀਨ ਦੇ ਪਤੇ ਖ਼ਤਮ ਹੋ ਗਏ ਹਨ, ਅਤੇ ਨਾ ਹੀ ਇਹ ਕਿ VPN ਟੁੱਟ ਗਿਆ ਹੈ। ਨਿਦਾਨ ਦੋ ਸਵਾਲ ਤੈਅ ਕਰਦੇ ਹਨ: ਡੈਮਨ ਕਿਹੜੇ ਉਮੀਦਵਾਰ ਬਲਾਕ ਵੇਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸ ਵਾਤਾਵਰਨ ਵਿੱਚ ਇਸਦਾ ਵੰਡਕਰਤਾ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜੇ ਬਾਹਰ ਰੱਖਦਾ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਨਿਪਟਾਓ, ਕਿਉਂਕਿ ਪਹਿਲੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਮਿਲਣ ਤੱਕ ਦੂਜੇ ਸਵਾਲ ਦਾ ਕੋਈ ਅਰਥ ਨਹੀਂ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੀ ਨਾਕਾਮ ਹੋਇਆ

ਹੇਠਾਂ ਦਿੱਤੇ ਕਦਮ ਉਸੇ ਹੋਸਟ ਤੋਂ ਚਲਾਓ ਜੋ ਡੈਮਨ ਚਲਾਉਂਦਾ ਹੈ। ਦੂਰਲੇ ਸੰਦਰਭ ਨਾਲ ਗੱਲ ਕਰਦਾ ਸ਼ੈੱਲ ਕਿਸੇ ਹੋਰ ਮਸ਼ੀਨ ਦਾ ਵਰਣਨ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਹ ਇੱਕੋ ਗਲਤੀ ਇੱਕ ਘੰਟਾ ਬਰਬਾਦ ਕਰ ਸਕਦੀ ਹੈ।

ਉਸੇ ਸਮੇਂ ਟਿਕਟ ਵਿੱਚ Engine ਸੰਸਕਰਣ ਵੀ ਦਰਜ ਕਰੋ। ਇਸ ਰਨਬੁੱਕ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਦੀ ਹਰ ਹਿਊਰਿਸਟਿਕ ਸੰਸਕਰਣ-ਸੀਮਿਤ ਹੈ, ਅਤੇ ਸੰਸਕਰਣ ਤੋਂ ਬਿਨਾਂ ਦਾਅਵਾ ਅਫਵਾਹ ਹੈ।

ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਵੰਡਾਂ ਗਿਣੋ

ਨੈੱਟਵਰਕਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ, ਫਿਰ ਮਹੱਤਵਪੂਰਨ ਲੋਕਾਂ ਦੀ ਜਾਂਚ ਕਰੋ: docker network ls, ਫਿਰ docker network inspect NETWORK_NAME। ਉਹਨਾਂ ਦੇ IPAM ਸਬਨੈੱਟ ਅਤੇ ਹਰੇਕ ਨਾਲ ਜੁੜੇ ਕੰਟੇਨਰ ਪੜ੍ਹੋ। ਕਈ Compose ਪ੍ਰੋਜੈਕਟ ਆਪਣੀ ਕੰਟੇਨਰ ਗਿਣਤੀ ਤੋਂ ਸੰਕੇਤ ਮਿਲਣ ਨਾਲੋਂ ਵੱਧ ਬਲਾਕ ਖਪਤ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਹਰ ਪ੍ਰੋਜੈਕਟ ਆਪਣਾ ਡਿਫ਼ਾਲਟ ਨੈੱਟਵਰਕ ਬਣਾਉਣ ਵੱਲ ਝੁਕਦਾ ਹੈ। ਰੁਕਿਆ ਕੰਟੇਨਰ ਆਪਣੇ ਨੈੱਟਵਰਕ ਦੀ ਵੰਡ ਜਾਰੀ ਨਹੀਂ ਕਰਦਾ।

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

ਗਿਣਤੀ ਲਿਖ ਲਓ। ਇਹੀ ਉਹ ਆਧਾਰ-ਰੇਖਾ ਹੈ ਜੋ ਦੱਸਦੀ ਹੈ ਕਿ ਅਗਲੇ ਬਦਲਾਅ ਨੇ ਮਦਦ ਕੀਤੀ ਜਾਂ ਨਹੀਂ।

ਡੈਮਨ ਰੂਟਾਂ ਨੂੰ ਕਿਵੇਂ ਵੇਖਦਾ ਹੈ, ਇਸਦੀ ਤੁਲਨਾ ਕਰੋ

VPN ਉਮੀਦਵਾਰ ਚੋਣ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਕਿਵੇਂ, ਇਹ ਸਟੀਕ ਲਾਗੂਕਰਨ ਤੈਅ ਕਰਦਾ ਹੈ। Linux ਉੱਤੇ Moby 28.2.2 ਵਿੱਚ, InferReservedNetworks ਨੇਮਸਰਵਰ ਪਤੇ ਅਤੇ ਕੁਝ ਆਨ-ਲਿੰਕ IPv4 ਰੂਟ ਇਕੱਠੇ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਹਰ ਸਾਰਣੀ ਦੇ ਹਰ ਰੂਟ ਨੂੰ ਸਿੱਧਾ ਰਾਖਵਾਂ ਨਹੀਂ ਰੱਖਦਾ। ਇਕੱਠੇ ਕੀਤੇ ਲਿੰਕ ਰੂਟ ਅਣ-ਨਿਰਧਾਰਿਤ ਟਿਕਾਣਾ ਪਤੇ ਨੂੰ ਵੀ ਬਾਹਰ ਰੱਖਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕਲਾ 0.0.0.0/1 ਰੂਟ ਸਾਰੇ ਪਤੇ ਰਾਖਵੇਂ ਨਹੀਂ ਰੱਖਦਾ। ਕੋਈ ਹੋਰ ਚੌੜਾ ਆਨ-ਲਿੰਕ ਪ੍ਰੀਫ਼ਿਕਸ, ਜਿਵੇਂ 128.0.0.0/1, ਜਾਣੀਆਂ-ਪਛਾਣੀਆਂ 172 ਅਤੇ 192 ਉਮੀਦਵਾਰ ਲੜੀਆਂ ਨੂੰ ਕੱਟ ਸਕਦਾ ਹੈ।

VPN ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ip -4 route show table all ਦੀ ਡੈਮਨ ਦੇ ਹੋਸਟ ਉੱਤੇ ਤੁਲਨਾ ਕਰੋ। ਅੰਤਰ ਹੀ ਸਬੂਤ ਹੈ, ਅਤੇ ਸੰਸਕਰਣ ਹੀ ਦਾਅਵੇ ਦਾ ਦਾਇਰਾ ਹੈ।

ਇੱਕ ਸੰਸਕਰਣ ਦੀ ਹਿਊਰਿਸਟਿਕ ਨੂੰ ਸਾਰੇ ਸੰਸਕਰਣਾਂ ਉੱਤੇ ਆਮ ਨਾ ਬਣਾਓ। ਇਸੇ ਤਰ੍ਹਾਂ ਹੀ ਕੋਈ ਫੋਰਮ ਜਵਾਬ ਨੀਤੀ ਬਦਲਾਅ ਬਣ ਜਾਂਦਾ ਹੈ।

ਜੋ ਸਭ ਤੋਂ ਛੋਟਾ ਸੁਧਾਰ ਕੰਮ ਕਰੇ, ਉਹ ਚੁਣੋ

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

default-address-pools ਬਦਲਣਾ ਭਵਿੱਖ ਦੀਆਂ ਵੰਡਾਂ ਬਾਰੇ ਵਿਆਪਕ ਨੀਤੀ ਹੈ। ਕੋਈ ਟਕਰਾਅ-ਰਹਿਤ ਆਧਾਰ ਅਤੇ ਢੁਕਵਾਂ ਵੰਡਿਆ ਆਕਾਰ ਚੁਣੋ, ਇਸਨੂੰ ਮੌਜੂਦਾ ਡੈਮਨ ਸੈਟਿੰਗਾਂ ਨਾਲ ਮਿਲਾਓ, ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਰੀਸਟਾਰਟ ਪ੍ਰਭਾਵ ਦੀ ਯੋਜਨਾ ਬਣਾਓ। ਮੌਜੂਦਾ ਨੈੱਟਵਰਕ ਚੁੱਪਚਾਪ ਮੁੜ-ਸੰਖਿਆਬੱਧ ਨਹੀਂ ਹੁੰਦੇ।

ਵੰਡ ਸਫਲ ਹੋਣ ਲਈ ਕੰਪਨੀ ਦੇ ਰੂਟ ਪੁਸ਼ ਬੰਦ ਨਾ ਕਰੋ। ਸਪੱਸ਼ਟ ਪਤਾ ਯੋਜਨਾ ਆਮ ਤੌਰ ’ਤੇ ਲਾਜ਼ਮੀ ਨੀਤੀ ਨੂੰ ਕਮਜ਼ੋਰ ਕੀਤੇ ਬਿਨਾਂ ਸਥਾਨਕ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦੀ ਹੈ।

ਵੰਡ ਅਤੇ ਰੂਟਿੰਗ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਸਵੀਕਾਰ ਕਰੋ

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

ਰੂਟ ਅੰਤਰ ਅਤੇ ਪੂਲ ਗਿਣਤੀ ਨੂੰ ਬਦਲਾਅ ਰਿਕਾਰਡ ਨਾਲ ਰੱਖੋ, ਕਿਉਂਕਿ ਅਗਲਾ VPN ਕਲਾਇੰਟ ਅਪਡੇਟ Docker ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਪਹਿਲੇ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ।

ਰਨਬੁੱਕ ਤਦ ਪੂਰੀ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕੋਈ ਹੋਰ ਇਹ ਦੋਵੇਂ ਜਾਂਚਾਂ ਦੁਹਰਾ ਕੇ ਉਹੀ ਜਵਾਬ ਲੈ ਸਕੇ।