ਕਿਹੜਾ ਲਿੰਕ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਸਪਲਿਟ-ਟਨਲ VPN DNS ਲਈ ਰੂਟਿੰਗ ਡੋਮੇਨ

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

ਪਹਿਲਾ ਕਦਮ: ਰੂਟ ਨੂੰ ਰਿਜ਼ੌਲਵਰ ਤੋਂ ਵੱਖ ਕਰੋ

ipv4.never-default ਰੂਟਿੰਗ ਦੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ NetworkManager ਨੂੰ ਇਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸਾਰੇ IPv4 ਟ੍ਰੈਫਿਕ ਦਾ ਰਾਹ ਵਜੋਂ ਸਥਾਪਿਤ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ। DNS ਰੂਟਿੰਗ ਡੋਮੇਨ ਹੋਰ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਮਿਲਦੇ ਸਫਿਕਸ ਲਈ ਕਿਹੜੇ ਲਿੰਕ ਦੇ ਨਾਮ ਸਰਵਰ ਕਿਊਰੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ। ਕੋਈ ਵੀ ਦੂਜੇ ਨੂੰ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਸਾਲਾਂ ਤੱਕ ਇੱਕ ਰੱਖ ਸਕਦਾ ਹੈ ਜਦਕਿ ਦੂਜਾ ਗੁੰਮ ਹੋਵੇ। ਸਿਰਫ਼-ਰੂਟ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟਨਲ ਕੰਪਨੀ ਦੇ ਸਬਨੈੱਟ ਲੈ ਜਾਂਦੀ ਹੈ ਅਤੇ ਉਸ ਦਾ ਰਿਜ਼ੌਲਵਰ ਕੰਪਨੀ ਦੇ ਨਾਮਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਬਾਕੀ ਸਭ ਅਛੂਤਾ ਰਹਿੰਦਾ ਹੈ।

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

ਦੂਜਾ ਕਦਮ: ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਸਿਰਫ਼-ਰੂਟਿੰਗ ਡੋਮੇਨ ਜੋੜੋ

ਮੰਨ ਲਓ ਕਿ ਕਨੈਕਸ਼ਨ ਦਾ ਨਾਮ corp-vpn ਹੈ, ਕੰਪਨੀ ਦਾ ਸਫਿਕਸ internal.example ਹੈ, ਅਤੇ ਟਨਲ ਦਾ ਰਿਜ਼ੌਲਵਰ ਪਹਿਲਾਂ ਹੀ ਪਹੁੰਚ ਯੋਗ ਹੈ। ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਮੁੱਲ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਹੇਠਲੇ ਆਦੇਸ਼ ਉਹਨਾਂ ਪ੍ਰਾਪਰਟੀਆਂ ਨੂੰ ਬਦਲਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਐਂਟਰੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

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

ਸ਼ੁਰੂ ਦਾ ਟਿਲਡਾ ਸਿਰਫ਼-ਰੂਟਿੰਗ ਡੋਮੇਨ ਦਰਸਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਮਿਲਦੀਆਂ ਕਿਊਰੀਆਂ ਇਸ ਲਿੰਕ ਦੇ ਸਰਵਰਾਂ ਨੂੰ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਸਫਿਕਸ ਛੋਟੇ ਨਾਮਾਂ ਵਿੱਚ ਨਹੀਂ ਜੁੜਦਾ। ਟਿਲਡਾ ਹਟਾਓ ਤਾਂ ਉਹੀ ਸਟਰਿੰਗ ਖੋਜ ਸਫਿਕਸ ਵੀ ਬਣ ਜਾਂਦਾ ਹੈ, ਜੋ ਲੋਕ ਸ਼ਾਇਦ ਹੀ ਚਾਹੁੰਦੇ ਹਨ। ਉੱਪਰਲੀਆਂ ਦੋਵੇਂ ਸੈਟਿੰਗਾਂ IPv4 ਹਨ, ਇਸ ਲਈ ਦੋਹਰੇ-ਸਟੈਕ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ipv6.never-default ਅਤੇ ipv6.dns-search ਵਿੱਚ ਉਹੀ ਰੂਟਿੰਗ ਡੋਮੇਨ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ IPv6 ਪਾਸਾ ਡਿਫਾਲਟ ਰੂਟ ਵਰਤਦਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਉੱਥੇ ਅੰਦਰੂਨੀ ਨਾਮ ਫੇਲ ਹੁੰਦੇ ਹਨ।

ਤੀਜਾ ਕਦਮ: resolvectl ਨੂੰ ਪੁੱਛੋ ਕਿ ਕਿਹੜੇ ਲਿੰਕ ਨੇ ਜਵਾਬ ਦਿੱਤਾ

resolvectl status ਚਲਾਓ ਅਤੇ ਹਰ ਲਿੰਕ ਦੇ DNS ਸਰਵਰ ਅਤੇ ਡੋਮੇਨ ਪੜ੍ਹੋ, ਫਿਰ ਇੱਕ ਅਸਲੀ ਅੰਦਰੂਨੀ ਨਾਮ ਉੱਤੇ resolvectl query host.internal.example ਚਲਾਓ ਜਿਸ ਨੂੰ ਪੁੱਛਣ ਦੀ ਤੁਹਾਨੂੰ ਇਜਾਜ਼ਤ ਹੈ। ਦੂਜਾ ਆਦੇਸ਼ ਹੀ ਇੱਕੋ ਸਿੱਧਾ ਸਬੂਤ ਹੈ ਕਿ ਰੂਟਿੰਗ ਡੋਮੇਨ ਆਪਣਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਲਿੰਕ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ। ਸਿਰਫ਼ ਸਥਿਤੀ ਸੂਚੀ ਸੰਰਚਨਾ ਸਾਬਤ ਕਰਦੀ ਹੈ; ਕਿਊਰੀ ਹੱਲ ਸਾਬਤ ਕਰਦੀ ਹੈ।

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

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

ਚੌਥਾ ਕਦਮ: ਜਦੋਂ ਨਾਮ ਹੱਲ ਹੁੰਦਾ ਹੈ ਪਰ ਸੇਵਾ ਨਹੀਂ

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

ਇਸ ਸਵਾਲ ਨਾਲ ਘੁੰਮਦੀ Samba ਤਬਦੀਲੀ ਪਹੁੰਚ ਪਰਤ ਦੀ ਹੈ, DNS ਚੋਣ ਦੀ ਨਹੀਂ। ਨਾਮ-ਹੱਲ ਖਰਾਬੀ ਉੱਤੇ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਹੀ ਛੋਟੀ ਸਮੱਸਿਆ ਦੇ ਦੂਜੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ।

ਪੰਜਵਾਂ ਕਦਮ: ਗੁੰਮ ਡੋਮੇਨ ਠੀਕ ਕਰਨ ਲਈ ਰਿਜ਼ੌਲਵਰ ਨਾ ਬਦਲੋ

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

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