لماذا يكسر مسار VPN واسع بعض المواقع العامة
تفشل بضعة مواقع بينما تُحمَّل البقية لأن بادئة واسعة تلتقط عناوينها. طابِق المسار مع العنوان المُستخرَج، ثم اكتشف مَن يثبّته.
تُحمَّل معظم الصفحات، وتنتهي مهلتَي صفحتين أو ثلاث، ويلقي المتصفح اللوم على الاتصال. أما المواقع التي تفشل فتشترك في شيء لا تشترك فيه المواقع العاملة: عناوينها المُستخرَجة تقع داخل بادئة ثبّتها الـ VPN. والمسار الواسع بما يكفي لتغطية نطاق عام سيلتقط حركة لم يكن النفق مخصصًا لنقلها أصلًا، فتبدو الأعراض مشكلة في الموقع لا قرارًا في التوجيه.
استخرج اسم الموقع الفاشل، ثم انظر في جدول التوجيه لا في المتصفح.
قارِن العنوان لا اسم الموقع
ابحث عن العنوان الذي حاول العميل استخدامه فعلًا، ثم تحقق من المسار الذي يطابقه. الوجهة الواقعة داخل 45.61.20.10 تندرج تحت 45.0.0.0/8 إذا كانت تلك البادئة موجودة، حتى لو لم يكن للموقع نفسه أي علاقة بالنفق. ومقارنة العنوان الفاشل بالبادئات المثبّتة مسألة طرح لا تخمين.
يستطيع Windows الإجابة عن الشقّين مباشرة، ويُظهر البحث الواجهة والخطوة التالية التي فازتا بالاختيار. استخرج الاسم مرتين إذا أعاد الموقع عدة عناوين. سجّل كل عنوان مع المسار الذي طابقه. فالعناوين المختلفة قد تعطي إجابات مختلفة، وربما كان واحد منها فقط هو الحالة الفاشلة.
Resolve-DnsName www.example.org Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric Find-NetRoute -RemoteIPAddress 45.61.20.10 Get-VpnConnection | Format-List Name,SplitTunneling,Routes
اقرأ البادئة الأكثر تحديدًا بين المتطابقات، لا أول سطر يبدو مألوفًا. وجود مسار في الجدول لا يثبت أنه فاز بالبحث؛ فالأطول تطابقًا هو من يفوز. وقد تطابق بادئتان عنوانًا واحدًا، لكن واحدة فقط منهما تستقبل الحزمة. أما الخاسر فيبقى في الجدول ويبدو حقيقيًا تمامًا في القائمة.
دوّن البادئة وواجهتها والعنوان المُستخرَج. هذه القيم الثلاث هي التشخيص كله.
اعرف مَن ثبّت المسار
تأتي المسارات من أربعة مصادر: ملف تعريف الـ VPN المدمج، أو سياسة إدارة، أو سكربت اتصال، أو عميل آخر تمامًا. حذف الإدخال الحيّ قد يؤكد صلته، لكن الاتصال التالي يعيد إنشاءه من الإعدادات المحفوظة، لذا المصدر هو ما يجب تغييره.
افحص قائمة مسارات ملف التعريف أولًا، ثم سياسة الإدارة، ثم أي سكربت يعمل عند الاتصال. هذا الترتيب يوافق تكرار مسؤولية كل منها. وهو أيضًا يبقي التغيير محصورًا في طبقة واحدة بدل ثلاث.
اقرأ سلوك الفئات المدمج بعناية
لملفات تعريف Windows الأصلية إعداد موثّق، NativeProfile/DisableClassBasedDefaultRoute، يتحكم في مسار تلقائي يُستنتج من عنوان الواجهة. وعنوان ملف تعريف يبدأ بـ 45 قد يُنتج إدخال 45.0.0.0/8 في ظل هذا السلوك، وهكذا يلتقط عنوان عام واحد نطاق فئة A بأكمله.
اسم الخاصية يغري بقراءة خاطئة: ضبطها على true يعطّل الاستنتاج، وfalse يفعّله. وهي ليست الكائن نفسه الذي يمثله المسار الافتراضي، ولا تحكم عملاء الطرف الثالث الذين يثبّتون بادئاتهم الخاصة.
إذا ثبت أن الاستنتاج هو السبب، فأصلح ملف التعريف عبر مالك إدارته وقدّم البادئات الخاصة المقصودة صراحة. وإذا أضاف سكربت الإدخال، فأصلح السكربت. واستبدال مسار واسع غير مفسّر بآخر يغيّر العَرَض دون الإجابة عن السؤال.
أصلح المصدر ثم أعد فحص المسارين
بعد التغيير، أعد الاتصال وكرر البحث لموقع عام فاشل وللمورد الذي يجب أن يستخدم النفق. ينبغي أن يُحلّ الأول الآن إلى الواجهة الفعلية، ويظل الثاني يختار الـ VPN. لا تتوقف عند أول نجاح؛ فإصلاح يعطّل الوصول الخاص أيضًا يكون قد بادل عطلًا بعطل.
راجع خطة عناوين الخادم في الوقت نفسه. فمجمّع يتقاطع مع الفضاء العام يسبب هذه الفئة من المشكلات مرارًا. والنطاق الذي اختاره المشغّل عن قصد يستحق نقاشًا مختلفًا، لا إعادة ترقيم تلقائية.
رفع الـ MTU أو تفريغ ذاكرة DNS لن يصحح بادئة ما زالت تدفع ذلك العنوان إلى النفق. اختبر الاختيار أولًا، ثم المسار.