Split-DNS ਕੈਪਚਰ: ਦੱਸੋ ਹਰ ਨਿਰੀਖਣ ਕਿੱਥੇ ਲਿਆ ਗਿਆ

ਦੋ ਲੋਕ ਇੱਕੋ Split-DNS ਸਮੱਸਿਆ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨ ਅਤੇ ਵੱਖਰੇ resolver ਪਤੇ ਪਾਉਂਦੇ ਹਨ। ਇੱਕ ਨੇ ਖੋਜ ਸਾਧਨ ਵਰਤਿਆ, ਦੂਜੇ ਨੇ ਅਡੈਪਟਰ ਉੱਤੇ ਪੈਕੇਟ ਕੈਪਚਰ ਕੀਤੇ, ਅਤੇ ਤੀਜੇ ਨੇ ਕਲਾਇੰਟ ਦਾ ਆਪਣਾ ਨਿਦਾਨ ਪੜ੍ਹਿਆ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਝੂਠ ਨਹੀਂ ਬੋਲ ਰਿਹਾ, ਅਤੇ ਕੋਈ ਇੱਕੋ ਪੜਾਅ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰ ਰਿਹਾ। ਨਿਰੀਖਣ ਬਿੰਦੂ ਦਾ ਨਾਮ ਦੇਣ ਨਾਲ ਵਿਰੋਧਾਭਾਸ ਨਕਸ਼ੇ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਖੋਜ, ਕਈ ਨਿਰੀਖਣ ਬਿੰਦੂ

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

ਹਰ ਇੱਕ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਇਕੱਲਾ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕੁਐਰੀ ਕਿੱਥੇ ਗਈ।

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

ਕਲਾਇੰਟ ਦਾ ਫਿਲਟਰ ਐਪ ਅਤੇ ਤਾਰ ਵਿਚਕਾਰ ਬੈਠਦਾ ਹੈ

Split-DNS ਵਾਲਾ VPN ਕਲਾਇੰਟ ਪੈਕੇਟ ਦੇ ਮਸ਼ੀਨ ਛੱਡਣ ਤੋਂ ਪਹਿਲਾਂ ਡੋਮੇਨ ਮੇਲ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਟਨਲ ਕੀਤੇ ਸਫਿਕਸ ਦੇ ਨਾਮ ਅੰਦਰੂਨੀ resolver ਕੋਲ ਜਾਂਦੇ ਹਨ; ਬਾਕੀ ਸਭ ਸਥਾਨਕ ਕੋਲ ਜਾਂਦਾ ਹੈ। ਫਿਲਟਰ ਨੀਤੀ ਹੈ, ਅਤੇ ਨੀਤੀ ਪਲੇਟਫਾਰਮ ਅਤੇ ਕਲਾਇੰਟ ਸੰਸਕਰਣ ਅਨੁਸਾਰ ਬਦਲ ਸਕਦੀ ਹੈ।

Cisco ਦੀ Secure Client Split-DNS ਅਗਵਾਈ ਡੋਮੇਨ ਮੇਲ ਅਤੇ Windows ਫਿਲਟਰ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹ ਵੱਖਰਾ ਕਰਦੀ ਹੈ ਕਿ ਐਪ ਮੂਲ resolver API ਵਰਤਦਿਆਂ ਕੀ ਦੇਖਦਾ ਹੈ ਅਤੇ nslookup ਵਰਗਾ ਸਾਧਨ ਕੀ ਦੇਖਦਾ ਹੈ। ਇਹੀ ਫ਼ਰਕ ਮੁੱਖ ਗੱਲ ਹੈ।

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

nslookup ਐਪ ਤੋਂ ਵੱਖਰਾ ਰਾਹ ਲੈਂਦਾ ਹੈ

nslookup ਆਪਣੀ DNS ਕੁਐਰੀ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੀ resolver ਨੀਤੀ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਇਸਨੂੰ ਕਿਸੇ ਖਾਸ ਸਰਵਰ ਨੂੰ ਕੋਈ ਖਾਸ ਸਵਾਲ ਪੁੱਛਣ ਲਈ ਲਾਹੇਵੰਦ ਸਾਧਨ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਐਪ ਕੀ ਅਨੁਭਵ ਕਰੇਗਾ ਇਹ ਜਾਂਚਣ ਲਈ ਭਰਮਾਉਣ ਵਾਲਾ ਸਾਧਨ।

Windows ਵਿੱਚ ਨਾਮ-ਹੱਲ ਨੀਤੀ ਸਾਰਣੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜਾ ਸਫਿਕਸ ਕਿਹੜਾ ਸਰਵਰ ਵਰਤਦਾ ਹੈ। ਇਸਨੂੰ ਪੜ੍ਹਨ ਨਾਲ ਉਹ ਨੀਤੀ ਦਿਸਦੀ ਹੈ ਜੋ ਐਪ ਅਪਣਾਏਗਾ, ਅਤੇ ਅਕਸਰ ਉਹੀ ਗੁੰਮ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ।

ਨੀਤੀ ਪੜ੍ਹੋ ਅਤੇ ਫਿਰ ਉਹੀ ਸਵਾਲ ਆਮ resolver ਰਾਹੀਂ ਪੁੱਛੋ:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

ਇਨਕ੍ਰਿਪਟ ਕੀਤੇ resolver ਕੁਐਰੀ ਲੁਕਾਉਂਦੇ ਹਨ, ਕਨੈਕਸ਼ਨ ਨਹੀਂ

ਆਪਣਾ DNS-over-HTTPS resolver ਰੱਖਣ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਬਿਲਕੁਲ ਵੱਖਰਾ ਮਾਮਲਾ ਹੈ। ਕੁਐਰੀ TLS ਦੇ ਅੰਦਰੋਂ ਨਿਕਲਦੀ ਹੈ, ਇਸ ਲਈ ਪੈਕੇਟ ਕੈਪਚਰ resolver ਪਤੇ ਨਾਲ ਕਨੈਕਸ਼ਨ ਦਿਖਾਉਂਦਾ ਹੈ ਪਰ ਪੁੱਛਿਆ ਨਾਮ ਨਹੀਂ ਦਿਖਾਉਂਦਾ।

ਪਹਿਲਾਂ ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਪ੍ਰਬੰਧਿਤ ਨੀਤੀ ਪਤਾ ਕਰੋ, ਫਿਰ ਇਸਦੀ ਤੁਲਨਾ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੀ ਖੋਜ ਨਾਲ ਕਰੋ। ਆਪਣਾ resolver ਚੁਣਨ ਦੀ ਇਜਾਜ਼ਤ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ Split-DNS ਨੀਤੀ ਸ਼ਾਇਦ ਹੀ ਕਦੇ ਵੇਖੇ।

ਇਹੀ ਸਾਵਧਾਨੀ ਆਪਣਾ resolver ਲਿਆਉਣ ਵਾਲੇ ਹਰ ਕਲਾਇੰਟ ਉੱਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਦੂਰ ਦੇ ਕਨੈਕਸ਼ਨ ਦੀ ਪਛਾਣ ਕਰਨ ਵਾਲਾ ਕੈਪਚਰ ਕੁਐਰੀ ਦੇ ਨਾਮ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ। ਜੇ ਨਾਮ ਲੋੜੀਂਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ resolver ਦੇ ਆਪਣੇ ਲੌਗ ਜਾਂ ਐਪ ਦੇ ਨਿਦਾਨ ਤੋਂ ਲਓ, ਲਾਗੂ ਹੁੰਦੇ ਗੋਪਨੀਯਤਾ ਨਿਯਮਾਂ ਸਮੇਤ।

ਲੇਬਲ ਕੀਤੀ ਜਾਂਚ ਨਾਲ ਤੁਲਨਾ ਕਰੋ

ਜਾਂਚ ਲਈ ਮਨਜ਼ੂਰ ਅੰਦਰੂਨੀ ਨਾਮ, ਨਾਲ ਹੀ ਸੰਵੇਦਨਸ਼ੀਲ ਅਰਥ ਨਾ ਰੱਖਣ ਵਾਲਾ ਜਨਤਕ ਨਾਮ ਚੁਣੋ। ਹਰੇਕ ਲਈ ਸਮਾਂ, ਰਿਕਾਰਡ ਕਿਸਮ, ਜਵਾਬ ਅਤੇ ਉਮੀਦ ਕੀਤੀ ਨੀਤੀ ਦਰਜ ਕਰੋ।

ਜਿੱਥੇ ਮਨਜ਼ੂਰ ਹੋਵੇ, resolver ਦੀ ਪ੍ਰਾਪਤੀ ਦੀ ਤੁਲਨਾ ਇੱਕ ਸੰਕੀਰਣ ਕਲਾਇੰਟ ਜਾਂ ਗੇਟਵੇ ਨਿਰੀਖਣ ਨਾਲ ਕਰੋ:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

ਸਿਰਫ਼ ਤੁਲਨਾ ਬਣਾਉਣ ਲਈ ਨਿੱਜੀ ਨਾਮ ਅਸੰਬੰਧਿਤ ਜਨਤਕ resolver ਕੋਲ ਕਦੇ ਨਾ ਭੇਜੋ, ਅਤੇ ਤੁਸੀਂ ਸਾਂਝਾ ਕਰਦੇ ਹੋ ਉਹ ਸਭ ਸੰਪਾਦਿਤ ਕਰੋ। ਅੰਤ ਵਿੱਚ, ਸਹੀ DNS ਜਵਾਬ ਨੂੰ ਉਸ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲੇ ਸੇਵਾ-ਕਨੈਕਸ਼ਨ ਤੋਂ ਵੱਖ ਕਰੋ: ਹੱਲ ਕੀਤੇ ਨਿੱਜੀ ਪਤੇ ਨੂੰ ਅਜੇ ਵੀ ਰਾਹ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਮਨਜ਼ੂਰੀ ਦੀ ਲੋੜ ਹੈ।