Azure P2S VPN ਪ੍ਰਾਈਵੇਟ ਐਂਡਪੌਇੰਟ ਦਾ ਨਾਂ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ

ਤੁਸੀਂ point-to-site ਟਨਲ ਜੋੜਦੇ ਹੋ, ਪ੍ਰਾਈਵੇਟ ਪਤੇ 'ਤੇ ping ਕਰਦੇ ਹੋ, ਐਪ ਖੋਲ੍ਹਦੇ ਹੋ ਅਤੇ ਇਸ ਦੀ ਥਾਂ 403 ਜਾਂ ਸਰਟੀਫਿਕੇਟ ਗਲਤੀ ਮਿਲਦੀ ਹੈ। ਦੋਵੇਂ ਲੱਛਣ DNS ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਪਰ ਇਹ ਵੱਖਰੀਆਂ ਖਰਾਬੀਆਂ ਹਨ: ਇੱਕ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨੇ ਜਨਤਕ ਪਤਾ ਹੱਲ ਕੀਤਾ, ਦੂਜੇ ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਉਸ ਨੇ ਪ੍ਰਾਈਵੇਟ ਪਤਾ ਹੱਲ ਕੀਤਾ ਅਤੇ ਫਿਰ ਅਜਿਹਾ ਨਾਂ ਦਿੱਤਾ ਜੋ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ ਢਕਦਾ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ ਅਤੇ ਪਹਿਲੀ ਅਸਫਲਤਾ 'ਤੇ ਰੁਕੋ, ਕਿਉਂਕਿ hosts ਐਂਟਰੀ ਜਾਂ ਕੈਸ਼ ਕੀਤਾ ਜਵਾਬ ਹਰ ਅਗਲੀ ਜਾਂਚ ਨੂੰ ਗਲਤ ਕਾਰਨ ਨਾਲ ਪਾਸ ਕਰਾ ਸਕਦਾ ਹੈ। ਮੈਂ ਇਹ ਕ੍ਰਮ ਆਪਣੇ VPN ਪ੍ਰੋਫਾਈਲਾਂ ਦੇ ਕੋਲ ਇੱਕ ਟੈਕਸਟ ਫਾਈਲ ਵਿੱਚ ਰੱਖਦਾ ਹਾਂ, ਕਿਉਂਕਿ ਸੁਧਾਰ ਟਨਲ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ ਅਤੇ ਕਲਾਇੰਟ ਜੋ ਜਾਣਦਾ ਹੈ ਉਸ ਵਿੱਚ ਸਭ ਕੁਝ ਬਦਲਦਾ ਹੈ।

ਕਲਾਇੰਟ ਨੂੰ ਅਸਲ ਵਿੱਚ ਮਿਲਣ ਵਾਲੇ ਪਤੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

ਐਪ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਰਿਜ਼ੌਲਵਰ ਤੋਂ ਸਿੱਧਾ ਪੁੱਛੋ। Windows 'ਤੇ, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨੂੰ ਕਿਹੜਾ ਦ੍ਰਿਸ਼ ਮਿਲਿਆ। ਜਨਤਕ ਜਵਾਬ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅੱਗੇ ਕੁਝ ਵੀ ਐਂਡਪੌਇੰਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੇਗਾ; ਐਂਡਪੌਇੰਟ ਦਾ ਪ੍ਰਾਈਵੇਟ ਪਤਾ ਮਤਲਬ DNS ਮੁੱਕ ਗਿਆ ਅਤੇ ਅਗਲੀ ਜਾਂਚ ਕਨੈਕਸ਼ਨ ਆਪ ਹੈ।

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

ਟਨਲ ਤੋਂ ਪਹਿਲਾਂ ਜ਼ੋਨ, ਉਸ ਦਾ ਲਿੰਕ ਅਤੇ ਰਿਕਾਰਡ ਜਾਂਚੋ

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

ਜ਼ੋਨ ਦੇ ਨਾਂ ਸੇਵਾਵਾਂ ਦੇ ਹੁੰਦੇ ਹਨ, ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਾਈਵੇਟ ਲਿੰਕਾਂ ਦੇ ਨਹੀਂ। App Service ਆਮ ਤੌਰ 'ਤੇ privatelink.azurewebsites.net ਵਰਤਦਾ ਹੈ, ਸਟੋਰੇਜ ਅਤੇ SQL ਦੇ ਆਪਣੇ ਨਾਂ-ਥਾਂ ਹਨ, ਅਤੇ ਦੂਜੀ ਸੇਵਾ ਦਾ ਜ਼ੋਨ ਉਧਾਰ ਲੈਣ ਨਾਲ ਅਜਿਹਾ ਜ਼ੋਨ ਬਣਦਾ ਹੈ ਜੋ ਮੌਜੂਦ ਹੈ ਪਰ ਕੋਈ ਲਾਹੇਵੰਦ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ।

ਕਲਾਇੰਟ ਨੂੰ ਅਜਿਹਾ ਰਿਜ਼ੌਲਵਰ ਦਿਓ ਜਿਸ ਤੱਕ ਉਹ ਅਸਲ ਵਿੱਚ ਪਹੁੰਚ ਸਕੇ

168.63.129.16 Azure ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ point-to-site ਟਨਲ ਦੇ ਪਾਰਲੇ ਪਾਸੇ ਵਾਲੇ ਲੈਪਟਾਪ ਲਈ DNS ਸਰਵਰ ਨਹੀਂ ਹੈ। ਕਲਾਇੰਟ ਨੂੰ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਰਿਜ਼ੌਲਵਰ ਚਾਹੀਦਾ ਹੈ: Azure DNS Private Resolver ਦਾ ਇਨਬਾਊਂਡ ਐਂਡਪੌਇੰਟ, ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਅੰਦਰ ਫਾਰਵਰਡਰ, ਜਾਂ VPN ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਲਿਜਾਈਆਂ DNS ਸਰਵਰ ਐਂਟਰੀਆਂ, ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਨੂੰ ਸਿੱਧਾ ਪੁੱਛੇ।

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

ਜੇ ਤੁਸੀਂ ਸੈਟਿੰਗਾਂ ਧੱਕਣ ਦੀ ਥਾਂ ਫਾਰਵਰਡ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਨਾਂ-ਥਾਂ ਫਾਰਵਰਡ ਕਰੋ ਜੋ ਪ੍ਰਾਈਵੇਟ ਜ਼ੋਨ ਦੀ ਹੈ, ਪੂਰੇ azurewebsites.net ਦੀ ਥਾਂ privatelink.azurewebsites.net। ਜੋ ਸ਼ਰਤੀ ਫਾਰਵਰਡਰ ਪੂਰਾ ਪੇਰੈਂਟ ਸਫਿਕਸ ਨਿਗਲ ਜਾਂਦਾ ਹੈ, ਉਹ ਸੇਵਾ ਦੀ ਹਰ ਖੋਜ Azure ਨੂੰ ਭੇਜਦਾ ਹੈ, ਉਹ ਵੀ ਜੋ ਲੋਕਲ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ।

ਉਹ ਨਾਂ ਵਰਤੋ ਜਿਸ ਲਈ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਹੋਇਆ

ਪਤਾ ਸਹੀ ਹੋਣ 'ਤੇ ਦੂਜੀ ਖਰਾਬੀ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ। ਸਟੋਰੇਜ ਅਤੇ App Service privatelink ਉਪਨਾਮ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਹ ਉਪਨਾਮ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਸਰਟੀਫਿਕੇਟ ਵਿੱਚਲਾ ਨਾਂ ਹੋਵੇ। privatelink.blob.core.windows.net ਵੱਲ ਭੇਜੀ AzCopy ਅੱਪਲੋਡ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿੱਚ ਫੇਲ੍ਹ ਹੋਈ; ਉਹੀ ਅੱਪਲੋਡ <account>.blob.core.windows.net/<container> ਵੱਲ ਪ੍ਰਾਈਵੇਟ ਪਤੇ 'ਤੇ ਹੱਲ ਹੋਇਆ ਅਤੇ ਪਾਸ ਹੋ ਗਿਆ, ਇਸ ਲਈ ਇਹ ਬਿਨਾਂ ਕਿਸੇ ਬਾਈਪਾਸ ਦੇ ਪ੍ਰਾਈਵੇਟ ਰਾਹ 'ਤੇ ਰਿਹਾ।

ਨਿਯਮ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਅਤੇ App Service ਲਈ ਵੀ ਲਾਗੂ ਹੈ: ਸਰਟੀਫਿਕੇਟ ਜਿਸ ਹੋਸਟਨਾਮ ਨੂੰ ਢਕਦਾ ਹੈ ਉਸ ਨਾਲ ਜੁੜੋ ਅਤੇ DNS ਨੂੰ ਪ੍ਰਾਈਵੇਟ ਪਤਾ ਦੇਣ ਦਿਓ। ਪ੍ਰਮਾਣਿਕਤਾ ਟਾਲਣ ਵੱਲ ਨਾ ਵਧੋ, ਕਿਉਂਕਿ ਇਹ ਨਾਂਕਰਨ ਦੀ ਗਲਤੀ ਨੂੰ ਸੁਰੱਖਿਆ ਘਟਾ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਸਫਲ ping ਰਾਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਅਤੇ ਹੱਥ ਮਿਲਾਉਣ ਅੰਦਰਲੇ ਨਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ, ਇਸੇ ਲਈ ਇਹ ਵੱਖਰੀਆਂ ਜਾਂਚਾਂ ਰਹਿੰਦੀਆਂ ਹਨ।

ਹਰ ਤਹਿ ਨੂੰ ਵੱਖ ਕਰਨ ਵਾਲਾ ਚਾਰ ਕਦਮਾਂ ਦਾ ਕ੍ਰਮ

1. ਪੱਕਾ ਕਰੋ ਕਿ VPN ਕਲਾਇੰਟ ਕੋਲ point-to-site ਪੂਲ ਤੋਂ ਪਤਾ ਹੈ ਅਤੇ ਐਂਡਪੌਇੰਟ ਦੇ ਪ੍ਰਾਈਵੇਟ ਪਤੇ ਤੱਕ ਰਾਹ ਹੈ।
2. ਐਪ ਜੋ ਸਹੀ ਨਾਂ ਵਰਤਦਾ ਹੈ ਉਸ ਨੂੰ ਹੱਲ ਕਰੋ ਅਤੇ ਜਵਾਬ ਦੀ ਐਂਡਪੌਇੰਟ ਦੇ ਪਤੇ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
3. ਸੇਵਾ ਪੋਰਟ 'ਤੇ ਐਂਡਪੌਇੰਟ ਨਾਲ TCP ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹੋ, ਫਿਰ ਉਸ ਕਨੈਕਸ਼ਨ 'ਤੇ ਪੇਸ਼ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਦਾ ਨਾਂ ਪੜ੍ਹੋ।
4. ਹੁਣ ਹੀ ਅਧਿਕਾਰ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਕੰਮ ਕਰਦਾ ਰਾਹ ਅਤੇ ਵੈਧ ਸਰਟੀਫਿਕੇਟ ਅਜੇ ਸਰੋਤ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਦਿੰਦੇ।

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

ਕੰਟਰੋਲ ਵਜੋਂ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਅੰਦਰਲਾ VM ਵਰਤੋ। ਜੇ ਨਾਂ ਉੱਥੇ ਪ੍ਰਾਈਵੇਟ ਅਤੇ ਟਨਲ ਤੋਂ ਜਨਤਕ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਜ਼ੋਨ ਅਤੇ ਰਿਕਾਰਡ ਸਹੀ ਹਨ ਅਤੇ ਇੱਕੋ ਫ਼ਰਕ ਕਲਾਇੰਟ ਦੇ ਰਿਜ਼ੌਲਵਰ ਰਾਹ ਦਾ ਹੈ, ਜੋ ਐਂਡਪੌਇੰਟ ਕਨਫਿਗਰੇਸ਼ਨ 'ਤੇ ਇੱਕ ਹੋਰ ਗੇੜ ਲਾਉਣ ਨਾਲੋਂ ਛੇਤੀ ਪੱਕਾ ਹੁੰਦਾ ਹੈ।

ਕਲਾਇੰਟ ਵੀ ਕੈਸ਼ ਕਰਦੇ ਹਨ। ਦਸ ਮਿੰਟ ਪਹਿਲਾਂ ਜਨਤਕ ਤੌਰ 'ਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਰਿਕਾਰਡ ਜ਼ੋਨ ਸੁਧਾਰਨ ਤੋਂ ਬਾਅਦ ਵੀ ਜਵਾਬ ਦਿੰਦਾ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਦੁਬਾਰਾ ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਕੈਸ਼ ਖਾਲੀ ਕਰੋ। Windows 'ਤੇ, ipconfig /flushdns ਕਲਾਇੰਟ ਕੈਸ਼ ਸਾਫ਼ ਕਰਦਾ ਹੈ; ਨਾਂ ਹੱਲ ਨੀਤੀ ਦੇ ਨਿਯਮ ਬਚੇ ਰਹਿੰਦੇ ਹਨ, ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜਾ ਸਫਿਕਸ ਕਿਹੜੇ ਸਰਵਰ 'ਤੇ ਜਾਵੇ, ਅਤੇ ਤੁਹਾਡੇ ਵੱਲੋਂ ਹੁਣੇ ਬਦਲੇ ਰਿਜ਼ੌਲਵਰ 'ਤੇ ਨਾਂ-ਥਾਂ ਭੇਜਦੇ ਰਹਿ ਸਕਦੇ ਹਨ।

hosts ਐਂਟਰੀ ਕਿੱਥੇ ਬਣਦੀ ਹੈ

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

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

ਛੋਟੇ ਨਾਵਾਂ ਨੂੰ ਖੋਜ ਸਫਿਕਸ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਪੂਰੇ ਯੋਗ ਨਾਵਾਂ ਨੂੰ ਨਹੀਂ, ਇਸ ਲਈ ਪਹਿਲਾਂ ਪੂਰਾ ਯੋਗ ਨਾਂ ਪਰਖੋ, ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਵਰਕਫਲੋ ਨੂੰ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਰਾਹੀਂ ਧੱਕਿਆ ਸਫਿਕਸ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। Microsoft ਆਪਣੇ ਪ੍ਰਾਈਵੇਟ ਐਂਡਪੌਇੰਟ DNS ਮਾਰਗਦਰਸ਼ਨ ਵਿੱਚ ਹਰ ਸੇਵਾ ਲਈ ਜ਼ੋਨ ਨਾਂ ਅਤੇ ਰਿਕਾਰਡ ਦੇ ਰੂਪ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ; ਦੂਜੀ ਸੇਵਾ ਤੋਂ ਜ਼ੋਨ ਕਾਪੀ ਕਰਨ ਦੀ ਥਾਂ ਆਪਣੀ ਸੇਵਾ ਦੀ ਐਂਟਰੀ ਪੜ੍ਹੋ।