OpenVPN ਨੇ DNS ਸਰਵਰ ਭੇਜਿਆ, ਪਰ Linux ਇਸ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ

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

ਜਾਂਚ ਇੱਕ: ਕਨੈਕਸ਼ਨ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ

ਕਨੈਕਸ਼ਨ ਦਾ ਮਾਲਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੌਣ ਰਿਜ਼ੋਲਵਰ ਸੈਟਿੰਗਾਂ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ। ਸ਼ੈੱਲ ਤੋਂ ਸਿੱਧਾ openvpn ਹੁਕਮ ਆਪਣੀ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਬਿਨਾਂ ਕੁਝ ਨਹੀਂ ਰੱਖਦਾ, ਜਦੋਂ ਕਿ systemd ਯੂਨਿਟ, NetworkManager ਜਾਂ ਵਿਕਰੇਤਾ ਦਾ ਕਲਾਇੰਟ ਹਰ ਇੱਕ ਦਾ DNS ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦਾ ਆਪਣਾ ਤਰੀਕਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਕਿਰਿਆ ਸੂਚੀ ਅਤੇ ਯੂਨਿਟ ਦਾ ਨਾਮ ਪੜ੍ਹੋ।

ਕਮਾਂਡ-ਲਾਈਨ ਪ੍ਰਕਿਰਿਆ ਆਪਣੇ ਆਪ NetworkManager ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਹੈ, ਅਤੇ NetworkManager ਕਨੈਕਸ਼ਨ ਆਪਣੇ ਆਪ ਉਹ ਚੀਜ਼ ਨਹੀਂ ਹੈ ਜਿਸਨੇ resolv.conf ਲਿਖਿਆ। ਇਹ ਦੋ ਅਨੁਮਾਨ ਇਸ ਜਾਂਚ ਵਿੱਚ ਬਰਬਾਦ ਹੋਏ ਜ਼ਿਆਦਾਤਰ ਘੰਟਿਆਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ। ਪੁੱਛੋ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਜੋ ਇੰਟਰਫੇਸ ਦੇਖ ਰਹੇ ਹੋ ਉਸ ਲਈ ਕਿਹੜਾ ਹਿੱਸਾ DNS ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੇਗਾ।

ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਲਕ ਲਿਖ ਲਓ। ਹਰ ਅਗਲੀ ਜਾਂਚ ਇਸ ’ਤੇ ਨਿਰਭਰ ਹੈ।

ਜਾਂਚ ਦੋ: ਰਿਜ਼ੋਲਵਰ ਲਿੰਕ ਅਸਲ ਵਿੱਚ ਕੀ ਰੱਖਦੀ ਹੈ

systemd-resolved ਹੋਸਟ ’ਤੇ, resolvectl status ਹਰ ਲਿੰਕ ਨੂੰ ਇਸਦੇ DNS ਸਰਵਰਾਂ ਅਤੇ ਡੋਮੇਨਾਂ ਸਮੇਤ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ। ਟਨਲ ਲਿੰਕ ਲੱਭੋ ਅਤੇ ਇਸਦੀਆਂ ਐਂਟਰੀਆਂ ਪੜ੍ਹੋ, ਅਤੇ ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਇੰਟਰਫੇਸ ਦਾ ਨਾਮ tun0 ਹੈ, ਕਿਉਂਕਿ ਨੰਬਰ ਬਣਾਉਣ ਦੇ ਕ੍ਰਮ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ। ਜੇ ਭੇਜਿਆ ਪਤਾ ਲਿੰਕ ’ਤੇ ਨਹੀਂ ਹੈ, ਤਾਂ ਤਬਾਦਲਾ ਫੇਲ ਹੋਇਆ ਹੈ, ਕਵੈਰੀ ਨਹੀਂ।

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

ਕੋਈ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਰਿਜ਼ੋਲਵਰ ਆਉਟਪੁੱਟ ਵਿੱਚ ਲਿੰਕ ਦੇ ਨਾਮ ਦੀ VPN ਲੌਗ ਵਿੱਚ ਇੰਟਰਫੇਸ ਦੇ ਨਾਮ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਉੱਥੇ ਅਸੰਗਤੀ ਆਮ ਤੌਰ ’ਤੇ ਦੱਸਦੀ ਹੈ ਕਿ ਲੌਗ ਦੀ ਲਾਈਨ ਕਿਸੇ ਹੋਰ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਆਈ ਹੈ।

ਜਾਂਚ ਤਿੰਨ: ਕੀ ਨਾਮ-ਥਾਂ ਉਹ ਲਿੰਕ ਚੁਣਦੀ ਹੈ

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

ਡੋਮੇਨ ਨਿਰਧਾਰਨ ਜਾਂਚੋ, ਸਿਰਫ਼ ਸਰਵਰ ਪਤਾ ਨਹੀਂ। ~corp.example ਵਜੋਂ ਲਿਖਿਆ ਡੋਮੇਨ ਰੂਟਿੰਗ ਡੋਮੇਨ ਹੈ, ਅਤੇ ਟਿਲਡ ਨਿਸ਼ਾਨ ਬਦਲਦਾ ਹੈ ਕਿ ਨਾਮ ਕਿਵੇਂ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ।

ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਆਪਣਾ ਰਿਜ਼ੋਲਵਰ ਹੈ, ਤਾਂ ਸਿਸਟਮ ਸਾਧਨ ਨਾਲ ਨਹੀਂ, ਉਸੇ ਵਿਧੀ ਨਾਲ ਟੈਸਟ ਕਰੋ ਜੋ ਉਹ ਵਰਤਦੀ ਹੈ। ਸਿਸਟਮ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਟਾਲਣ ਵਾਲਾ ਕਵੈਰੀ ਸਾਧਨ ਲਿੰਕ ਦੀ ਸਥਿਤੀ ਭਾਵੇਂ ਜੋ ਵੀ ਹੋਵੇ ਸਫਲ ਹੋਵੇਗਾ।

ਜਾਂਚ ਚਾਰ: ਇੱਕ ਮਾਲਕ, ਦੋ ਨਹੀਂ

ਜੇ NetworkManager ਪਹਿਲਾਂ ਹੀ VPN ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਦੀ ਸਥਿਤੀ ਸੰਭਾਲਦਾ ਹੈ, ਤਾਂ ਅਸੰਬੰਧਿਤ ਹੁੱਕ ਸਕ੍ਰਿਪਟ ਜੋੜਨਾ ਮੁਕਾਬਲਾ ਕਰਨ ਵਾਲੇ ਲੇਖਕ ਬਣਾਉਂਦਾ ਹੈ। ਪੈਕੇਜ ਵੱਲੋਂ systemd-resolved ਲਈ ਦਿੱਤਾ ਹੁੱਕ ਸਮਰਥਿਤ ਏਕੀਕਰਣ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਖ਼ਾਸ ਜੀਵਨ-ਚੱਕਰ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ: script-security 2, ਇੱਕ up ਮਾਰਗ, up-restart, ਇੱਕ down ਮਾਰਗ ਅਤੇ down-pre। ਉਹ ਵਿਕਲਪ ਰਜਿਸਟਰੇਸ਼ਨ ਅਤੇ ਹਟਾਉਣ ਨੂੰ ਸਿਰਫ਼ ਪਹਿਲੇ ਕਨੈਕਸ਼ਨ ’ਤੇ ਨਹੀਂ, ਸਗੋਂ ਸਹੀ ਪਲਾਂ ’ਤੇ ਹੋਣ ਦਿੰਦੇ ਹਨ।

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

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

ਜਾਂਚ ਪੰਜ: ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਉਹੀ ਨਤੀਜਾ

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

ਦੁਬਾਰਾ ਕਨੈਕਸ਼ਨ ’ਤੇ ਪੰਜੇ ਜਾਂਚਾਂ ਪਾਸ ਹੋਣ ’ਤੇ ਹੀ ਤੁਸੀਂ ਕਹਿ ਸਕਦੇ ਹੋ ਕਿ ਭੇਜੀਆਂ ਸੈਟਿੰਗਾਂ ਵਰਤੋਂ ਵਿੱਚ ਹਨ। ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਸਭ ਕੁਝ ਇੱਕ ਖੁਸ਼ਕਿਸਮਤ ਪਲ ਦਾ ਸਨੈਪਸ਼ਾਟ ਹੈ।