روابط 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.