SharePoint ਲਿੰਕ ਪ੍ਰਕਾਸ਼ਿਤ URL ਕਾਰਨ VPN ਉੱਤੇ ਟੁੱਟ ਜਾਂਦੇ ਹਨ
VPN ਰਾਹੀਂ ਲੋਡ ਹੋਣ ਵਾਲਾ SharePoint ਪੰਨਾ ਅਜੇ ਵੀ ਉਸ ਨਾਮ ਉੱਤੇ ਦਸਤਾਵੇਜ਼ ਲਿੰਕ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ। DNS, ਰੂਟ, TLS ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ URL ਦੀ ਜਾਂਚ ਕਰੋ।
VPN ਰਾਹੀਂ SharePoint ਪੰਨਾ ਖੁੱਲ੍ਹਦਾ ਹੈ, ਅਤੇ ਪਹਿਲਾ ਦਸਤਾਵੇਜ਼ ਲਿੰਕ ਅਜਿਹੇ ਨਾਮ ਨਾਲ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਜੋ ਕਦੇ ਪਤਾ ਪੱਟੀ ਵਿੱਚ ਨਹੀਂ ਸੀ। ਇਹ ਖਾਲੀ ਥਾਂ ਹੀ ਪੂਰੀ ਸਮੱਸਿਆ ਹੈ: ਪੰਨਾ ਇੱਕ URL ਤੋਂ ਆਇਆ, ਅਤੇ ਸੇਵਾ ਨੇ ਅਗਲੀ ਬੇਨਤੀ ਦੂਜੇ ਤੋਂ ਬਣਾਈ। ਪ੍ਰਕਾਸ਼ਿਤ URL ਸਰਵਰ ਪਾਸੇ ਦਾ ਫੈਸਲਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਕਲਾਇੰਟ ਉੱਤੇ ਠੀਕ ਕਰਨਾ ਗਲਤ ਸਿਰਾ ਹੈ। DNS ਜਾਂ ਰੂਟ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਸੇਵਾ ਕਿਹੜਾ ਨਾਮ ਵਾਪਸ ਕਰਦੀ ਹੈ।
ਪਹਿਲਾ ਪੰਨਾ ਅਤੇ ਅਗਲੀ ਬੇਨਤੀ ਵੱਖਰੇ ਨਾਮ ਵਰਤਦੇ ਹਨ
ਪਤੇ ਰਾਹੀਂ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲਾ ਉਪਭੋਗਤਾ ਕੰਮ ਕਰਦਾ ਹੋਮਪੇਜ ਦੇਖਦਾ ਹੈ। ਉਸ ਪੰਨੇ ਦੇ ਦਸਤਾਵੇਜ਼ ਲਿੰਕ ਉਸ URL ਤੋਂ ਬਣਦੇ ਹਨ ਜਿਸਨੂੰ ਸੇਵਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਰਹੀ ਹੈ ਐਸਾ ਉਹ ਮੰਨਦੀ ਹੈ, ਨਾ ਕਿ ਉਸ ਤੋਂ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਨੇ ਟਾਈਪ ਕੀਤਾ। ਜੇ ਉਹ ਵੱਖਰੇ ਹਨ, ਤਾਂ ਅਗਲਾ ਕਲਿੱਕ ਉਸ ਨਾਮ ਉੱਤੇ ਜਾਂਦਾ ਹੈ ਜਿਸਨੂੰ ਕਲਾਇੰਟ ਨੇ ਕਦੇ ਹੱਲ ਨਹੀਂ ਕੀਤਾ।
ਪਤਾ ਇੱਕ ਵਾਰ ਦਾਖਲ ਕਰਨ ਨਾਲ ਹਰ ਬਣਿਆ ਲਿੰਕ ਠੀਕ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਪਤੇ ਦਾ ਬੁੱਕਮਾਰਕ ਦਸਤਾਵੇਜ਼ ਖੁੱਲ੍ਹਣ ਤੱਕ ਸਮੱਸਿਆ ਲੁਕਾਉਂਦਾ ਹੈ।
ਇਸ ਅਸਫਲਤਾ ਨੂੰ VPN ਸਮੱਸਿਆ ਸਮਝਣਾ ਸੌਖਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਟਨਲ ਵਰਤਣ ਤੋਂ ਬਾਅਦ ਹੀ ਦਿਸਦੀ ਹੈ। ਅਸਲ ਵਿੱਚ ਟਨਲ ਆਪਣਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ: ਇਹ ਬੇਨਤੀ ਨੂੰ ਅਜਿਹੇ ਨਾਮ ਤੱਕ ਲੈ ਜਾਂਦਾ ਹੈ ਜਿਸਦਾ ਕੰਮ ਕਰਦਾ ਰਾਹ ਜਾਂ ਮੇਲ ਖਾਂਦਾ ਸਰਟੀਫਿਕੇਟ ਨਹੀਂ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਸਵਾਲ ਵੱਖ ਕਰੋ। ਇੱਕ ਹੈ ਪੈਕਟ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ, ਦੂਜਾ ਹੈ ਸੇਵਾ ਨੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਲਈ ਕਿਹੜਾ ਨਾਮ ਚੁਣਿਆ।
ਚਾਰ ਨਿਯੰਤਰਣ, ਇੱਕ ਨਾਮ
ਹਰ ਪ੍ਰਕਾਸ਼ਿਤ ਨਾਮ ਨੂੰ ਚਾਰ ਸੁਤੰਤਰ ਨਿਯੰਤਰਣ ਪਾਰ ਕਰਨੇ ਪੈਂਦੇ ਹਨ। DNS ਨੇ ਇਸਨੂੰ ਅਸਲ ਕਲਾਇੰਟ ਲਈ ਹੱਲ ਕਰਨਾ ਹੈ, ਰਾਊਟਿੰਗ ਅਤੇ ਪਹੁੰਚ ਨੀਤੀ ਨੇ ਰਾਹ ਦੀ ਆਗਿਆ ਦੇਣੀ ਹੈ, TLS ਨੇ ਉਸ ਨਾਮ ਦੀ ਤਸਦੀਕ ਕਰਨੀ ਹੈ, ਅਤੇ ਸੇਵਾ ਇਸਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ ਨਿਯੰਤਰਣ ਵਿੱਚ ਬਦਲਾਅ ਬਾਕੀ ਨਹੀਂ ਕਰਦਾ। ਸਰਟੀਫਿਕੇਟ ਚੇਤਾਵਨੀ ਸਵੀਕਾਰ ਕਰਨਾ ਨਾਮ-ਹੱਲ ਦੀ ਮੁਰੰਮਤ ਨਹੀਂ ਹੈ।
ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਜਾਂਚ ਸੂਚੀ ਦਾ ਕ੍ਰਮ ਹੈ। ਅਸਫਲ ਹੋਣ ਵਾਲੀ ਪਹਿਲੀ ਕਤਾਰ ਉੱਤੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਬਾਅਦ ਦੀ ਮੁਰੰਮਤ ਪਹਿਲਾਂ ਦੀ ਕਮੀ ਦੀ ਭਰਪਾਈ ਨਹੀਂ ਕਰ ਸਕਦੀ।
| Control | Question | Where to look |
|---|---|---|
| DNS | Can the client resolve the published name? | Client resolver and split-DNS policy |
| Route and policy | Does the permitted path exist to the service? | VPN routes and firewall rules |
| TLS identity | Does the certificate match the name in use? | Certificate subject names and trust store |
| Publishing config | Which URL does the service return? | Web application settings and site model |
ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਕਾਸ਼ਨ ਮਾਡਲ ਪੜ੍ਹੋ
SharePoint Server ਤੈਨਾਤੀਆਂ ਵੱਖਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਕਲਾਸਿਕ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿਕਲਪਿਕ ਪਹੁੰਚ ਮੈਪਿੰਗਾਂ ਵਰਤ ਸਕਦੀਆਂ ਹਨ, ਜਿੱਥੇ ਅੰਦਰੂਨੀ URL ਉਹ ਹੈ ਜੋ ਸਰਵਰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਜਨਤਕ URL ਉਹ ਹੈ ਜੋ ਲਿੰਕ ਬਣਾਉਣ ਲਈ ਵਰਤਦਾ ਹੈ। ਹੋਸਟ-ਨਾਮ ਵਾਲੀਆਂ ਸਾਈਟ ਸੰਗ੍ਰਹਿਾਂ ਵੱਖਰੀ ਪਹੁੰਚ ਅਪਣਾਉਂਦੀਆਂ ਹਨ ਅਤੇ Microsoft ਦੀ ਅਗਵਾਈ ਅਨੁਸਾਰ AAM ਨਹੀਂ ਵਰਤ ਸਕਦੀਆਂ।
Microsoft ਦੀ ਯੋਜਨਾ ਅਗਵਾਈ ਵੀ AAM ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਪੁਰਾਣਾ ਦੱਸਦੀ ਹੈ ਅਤੇ ਨਵੀਂ ਯੋਜਨਾ ਲਈ ਹੋਸਟ-ਨਾਮ ਵਾਲੀਆਂ ਸਾਈਟ ਸੰਗ੍ਰਹਿਾਂ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦੀ ਹੈ। ਇਸ ਨਾਲ ਤੈਨਾਤੀ ਮਾਡਲ ਇਸਦੇ ਮਾਲਕ ਦਾ ਸਵਾਲ ਬਣਦਾ ਹੈ, ਤੁਹਾਡੇ ਵੱਲੋਂ ਪੈਚ ਕੀਤਾ ਡਿਫਾਲਟ ਨਹੀਂ।
ਮੈਪਿੰਗ ਬਦਲਾਅ ਦਾ ਸੁਝਾਅ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜਾ ਮਾਡਲ ਵਰਤੋਂ ਵਿੱਚ ਹੈ। ਹੋਸਟ-ਨਾਮ ਵਾਲੀ ਤੈਨਾਤੀ ਵਿੱਚ AAM ਐਂਟਰੀ ਜੋੜਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਕਲਾਸਿਕ ਤੈਨਾਤੀ ਵਿੱਚ ਇੱਕ ਜੋੜਨ ਨਾਲ ਹਰ ਵਾਪਸ ਕੀਤਾ ਲਿੰਕ ਇੱਕੋ ਵਾਰ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਦੋਵੇਂ ਵਿਆਪਕ ਪ੍ਰਭਾਵ ਵਾਲੇ ਸੰਰਚਨਾ ਬਦਲਾਅ ਹਨ, ਇਸ ਲਈ ਇਹਨਾਂ ਨੂੰ ਪੜਾਵਾਂ ਵਿੱਚ ਤਿਆਰ ਕਰੋ ਅਤੇ ਰੋਲਬੈਕ ਰੱਖੋ। ਇਹ ਆਧੁਨਿਕ ਵਾਤਾਵਰਣ ਵਿੱਚ ਪੁਰਾਣੀਆਂ ਮੈਪਿੰਗਾਂ ਲਿਆਉਣ ਦੀ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਹੈ।
ਅਸਫਲ ਕਾਰਵਾਈ ਦਾ ਪਿੱਛਾ ਕਰੋ, ਹੋਮਪੇਜ ਦਾ ਨਹੀਂ
ਅਸਫਲ ਬੇਨਤੀ ਨੇ ਅਸਲ ਵਿੱਚ ਵਰਤਿਆ ਮੰਜ਼ਿਲ, ਕਲਾਇੰਟ ਐਪਲੀਕੇਸ਼ਨ, ਸਮਾਂ ਅਤੇ ਗਲਤੀ ਦਰਜ ਕਰੋ। ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਡੈਸਕਟਾਪ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕੋ ਦਸਤਾਵੇਜ਼ ਤੱਕ ਵੱਖਰੇ ਪ੍ਰਾਕਸੀ, VPN ਜਾਂ ਪ੍ਰਮਾਣੀਕਰਨ ਰਾਹ ਲੈ ਸਕਦੇ ਹਨ।
ਬ੍ਰਾਊਜ਼ਰ ਸਫਲ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ Office ਕਲਾਇੰਟ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਫਰਕ ਇਸ ਗੱਲ ਦਾ ਸੰਕੇਤ ਹੈ ਕਿ ਕਿਹੜਾ ਸੰਦਰਭ ਨਾਮ ਹੱਲ ਕਰਦਾ ਹੈ।
ਜੇ URL ਅਤੇ ਨੈੱਟਵਰਕ ਹੈਂਡਆਫ ਦੋਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਸੇਵਾ ਅਜੇ ਵੀ ਕਾਰਵਾਈ ਨੂੰ ਰੱਦ ਕਰਦੀ ਹੈ, ਤਾਂ ਬਾਕੀ ਸਮੱਸਿਆ ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ ਦੀ ਹੈ। ਦਸਤਾਵੇਜ਼ ਅਨੁਮਤੀਆਂ ਅਤੇ ਚੈੱਕ-ਆਊਟ ਸਥਿਤੀ ਸੇਵਾ ਮਾਲਕ ਦੀ ਹੈ, ਅਤੇ VPN ਰੂਟ ਕਨੈਕਟੀਵਿਟੀ ਦਿੰਦਾ ਹੈ, ਅਨੁਮਤੀ ਨਹੀਂ।
ਹੈਂਡਆਫ ਦੀ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਜਾਂਚ ਕਰੋ
ਅਸਫਲ ਹੋਣ ਵਾਲੇ ਕਲਾਇੰਟ ਉੱਤੇ ਜਾਂਚਾਂ ਕ੍ਰਮ ਨਾਲ ਚਲਾਓ: ਪ੍ਰਕਾਸ਼ਿਤ ਨਾਮ ਹੱਲ ਕਰੋ, ਉਸ ਨਾਮ ਨਾਲ ਪੰਨਾ ਮੰਗੋ, ਫਿਰ ਪੰਨਾ ਸਰੋਤ ਤੋਂ ਦਸਤਾਵੇਜ਼ ਦਾ URL ਮੰਗੋ। ਹਰ ਕਦਮ ਇੱਕ ਨਿਯੰਤਰਣ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ।
ਤਿੰਨ ਕਮਾਂਡਾਂ ਹੱਲ, TLS ਅਤੇ ਦਸਤਾਵੇਜ਼ ਰਾਹ ਨੂੰ ਕਵਰ ਕਰਦੀਆਂ ਹਨ:
nslookup portal.hq.example
curl -sSI https://portal.hq.example/ | head -5
curl -sS -o /dev/null -w "%{http_code}" https://portal.hq.example/sites/team/Doc.aspxਜੇ ਹੱਲ ਸਿਰਫ਼ ਟਨਲ ਰਾਹੀਂ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ split-DNS ਨੀਤੀ ਸ਼ੱਕੀ ਹੈ। ਜੇ TLS ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਚੇਤਾਵਨੀ ਰਾਹੀਂ ਕਲਿੱਕ ਕਰਨ ਦੀ ਬਜਾਏ ਸਰਟੀਫਿਕੇਟ ਦਾ ਨਾਮ ਪ੍ਰਕਾਸ਼ਿਤ ਨਾਮ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਦੋਵੇਂ ਸਫਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਅਜੇ ਵੀ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਗਲਤੀ ਹੁਣ URL ਬਾਰੇ ਨਹੀਂ ਹੈ।