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

ਪਹਿਲਾਂ ਨੀਤੀ ਦਾ ਨਾਮ ਦਿਓ, ਫਿਰ ਉਹ ਪਲੇਟਫਾਰਮ ਪ੍ਰਿਮਿਟਿਵ ਚੁਣੋ ਜੋ ਇਸਨੂੰ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ।

ਤਿੰਨ ਸੈਟਿੰਗਾਂ ਜੋ ਮਿਲਾਉਣਾ ਸੌਖਾ ਹੈ

ਖੋਜ ਪ੍ਰਤਿਅਯ ਛੋਟੇ ਨਾਮ ਦਾ ਵਿਸਤਾਰ ਕਰਦਾ ਹੈ: files ਟਾਈਪ ਕਰਨ 'ਤੇ ਇਹ files.corp.example ਬਣ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਰਿਜ਼ਾਲਵਰ ਪ੍ਰਤਿਅਯਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਅਜ਼ਮਾਉਂਦਾ ਹੈ। ਰੂਟਿੰਗ ਡੋਮੇਨ ਚੁਣਦਾ ਹੈ ਕਿ ਨਾਮ-ਥਾਂ ਦੇ ਅੰਦਰ ਬੇਨਤੀਆਂ ਦਾ ਜਵਾਬ ਕਿਹੜਾ ਰਿਜ਼ਾਲਵਰ ਦੇਵੇਗਾ। IP ਰੂਟ ਸਿਰਫ ਚੁਣੇ ਹੋਏ ਰਿਜ਼ਾਲਵਰ ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਤਿੰਨ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਨੂੰ ਦੂਜੇ ਨਾਲ ਬਦਲਣ 'ਤੇ ਅਜਿਹੀ ਕਨਫਿਗਰੇਸ਼ਨ ਬਣਦੀ ਹੈ ਜੋ ਸਹੀ ਦਿਸਦੀ ਹੈ ਅਤੇ ਕੁਝ ਵੀ ਹੱਲ ਨਹੀਂ ਕਰਦੀ।

ਉਲਝਣ ਦੀ ਕੀਮਤ ਹੈ: ਖੋਜ ਪ੍ਰਤਿਅਯ ਜੋੜਨ ਨਾਲ ਹਰ ਛੋਟਾ ਨਾਮ ਕੰਮ ਵਾਲੇ ਰਿਜ਼ਾਲਵਰ 'ਤੇ ਜਾਂਦਾ ਹੈ, ਉਹ ਨਾਮ ਵੀ ਜੋ ਕਿਤੇ ਹੋਰ ਦੇ ਹਨ। ਰੂਟਿੰਗ ਡੋਮੇਨ ਚੁਣਨ ਨਾਲ ਅਸੰਬੰਧਿਤ ਬੇਨਤੀਆਂ ਸਥਾਨਕ ਰਿਜ਼ਾਲਵਰ 'ਤੇ ਰਹਿੰਦੀਆਂ ਹਨ ਅਤੇ ਫਿਰ ਵੀ *.corp.example ਟਨਲ ਰਾਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।

Linux: ਸਿਰਫ-ਰੂਟ ਡੋਮੇਨ, ਖੋਜ ਪ੍ਰਤਿਅਯ ਨਹੀਂ

systemd-resolved 'ਤੇ ਟਿਲਡੇ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲਾ ਡੋਮੇਨ ਸਿਰਫ-ਰੂਟ ਡੋਮੇਨ ਹੁੰਦਾ ਹੈ, ਭਾਵ ਉਸ ਨਾਮ-ਥਾਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਜੁੜੇ ਰਿਜ਼ਾਲਵਰ 'ਤੇ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਖੋਜ ਪ੍ਰਤਿਅਯ ਵੀ ਨਹੀਂ ਬਣਦੀਆਂ। resolvectl domain tun0 '~corp.example' ਇਹ ਸੈੱਟ ਕਰਦਾ ਹੈ, ਅਤੇ resolvectl dns tun0 10.8.0.1 ਸਰਵਰ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ। ਦੋਵੇਂ ਸੈਟਿੰਗਾਂ ਇੰਟਰਫੇਸ ਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਇਸ ਦੇ ਨਾਲ ਹੀ ਗਾਇਬ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਟਿਲਡੇ ਹੀ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਸ ਤੋਂ ਬਿਨਾਂ ਛੋਟੇ ਨਾਮ ਕੰਮ ਵਾਲੇ ਰਿਜ਼ਾਲਵਰ ਰਾਹੀਂ ਹੱਲ ਹੋਣ ਲੱਗਦੇ ਹਨ।

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

Windows ਨੂੰ ਨਾਮ-ਥਾਂ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ, ਪ੍ਰਤਿਅਯ ਨਹੀਂ

Windows ਵੰਡੀ DNS ਨੀਤੀ ਨੂੰ Name Resolution Policy Table ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਅਡੈਪਟਰ ਦੇ DNS ਪ੍ਰਤਿਅਯ ਵਿੱਚ ਨਹੀਂ। ਨਿਯਮ ਨਾਮ-ਥਾਂ ਨੂੰ ਖਾਸ ਸਰਵਰਾਂ ਨਾਲ ਜੋੜਦਾ ਹੈ: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1। ਸਿਰਫ ਪ੍ਰਤਿਅਯ ਸੈੱਟ ਕਰਨ ਨਾਲ ਛੋਟੇ ਨਾਮ ਕਿਵੇਂ ਦਿਸਦੇ ਹਨ ਉਹ ਬਦਲਦਾ ਹੈ; ਇਹ ਬੇਨਤੀ ਨੂੰ ਕਿਸੇ ਹੋਰ ਸਰਵਰ ਵੱਲ ਨਹੀਂ ਭੇਜਦਾ।

ਕਨੈਕਟ ਕਰਨ ਤੋਂ ਬਾਅਦ Get-DnsClientNrptPolicy ਨਾਲ ਪ੍ਰਭਾਵੀ ਨੀਤੀ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਪਿਛਲੇ ਕਨੈਕਸ਼ਨ ਦਾ ਨਿਯਮ ਟਨਲ ਤੋਂ ਵੱਧ ਚਿਰ ਰਹਿ ਸਕਦਾ ਹੈ। ਟਨਲ ਡਿੱਗਣ 'ਤੇ ਨਿਯਮ ਨਾਮ ਨਾਲ ਹਟਾਓ, ਅਤੇ ਸਫਾਈ ਸਹੀ ਐਂਟਰੀ 'ਤੇ ਹੋਵੇ ਇਸ ਲਈ ਡਿਸਪਲੇ ਨਾਮ ਸਥਿਰ ਰੱਖੋ।

ਹਰ ਪਲੇਟਫਾਰਮ ਲਈ ਇੱਕ ਰਿਜ਼ਾਲਵਰ ਮਾਲਕ

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

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

ਨਤੀਜਾ ਜਾਂਚੋ, ਪ੍ਰੋਫਾਈਲ ਦਾ ਪਾਠ ਨਹੀਂ

ਟਨਲ ਰਾਹੀਂ ਜਾਣ ਵਾਲਾ ਇੱਕ ਨਾਮ ਅਤੇ ਨਾ ਜਾਣ ਵਾਲਾ ਇੱਕ ਨਾਮ ਹਰ ਪਲੇਟਫਾਰਮ 'ਤੇ ਹੱਲ ਕਰੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਿਹੜੇ ਸਰਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ। resolvectl query host.corp.example ਅਤੇ Resolve-DnsName host.corp.example ਦੋਵੇਂ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਸਰਵਰ ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ। ਮੁੜ ਕਨੈਕਟ ਤੋਂ ਬਾਅਦ ਦੁਹਰਾਓ। ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਟਨਲ ਦਾ ਰਿਜ਼ਾਲਵਰ ਉਸ ਪਤੇ 'ਤੇ ਪਹੁੰਚਯੋਗ ਹੈ ਜੋ ਪ੍ਰੋਫਾਈਲ ਧੱਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰਲੇ ਸਰਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੀ ਸਹੀ ਨੀਤੀ ਵੀ ਬਿਨਾਂ ਨੀਤੀ ਦੇ ਜਿਹੀ ਫੇਲ ਹੁੰਦੀ ਹੈ।

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

ਸੰਬੰਧਿਤ ਲੇਖ