VPN ਕੰਟੇਨਰ ਦਾ ਨੈੱਟਵਰਕ ਸਾਂਝਾ ਕਰਨਾ: DNS ਨਾਲ ਕੀ ਹੁੰਦਾ ਹੈ

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

ਕਦਮ 1: ਹੋਸਟ ਤੋਂ ਨਹੀਂ, ਐਪ ਤੋਂ ਟੈਸਟ ਕਰੋ

ਜਿਸ ਕੰਟੇਨਰ ਵਿੱਚ ਸਮੱਸਿਆ ਹੈ ਉਸ ਦੇ ਅੰਦਰ ਲੁੱਕਅਪ ਚਲਾਓ, ਹੋਸਟ ਉੱਤੇ ਨਹੀਂ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਨਹੀਂ। docker exec app-container getent hosts db.internal ਇੱਕੋ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਇਸ ਪ੍ਰਕਿਰਿਆ ਦਾ ਰਿਜ਼ੌਲਵਰ ਕੀ ਵਾਪਸ ਕਰਦਾ ਹੈ।

ਜੇ ਹੋਸਟ ਨਾਮ ਹੱਲ ਕਰਦਾ ਹੈ ਅਤੇ ਕੰਟੇਨਰ ਨਹੀਂ, ਤਾਂ ਤੁਸੀਂ ਖਰਾਬੀ ਲੱਭ ਲਈ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ ਸਭ ਕੁਝ ਇਸਨੂੰ ਠੀਕ ਕਰਨ ਦਾ ਸਮਰਥਿਤ ਤਰੀਕਾ ਚੁਣਨਾ ਹੈ।

ਕਦਮ 2: ਰਨਟਾਈਮ ਦਾ ਸਮਰਥਿਤ ਮਾਡਲ ਪੜ੍ਹੋ

Docker ਦਾ ਨੈੱਟਵਰਕ ਦਸਤਾਵੇਜ਼ ਦੂਜੇ ਕੰਟੇਨਰ ਦਾ ਨੈੱਟਵਰਕ ਮੋਡ ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਕੰਟੇਨਰਾਂ ਲਈ DNS ਫਲੈਗਾਂ ਉੱਤੇ ਪਾਬੰਦੀਆਂ ਦਰਜ ਕਰਦਾ ਹੈ। Compose ਵਿੱਚ network_mode: service:vpn ਐਪ ਨੂੰ VPN ਕੰਟੇਨਰ ਦੇ ਨੇਮਸਪੇਸ ਨਾਲ ਬੰਨ੍ਹਦਾ ਹੈ, ਅਤੇ ਹਰ ਸੇਵਾ ਲਈ dns ਸੈਟਿੰਗਾਂ ਆਮ ਸੇਵਾ ਵਾਂਗ ਵਿਵਹਾਰ ਨਹੀਂ ਕਰਦੀਆਂ। ਤੁਹਾਨੂੰ ਮਿਲਣ ਵਾਲਾ ਹੱਲ ਉਹੀ ਹੈ ਜੋ ਸਾਂਝੇ ਨੇਮਸਪੇਸ ਕੋਲ ਹੈ।

ਵਰਤੋਂਕਾਰ-ਪਰਿਭਾਸ਼ਿਤ ਬ੍ਰਿਜ ਨੈੱਟਵਰਕ ਵੀ Docker ਦੇ ਅੰਦਰੂਨੀ DNS ਨੂੰ ਡਿਫਾਲਟ ਬ੍ਰਿਜ ਨਾਲੋਂ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਵਰਤਦੇ ਹਨ। ਇਸ ਲਈ dns ਕੰਮ ਕਰਦੇ ਬ੍ਰਿਜ ਉਦਾਹਰਨ ਤੋਂ ਕਾਪੀ ਕੀਤਾ ਖੰਡ ਸਾਂਝੇ ਸਟੈਕ ਵਿੱਚ ਕੁਝ ਵੀ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਖੰਡ ਕਾਪੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵਿਵਸਥਾ ਜਾਂਚੋ।

ਲੂਪਬੈਕ ਪਤਾ ਹਮੇਸ਼ਾ ਸੰਬੰਧਿਤ ਨੈੱਟਵਰਕ ਸੰਦਰਭ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਸਾਂਝੇ ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰ, 127.0.0.1 ਹੋਸਟ ਦਾ ਰਿਜ਼ੌਲਵਰ ਨਹੀਂ ਹੈ।

ਕਦਮ 3: ਕਿਊਰੀ ਨੂੰ ਇਸਦੇ ਪ੍ਰਾਪਤਕਰਤਾ ਤੱਕ ਲੈ ਜਾਓ

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

ਬ੍ਰਾਊਜ਼ਰ ਦਾ IP-ਜਾਂਚ ਪੰਨਾ ਤੁਹਾਨੂੰ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਨਾਮ ਕਿਊਰੀਆਂ ਕਿੱਥੇ ਗਈਆਂ। ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਇੱਕ HTTP ਕਨੈਕਸ਼ਨ ਕਿੱਥੇ ਗਿਆ।

ਕਦਮ 4: ਦੋ ਅਸਫਲਤਾ ਸ਼੍ਰੇਣੀਆਂ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਠੀਕ ਕਰੋ

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

ਜੇ ਦੋਵੇਂ ਸ਼੍ਰੇਣੀਆਂ ਅਸਫਲ ਹੋਣ, ਰਿਜ਼ੌਲਵਰ ਤੱਕ ਪਹੁੰਚ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਸਿਰਫ਼ ਇੱਕ ਅਸਫਲ ਹੋਵੇ, ਖੋਜ ਵਿਧੀ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਦੋਵਾਂ ਦੇ ਮਾਲਕ ਵੱਖਰੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਮੁਰੰਮਤ ਕਦੇ ਦੋਵਾਂ ਨੂੰ ਨਹੀਂ ਢਕਦੀ।

ਕਦਮ 5: ਮੁੜ ਬਣਾਉਣ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ

ਰਨਟਾਈਮ ਦੀ ਸਮਰਥਿਤ ਵਿਧੀ ਰਾਹੀਂ ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲੋ, ਫਿਰ ਚੱਲ ਰਹੇ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਫਾਈਲਾਂ ਸੰਪਾਦਿਤ ਕਰਨ ਦੀ ਬਜਾਏ ਕੰਟੇਨਰ ਦੁਬਾਰਾ ਬਣਾਓ। ਨਵਾਂ ਨਿੱਜੀ ਨਾਮ, ਨਵਾਂ ਜਨਤਕ ਨਾਮ ਅਤੇ ਲੁੱਕਅਪ ਤੋਂ ਬਾਅਦ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਬੇਨਤੀ ਟੈਸਟ ਕਰੋ। /etc/resolv.conf ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਦਾ ਸੰਪਾਦਨ ਮੁੜ ਬਣਾਉਣ ਵੇਲੇ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਯਕੀਨ ਦਿਵਾਏਗਾ ਕਿ ਮੁਰੰਮਤ ਹੋ ਗਈ ਜਦੋਂ ਕਿ ਹੋਈ ਨਹੀਂ।

ਸਾਂਝੇ ਨੈੱਟਵਰਕ ਪਰਿਭਾਸ਼ਾ ਦੇ ਕੋਲ ਰਿਜ਼ੌਲਵਰ ਦਾ ਮਾਲਕ ਅਤੇ ਉਮੀਦ ਕੀਤਾ ਨੇਮਸਪੇਸ ਲਿਖੋ। ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਦੋਵੇਂ ਚਾਹੀਦੇ ਹੋਣਗੇ।