ਜਨਤਕ DNS ਦਾ ਕੰਮ ਕਰਨਾ ਇਹ ਨਹੀਂ ਦਿਖਾਉਂਦਾ ਕਿ Active Directory ਲੱਭ ਸਕਦਾ ਹੈ
ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਪੇਜ ਲੋਡ ਹੋਣਾ ਸਿਰਫ਼ ਇੱਕ ਲੁੱਕਅੱਪ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਡੋਮੇਨ ਵਿੱਚ ਸਾਈਨ-ਇਨ ਲਈ SRV ਲੋਕੇਟਰ ਰਿਕਾਰਡ, ਕੰਟਰੋਲਰਾਂ ਦੇ ਪਤੇ ਅਤੇ ਇੱਕ ਰੂਟ ਲੋੜੀਂਦੇ ਹਨ, ਜੋ ਸਭ VPN ਰਾਹੀਂ ਹੱਲ ਹੋ ਸਕਣ।
VPN ਜੁੜਦਾ ਹੈ, ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ ਜਨਤਕ ਸਾਈਟ ਖੋਲ੍ਹਦਾ ਹੈ, ਅਤੇ ਲੈਪਟਾਪ ਫਿਰ ਵੀ ਡੋਮੇਨ ਵਿੱਚ ਸਾਈਨ-ਇਨ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਆਮ ਸਿੱਟਾ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ DNS ਠੀਕ ਹੈ ਕਿਉਂਕਿ ਨਾਮ ਹੱਲ ਹੁੰਦੇ ਹਨ। ਇਹ ਠੀਕ ਨਹੀਂ ਹੈ, ਅਤੇ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਜਾਂਚ ਡੋਮੇਨ ਨਾਲ ਜੁੜੇ ਕਲਾਇੰਟ ਨੂੰ ਲੋੜੀਂਦੀ ਲੜੀ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਲੁੱਕਅੱਪ ਪਰਖਦੀ ਹੈ। ਡੋਮੇਨ ਖੋਜ ਪਹਿਲਾਂ ਸੇਵਾ ਰਿਕਾਰਡ ਮੰਗਦੀ ਹੈ, ਫਿਰ ਉਹਨਾਂ ਰਿਕਾਰਡਾਂ ਵਿੱਚ ਨਾਮਿਤ ਕੰਟਰੋਲਰਾਂ ਦੇ ਪਤੇ, ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਕੰਟਰੋਲਰਾਂ ਵੱਲੋਂ ਸੁਣੇ ਜਾਂਦੇ ਪੋਰਟਾਂ ਤੱਕ ਦਾ ਰੂਟ। ਜਨਤਕ ਜਵਾਬ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਕਦਮ ਪੂਰਾ ਨਹੀਂ ਕਰਦਾ।
ਭਰਮ: ਨਾਮ ਹੱਲ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ DNS ਪੂਰਾ ਹੈ
ਜਨਤਕ ਸਾਈਟ ਦਾ ਹੱਲ ਹੋਣਾ ਸਿਰਫ਼ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਸੇ ਰਿਜ਼ਾਲਵਰ ਨੇ ਜਨਤਕ ਜ਼ੋਨ ਵਿੱਚਲੇ ਨਾਮ ਲਈ ਇੱਕ A ਜਾਂ AAAA ਕਵੈਰੀ ਦਾ ਜਵਾਬ ਦਿੱਤਾ। Active Directory ਉਹੀ ਪ੍ਰੋਟੋਕਾਲ ਦੂਜੇ ਸਵਾਲ ਲਈ ਵਰਤਦਾ ਹੈ: ਡੋਮੇਨ ਦੀਆਂ ਸੇਵਾਵਾਂ ਕਿੱਥੇ ਹਨ, ਅਤੇ ਇਸ ਕਲਾਇੰਟ ਨੂੰ ਕਿਹੜਾ ਕੰਟਰੋਲਰ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਵਾਲ ਡੋਮੇਨ ਦੇ ਨਾਮ ਵਾਲੇ ਜ਼ੋਨ ਹੇਠਾਂ SRV ਰਿਕਾਰਡ ਵਜੋਂ ਪ੍ਰਗਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਦੁਹਰਾਉ ਰਿਜ਼ਾਲਵਰ ਕੋਲ ਉਹਨਾਂ ਨੂੰ ਰੱਖਣ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ।
ਜਦੋਂ ਰਿਕਾਰਡ ਨਹੀਂ ਹੁੰਦਾ, ਰਿਜ਼ਾਲਵਰ ਨਕਾਰਾਤਮਕ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜੋ ਰੁਕਾਵਟ ਨਹੀਂ ਸਗੋਂ ਵੈਧ DNS ਜਵਾਬ ਹੈ। ਫਿਰ ਕਲਾਇੰਟ ਕੈਸ਼ ਵਿੱਚ ਰੱਖੀ ਕੰਟਰੋਲਰ ਜਾਣਕਾਰੀ ਵੱਲ ਮੁੜ ਜਾਂਦਾ ਹੈ, ਜੇ ਉਸ ਕੋਲ ਹੋਵੇ, ਅਤੇ ਇਸੇ ਕਾਰਨ ਡੈਸਕਟਾਪ ਘੰਟਿਆਂ ਤੱਕ ਠੀਕ ਦਿਸ ਸਕਦਾ ਹੈ ਅਤੇ ਰੀਬੂਟ ਜਾਂ ਪਾਸਵਰਡ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ।
ਡੋਮੇਨ ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਕੀ ਮੰਗਦਾ ਹੈ, ਕ੍ਰਮ ਵਿੱਚ
corp.example ਵਰਗੇ ਡੋਮੇਨ ਲਈ ਆਮ ਲੋਕੇਟਰ ਕਵੈਰੀ _ldap._tcp.dc._msdcs.corp.example ਹੈ। SRV ਜਵਾਬ ਸੰਭਾਵੀ ਕੰਟਰੋਲਰਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਪੋਰਟਾਂ ਦੇ ਨਾਮ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਨੂੰ ਉਹਨਾਂ ਹੋਸਟ ਨਾਮਾਂ ਲਈ ਪਤਾ ਰਿਕਾਰਡ ਚਾਹੀਦੇ ਹਨ। ਸਾਈਟ-ਜਾਗਰੂਕ ਖੋਜ ਸਾਈਟ ਸਬਡੋਮੇਨ ਹੇਠਾਂ ਕਵੈਰੀਆਂ ਜੋੜਦੀ ਹੈ, ਅਤੇ ਜਵਾਬ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜੇ ਕੰਟਰੋਲਰ ਤਰਜੀਹੀ ਹਨ, ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਲਾਜ਼ਮੀ ਹੈ।
nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.exampleਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਲੜੀ ਦੀ ਪਾਲਣਾ ਕਰੋ, ਉਸ ਨੈੱਟਵਰਕ ਤੋਂ ਜਿੱਥੇ ਸਮੱਸਿਆ ਆਉਂਦੀ ਹੈ। ਅਪਹੁੰਚ ਪਤੇ 'ਤੇ ਹੱਲ ਹੁੰਦਾ ਹੋਸਟ ਨਾਮ ਰੂਟਿੰਗ ਫੇਲ੍ਹਤਾ ਹੈ, DNS ਫੇਲ੍ਹਤਾ ਨਹੀਂ। ਲੋਕੇਟਰ ਰਿਕਾਰਡਾਂ ਤੋਂ ਬਿਨਾਂ ਪਹੁੰਚਯੋਗ ਕੰਟਰੋਲਰ DNS ਫੇਲ੍ਹਤਾ ਹੈ, ਰੂਟਿੰਗ ਫੇਲ੍ਹਤਾ ਨਹੀਂ। ਦੋਵੇਂ ਸਮਾਨ ਵਰਤੋਂਕਾਰ ਸ਼ਿਕਾਇਤਾਂ ਅਤੇ ਬਿਲਕੁਲ ਵੱਖਰੀਆਂ ਮੁਰੰਮਤਾਂ ਪੈਦਾ ਕਰਦੇ ਹਨ।
ਜਨਤਕ ਰਿਜ਼ਾਲਵਰ ਜਵਾਬ ਕਿਉਂ ਦਿੰਦਾ ਹੈ ਪਰ ਸਾਈਨ-ਇਨ ਫਿਰ ਵੀ ਟੁੱਟਦਾ ਹੈ
ਜੇ ਅਡੈਪਟਰ ਕਲਾਇੰਟ ਨੂੰ ਜਨਤਕ ਰਿਜ਼ਾਲਵਰ ਦਿੰਦਾ ਹੈ, ਜਨਤਕ ਨਾਮ ਚੱਲਦੇ ਹਨ ਅਤੇ ਅੰਦਰੂਨੀ ਨਾਮ ਥਾਂ ਨਹੀਂ ਚੱਲਦੀ। ਦੂਜਾ ਜਨਤਕ ਰਿਜ਼ਾਲਵਰ ਜੋੜਨ ਨਾਲ ਲਾਭ ਨਹੀਂ ਹੁੰਦਾ, ਕਿਉਂਕਿ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਜ਼ੋਨ ਨਹੀਂ ਰੱਖਦਾ। “ਪਹਿਲਾਂ ਅੰਦਰੂਨੀ, ਫਿਰ ਜਨਤਕ” ਵਾਲੀ ਆਮ ਸੂਚੀ ਵੀ ਹਰ ਡੋਮੇਨ ਲਈ ਨਿਯਮ ਵਾਂਗ ਵਿਵਹਾਰ ਨਹੀਂ ਕਰਦੀ: ਪਹਿਲੇ ਸਰਵਰ ਦਾ ਨਕਾਰਾਤਮਕ ਜਵਾਬ ਵੈਧ ਜਵਾਬ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਖਾਲੀ ਹੋਣ ਕਾਰਨ ਹੀ ਕਲਾਇੰਟ ਦੂਜੇ ਸਰਵਰ ਨੂੰ ਦੁਬਾਰਾ ਨਹੀਂ ਪਰਖਦਾ।
ਦੋਵੇਂ ਅੰਦਰੂਨੀ ਰਿਜ਼ਾਲਵਰ, ਜੇ ਤੁਸੀਂ ਦੋ ਚਲਾਉਂਦੇ ਹੋ, AD ਨਾਮ ਥਾਂ ਰੱਖਣ ਅਤੇ ਕਲਾਇੰਟ ਦੇ ਮੌਜੂਦਾ ਨੈੱਟਵਰਕ ਤੋਂ ਪਹੁੰਚਯੋਗ ਹੋਣ। ਸਪਲਿਟ-ਟਨਲ ਡਿਜ਼ਾਈਨ ਇਹੀ ਚੀਜ਼ ਤੋੜਦੇ ਹਨ: VPN ਟਨਲ ਦਾ ਸਬਨੈੱਟ ਲੈ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਅੰਦਰੂਨੀ ਰਿਜ਼ਾਲਵਰ ਅਜਿਹੇ ਪ੍ਰੀਫਿਕਸ 'ਤੇ ਬੈਠਾ ਹੁੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਟਨਲ ਰੂਟ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਕਵੈਰੀ ਉਸ ਰਿਜ਼ਾਲਵਰ ਕੋਲ ਜਾਂਦੀ ਹੈ ਜੋ ਇਸ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ।
Windows ਨਾਮ ਹੱਲ ਦੀ ਨੀਤੀ ਵੀ ਲਾਗੂ ਕਰਦਾ ਹੈ ਜੋ ਖਾਸ ਨਾਮ ਥਾਵਾਂ ਨੂੰ ਖਾਸ ਸਰਵਰਾਂ ਵੱਲ ਭੇਜ ਸਕਦੀ ਹੈ, ਅਤੇ ਅਡੈਪਟਰ ਵੱਲੋਂ ਦਿਖਾਏ DNS ਪਤੇ ਪੂਰੀ ਕਹਾਣੀ ਨਹੀਂ ਹਨ। ਉਹ ਨੀਤੀ ਬਦਲੇ ਬਿਨਾਂ ਅਡੈਪਟਰ ਦੀ ਸੂਚੀ ਬਦਲਣ ਨਾਲ ਪ੍ਰਭਾਵੀ ਸੰਰਚਨਾ ਅਛੂਤੀ ਰਹਿ ਸਕਦੀ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਲਾਗੂ ਹੋਇਆ ਜਾਪਦਾ ਸੁਧਾਰ ਕੋਈ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾਉਂਦਾ।
ਟਨਲ ਦਾ DNS ਅਤੇ ਉਸ ਦੇ ਰੂਟ ਮੇਲ ਰੱਖੋ
ਜੋ VPN ਪ੍ਰੋਫਾਈਲ ਰਿਜ਼ਾਲਵਰ ਭੇਜਦੀ ਹੈ ਪਰ ਉਸ ਨੂੰ ਸਮੇਟਣ ਵਾਲਾ ਪ੍ਰੀਫਿਕਸ ਨਹੀਂ ਭੇਜਦੀ, ਉਹ ਕਲਾਇੰਟ ਲਈ ਅਪਹੁੰਚ ਰਿਜ਼ਾਲਵਰ ਬਣਾਉਂਦੀ ਹੈ; ਜੋ ਪ੍ਰੀਫਿਕਸ ਭੇਜਦੀ ਹੈ ਪਰ ਰਿਜ਼ਾਲਵਰ ਨਹੀਂ, ਉਹ ਕਲਾਇੰਟ ਨੂੰ ਸਥਾਨਕ ਰਿਜ਼ਾਲਵਰ ਪੁੱਛਣ ਲਈ ਛੱਡ ਦਿੰਦੀ ਹੈ। ਇਸ ਜੋੜੀ ਨੂੰ ਇੱਕ ਸੰਰਚਨਾ ਇਕਾਈ ਮੰਨੋ ਅਤੇ ਹਰ ਪ੍ਰੋਫਾਈਲ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਦੋਵੇਂ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਮੁੜ-ਕ੍ਰਮਬੱਧ ਪੁਸ਼ ਜਾਂ ਨਵੀਂ ਸਪਲਿਟ-ਟਨਲ ਨੀਤੀ ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਕਰ ਸਕਦੀ ਹੈ।
ਇਹ ਵੀ ਜਾਂਚੋ ਕਿ ਕਲਾਇੰਟ ਭੇਜੀ ਸੈਟਿੰਗ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ। ਕੁਝ ਕਲਾਇੰਟ DNS ਸਰਵਰ ਸਿਰਫ਼ ਟਨਲ ਇੰਟਰਫੇਸ 'ਤੇ ਲਾਗੂ ਕਰਦੇ ਹਨ ਅਤੇ ਭੌਤਿਕ ਅਡੈਪਟਰ ਦਾ ਰਿਜ਼ਾਲਵਰ ਉਹੀਂ ਰਹਿਣ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਕਿਹੜਾ ਜਿੱਤੇਗਾ ਇਹ ਇੰਟਰਫੇਸ ਮੈਟ੍ਰਿਕ ਅਤੇ ਪੁੱਛੇ ਜਾਂਦੇ ਨਾਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜੇ ਅੰਦਰੂਨੀ ਜਵਾਬ ਸਿਰਫ਼ ਭੌਤਿਕ ਅਡੈਪਟਰ ਬੰਦ ਹੋਣ 'ਤੇ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਸੁਧਾਰਨ ਵਾਲਾ ਤੰਤਰ ਉਹੀ ਹੈ, ਡੋਮੇਨ ਰਿਕਾਰਡ ਨਹੀਂ।
ਖੋਜ ਕਾਲ ਅਤੇ ਇੱਕ ਜੀਵਤ ਕਾਰਵਾਈ ਨਾਲ ਸਵੀਕਾਰ ਕਰੋ
ਲਾਭਕਾਰੀ ਸਵੀਕ੍ਰਿਤੀ ਟੈਸਟ ਲੋਕੇਟਰ ਕਵੈਰੀ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਇੱਕ ਅਸਲ ਪ੍ਰਮਾਣਿਤ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਡਾਇਰੈਕਟਰੀ-ਸਮਰਥਿਤ ਸ਼ੇਅਰ ਖੋਲ੍ਹਣਾ ਜਾਂ ਟਿਕਟ ਮੰਗਣਾ। ਇਹ VPN ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ, ਉਸੇ ਮਸ਼ੀਨ 'ਤੇ, ਵਿਚਕਾਰ ਰੀਬੂਟ ਬਿਨਾਂ ਕਰੋ। ਕੈਸ਼ ਕੀਤੇ ਪ੍ਰਮਾਣ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਖੁੱਲ੍ਹੇ ਸੈਸ਼ਨ ਟੁੱਟੇ ਰਾਹ ਨੂੰ ਖੁਸ਼ੀ ਨਾਲ ਤੰਦਰੁਸਤ ਦਿਖਾ ਦੇਣਗੇ, ਇਸ ਲਈ ਸਫਲ ਡੈਸਕਟਾਪ ਲੌਗਇਨ ਟੈਸਟ ਨਹੀਂ ਹੈ।
Microsoft ਦੀਆਂ DNS ਕਲਾਇੰਟ ਲਈ ਸਿਫ਼ਾਰਸ਼ਾਂ ਅੰਦਰੂਨੀ ਨਾਮ ਥਾਂ ਹੱਲ ਕਰਨ ਅਤੇ ਜਨਤਕ ਕਵੈਰੀਆਂ ਉੱਪਰ ਭੇਜਣ ਵਿਚਕਾਰ ਉਹੀ ਰੇਖਾ ਖਿੱਚਦੀਆਂ ਹਨ, ਅਤੇ VPN ਲਿਆਉਣ ਵੇਲੇ ਇਹੀ ਬੰਦੋਬਸਤ ਬਚਾਉਣੀ ਹੈ।
ਜੇ ਫੇਲ੍ਹਤਾ ਸਿਰਫ਼ ਹੌਲੀ ਹੈ, ਫੇਲ ਨਹੀਂ, ਤਾਂ ਦੇਰੀ ਨੂੰ ਨਿਦਾਨ ਤੋਂ ਵੱਖ ਰੱਖੋ। ਖੋਜ ਵੇਲੇ ਸਮਾਂ ਖਤਮ ਹੋਣਾ ਅਪਹੁੰਚ ਕੰਟਰੋਲਰ, ਰੋਕੇ ਪੋਰਟ ਜਾਂ ਦੇਰ ਨਾਲ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਰਿਜ਼ਾਲਵਰ ਤੋਂ ਆ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਿਰਫ਼ ਉਡੀਕ ਨਾਲ ਸਾਬਤ ਨਹੀਂ ਹੁੰਦਾ। ਰਿਜ਼ਾਲਵਰ ਸੈਟਿੰਗ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਕਵੈਰੀ, ਉਸ ਦਾ ਜਵਾਬ ਅਤੇ ਕਨੈਕਸ਼ਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਦਰਜ ਕਰੋ।