ip netns exec ਅਤੇ DNS: ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰ ਨਾਮ ਕਿਉਂ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ

ਇੱਕ ਕਮਾਂਡ VPN ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰ 10.8.0.5 ਤੱਕ ਕਿਸੇ ਸ਼ਿਕਾਇਤ ਤੋਂ ਬਿਨਾਂ ਪਹੁੰਚਦੀ ਹੈ, ਅਤੇ ਉਹੀ ਕਮਾਂਡ ਉਸੇ ਪਲ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਉਹ ਹੋਸਟਨਾਮ ਵਰਤਦੀ ਹੈ। ਨੇਮਸਪੇਸ ਦੇ ਆਪਣੇ ਇੰਟਰਫ਼ੇਸ, ਰੂਟ ਅਤੇ ਸਾਕਟ ਹੁੰਦੇ ਹਨ; ਆਪਣੀ ਰਿਜ਼ੋਲਵਰ ਫ਼ਾਈਲ ਨਹੀਂ ਹੁੰਦੀ। ਜੇ ਕੋਈ ਉੱਥੇ ਇੱਕ ਨਾ ਰੱਖੇ, ਤਾਂ ਅੰਦਰਲਾ ਪ੍ਰੋਸੈਸ ਹੋਸਟ ਦੀ /etc/resolv.conf ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਅਜਿਹੇ ਸਰਵਰ ਨੂੰ ਪੁੱਛਦਾ ਹੈ ਜੋ ਉਸ ਨੈੱਟਵਰਕ ਸਟੈਕ ਤੋਂ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੋ ਸਕਦਾ ਹੈ।

ਇਹ ਰੂਟਿੰਗ ਦੀ ਨਹੀਂ, ਫ਼ਾਈਲ ਚੋਣ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਇਸੇ ਕਰਕੇ ਸੰਖਿਆਤਮਕ ਮੰਤਵ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ।

ਪ੍ਰੋਸੈਸ ਨੂੰ ਅਸਲ ਵਿੱਚ ਮਿਲਣ ਵਾਲਾ ਰਿਜ਼ੋਲਵਰ ਨਜ਼ਾਰਾ ਜਾਂਚੋ

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

ip netns add ਨਾਲ ਬਣੇ ਨੇਮਸਪੇਸ ਲਈ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਜਾਂਚ ਛੋਟੀ ਹੈ:

ip netns exec vpn cat /etc/resolv.conf

ਧਿਆਨ ਦਿਓ ਕਿ ਨਤੀਜਾ ਪਹੁੰਚਯੋਗ ਪਤਾ, ਕੋਈ loopback ਸਟਬ, ਜਾਂ ਵੱਖਰੀ ਪਹੁੰਚ ਵਾਲੀ ਥਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੀ ਸਿੰਬੋਲਿਕ ਲਿੰਕ ਦੱਸਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

exec ਸਹਾਇਕ ਅਸਲ ਵਿੱਚ ਕੀ ਮਾਊਂਟ ਕਰਦਾ ਹੈ

ip-netns ਟੂਲ ਹਰ ਨੇਮਸਪੇਸ ਦੀ ਸੰਰਚਨਾ /etc/netns/NAME/ ਅਧੀਨ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਕੋਈ ਪ੍ਰੋਸੈਸ ਲਾਂਚ ਕਰਦਾ ਹੈ, ਸਹਾਇਕ ਇੱਕ ਮਾਊਂਟ ਨੇਮਸਪੇਸ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਉਹ ਫ਼ਾਈਲਾਂ ਉਹਨਾਂ ਦੇ ਆਮ ਮਾਰਗਾਂ ਉੱਤੇ bind-mount ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਪ੍ਰੋਸੈਸ ਨੂੰ ਨੇਮਸਪੇਸ-ਵਿਸ਼ੇਸ਼ ਕਾਪੀ ਦਿਸੇ। ਇਹ ਇਸੇ ਖ਼ਾਸ ਲਾਂਚਰ ਦੀ ਸੁਵਿਧਾ ਹੈ। unshare ਜਾਂ ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਵਰਗੇ ਕਿਸੇ ਹੋਰ ਮਾਰਗ ਰਾਹੀਂ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਵਿੱਚ ਦਾਖ਼ਲ ਹੋਣਾ ਇਸ ਨੂੰ ਆਪਣੇ ਆਪ ਦੁਹਰਾਉਂਦਾ ਨਹੀਂ।

ਇੱਥੇ ਜਾਲ loopback ਰਿਜ਼ੋਲਵਰ ਹੈ: 127.0.0.53 ਦਾ ਮਤਲਬ ਨੇਮਸਪੇਸ ਦਾ ਆਪਣਾ loopback ਹੈ, ਹੋਸਟ ਦਾ ਸਟਬ ਨਹੀਂ। ਜੋ ਸਟਬ ਸਿਰਫ਼ ਹੋਸਟ ਨੇਮਸਪੇਸ ਵਿੱਚ ਸੁਣਦਾ ਹੈ ਉਹ ਨਵੇਂ ਵਿੱਚ ਸੇਵਾ ਨਹੀਂ ਬਣਦਾ।

ਉਹ ਰਿਜ਼ੋਲਵਰ ਚੁਣੋ ਜਿਸ ਤੱਕ ਨੇਮਸਪੇਸ ਪਹੁੰਚ ਸਕੇ

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

ਆਪਣਾ ਰਿਜ਼ੋਲਵਰ ਰੱਖਣ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ, ਜਿਵੇਂ DNS over HTTPS ਵਰਤਣ ਵਾਲੀ ਇੱਕ, ਫ਼ਾਈਲ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਜੇ ਟੂਲ ਦੀ ਆਪਣੀ DNS ਸੈਟਿੰਗ ਹੈ, ਤਾਂ resolv.conf ਬਦਲਣ ਦਾ ਉਸ ਉੱਤੇ ਅਸਰ ਨਹੀਂ ਪਵੇਗਾ, ਅਤੇ ਨੇਮਸਪੇਸ ਕਦੇ ਵੀ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ।

ਫ਼ਾਈਲ ਸਹੀ ਥਾਂ ਲਿਖੋ

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

ਰਨਬੁੱਕ ਵਿੱਚ ਫ਼ਾਈਲ ਦੀ ਸਮੱਗਰੀ ਦਰਜ ਕਰੋ। ਨਹੀਂ ਤਾਂ ਅਗਲਾ ਵਿਅਕਤੀ ਹੋਸਟ ਦਾ ਰਿਜ਼ੋਲਵਰ ਜਾਂਚੇਗਾ, ਕੰਮ ਕਰਦਾ ਜਵਾਬ ਵੇਖੇਗਾ ਅਤੇ ਸਿੱਟਾ ਕੱਢੇਗਾ ਕਿ ਨੇਮਸਪੇਸ ਠੀਕ ਹੈ।

ਪੂਰਾ ਮਾਰਗ ਦੁਬਾਰਾ ਜਾਂਚੋ

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

ਪੱਕਾ ਕਰੋ ਕਿ ਫ਼ਾਈਲ ਸ਼ੈੱਲ ਨਹੀਂ, ਪ੍ਰੋਸੈਸ ਪ੍ਰਾਪਤ ਕਰ ਰਿਹਾ ਹੈ। ਜੋ ਲੁੱਕਅਪ ਇੰਟਰਐਕਟਿਵ ਸ਼ੈੱਲ ਤੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਸੇਵਾ ਤੋਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਉਹ ਮਾਊਂਟ-ਸੰਦਰਭ ਬਾਰੇ ਖੋਜ ਹੈ, ਅਤੇ ਅਗਲੀ ਘਟਨਾ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਨੂੰ ਸਿਫ਼ਰ ਤੋਂ ਦੁਬਾਰਾ ਖੋਜਣ ਦੀ ਬਜਾਏ ਲਿਖ ਲੈਣਾ ਬਿਹਤਰ ਹੈ।