SharePoint ಲಿಂಕ್‌ಗಳು ಪ್ರಕಟಿತ URLಗಳಿಂದಾಗಿ VPN ಮೇಲೆ ಮುರಿಯುತ್ತವೆ
VPN ಮೂಲಕ ಲೋಡ್ ಆಗುವ SharePoint ಪುಟವು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಪರಿಹರಿಸಲಾಗದ ಹೆಸರಿನಲ್ಲಿ ದಾಖಲೆ ಲಿಂಕ್‌ಗಳನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು. DNS, ಮಾರ್ಗ, TLS ಮತ್ತು ಪ್ರಕಟಿತ URL ಪರಿಶೀಲಿಸಿ.
SharePoint ಪುಟವು VPN ಮೂಲಕ ತೆರೆಯುತ್ತದೆ, ಮತ್ತು ಮೊದಲ ದಾಖಲೆ ಲಿಂಕ್ ಎಂದೂ ವಿಳಾಸ ಪಟ್ಟಿಯಲ್ಲಿರದ ಹೆಸರಿನೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ಆ ಅಂತರವೇ ಸಂಪೂರ್ಣ ಸಮಸ್ಯೆ: ಪುಟವು ಒಂದು 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 ಬಗ್ಗೆ ಅಲ್ಲ.