קישורי SharePoint נשברים דרך VPN בגלל כתובות URL שפורסמו
דף SharePoint שנטען דרך VPN עדיין עשוי להחזיר קישורי מסמכים בשם שהלקוח שלכם אינו יכול לפתור. בדקו 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.