Azure P2S: عميل Windows واحد يفقد المسارات بعد تغيير في VNet

يتحقق حاسوبان محمولان عبر بوابة Azure point-to-site نفسها، ولا يستطيع إلا واحد منهما الوصول إلى VNet الموصولة حديثًا. كلاهما يعرض Connected، لذا فالمصادقة ليست الفرق؛ الفرق هو مسارات الوجهة التي يحتفظ بها كل منهما. ابدأ من العميل الذي يفشل، وقارن وجهة واحدة، وبعد ذلك فقط قرّر ما إذا كانت حزمة البوابة أم جدول التوجيه المحلي هو المسؤول عن الفجوة.

ابدأ من العميل الذي يفشل، لا من البوابة

أكّد الطوبولوجيا قبل إلقاء اللوم على الحاسوب. تحقّق من VNets الموصولة بـ VNet الخاصة بالبوابة، وما إذا كانت الشبكة الجديدة مقترنة مباشرة أم يُوصل إليها عبر نفق site-to-site منفصل. إذا لم تكن VNet الجديدة موصولة بـ VNet البوابة على الإطلاق، فلا يمكن لأي حزمة عميل أن توجّه إليها، ويكون الحاسوب العامل هو الشذوذ الذي يجب تفسيره. دوّن الإجابة، لأنها تحدد ما إذا كنت تنقّح عميلًا أم بوابة.

بعد التحقق من الطوبولوجيا، ضع الحاسوبين جنبًا إلى جنب. البوابة نفسها ومجمع العناوين نفسه والبروتوكول نفسه وإصدار العميل نفسه هو ما تريد مقارنته؛ وأي شيء آخر متغيّر ثانٍ سيتعيّن عليك استبعاده لاحقًا.

قارن وجهة واحدة باستخدام route print

اختر عنوان IP مسموحًا لمورد وقارن الحاسوبين مرتين: وهما غير متصلين، ثم وهما متصلان. في Windows، يسرد route print -4 مسارات IPv4 مع بادئة الوجهة والواجهة والخطوة التالية والمقياس. سجّل الصف الذي سيفوز فعليًا لتلك الوجهة بدلًا من عدّ المدخلات التي تحتوي كلمة VPN.

الاختيار يبدأ بأطول بادئة ثم بالمقياس، لذا يمكن لمسار محلي أكثر تحديدًا أن يتغلب على مسار النفق دون أن يبدو خطأً. إذا كانت الوجهة المقصودة داخل 10.24.0.0/16، يُظهر العميل السليم مسارًا مطابقًا على واجهة VPN، بينما يرسل العميل الفاشل العنوان نفسه إلى بوابته الافتراضية.

قد تنتج بادئة محلية متعارضة العَرَض نفسه. قبل إضافة أي شيء، حدّد أي الحالتين لديك: لا مسار نفق على الإطلاق، أم مسار نفق يخسر أمام مسار أكثر تحديدًا.

TTL expired ليس خللًا في توزيع المسارات

رسالة ping التي تعيد TTL expired in transit تقول إن الحزمة استنفدت مخصص القفزات، وهذا يعني عادةً حلقة إعادة توجيه لا برنامج تشغيل VPN معطوبًا. يقبل ping في Windows قيمة TTL حتى 255، ورفع القيمة لا يصلح حلقة؛ بل يؤخر الخطأ نفسه فقط. تعامل مع الرسالة كعَرَض للمسار، لا كدليل على توزيع المسارات.

استخدم tracert -4 10.24.1.10 لمعرفة أين يتكرر المسار. إذا ظهرت القفزتان نفسهما مرارًا، فابحث عن مسار يعيد حركة المرور المتجهة إلى النفق إلى النفق أو إلى موجّه محلي يعيد تمريرها.

أعد إنشاء الحزمة على البوابة التي تملكها

توثّق Microsoft أنه يجب تنزيل حزم عملاء Windows وتثبيتها مرة أخرى بعد التغييرات الطوبولوجية ذات الصلة. احصل على الحزمة الحالية من بوابة Azure التي تخدم هذا الملف التعريفي، ثم طبّقها بالإجراء المدعوم لذلك العميل. استبدال ملف تنفيذي لتطبيق VPN غير ذي صلة ليس العملية نفسها التي تعيد إنشاء إعدادات خاصة بالبوابة. إعادة تنزيل الحزمة رخيصة؛ التخمين في المسارات المحلية ليس كذلك.

أعد الاتصال وأعد قراءة المسار الخاص بالوجهة الأصلية. احتفظ بالصفين قبل وبعد مع سجل التغيير كي تكون النتيجة أدق من عبارة أعدت تثبيت العميل.

تفصل سيناريوهات توجيه Azure P2S بين VNets المقترنة مباشرة والشبكات التي يُوصل إليها عبر أنفاق أخرى، ولا تستطيع حزمة جديدة أن تجعل الاقتران متعديًا. بعض سيناريوهات Windows site-to-site أو BGP تحتاج أيضًا إلى مسارات بعيدة مُهيّأة يدويًا، لذا فتحديث الحزمة ليس آلية عالمية لتوزيع المسارات.

اترك المسار المؤقت مؤقتًا

قد يعزل مسار يدوي مسار عميل مفقودًا، لكن ابنِه من التصميم الفعلي: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42، بدون علم الاستمرارية، كي يختفي عند إعادة التشغيل. اختر فهرس الواجهة والخطوة التالية من محوّل VPN المتصل، لا من تخمين.

لا تترك مسارًا تجريبيًا في مكانه كمالك منافس دائم. قد تضيف تحديثات الملف التعريفي المستقبلية البادئة نفسها بمقياس مختلف، وحينها يقرر المدخل اليدوي بصمت أي مسار يفوز. سجّل خطوة الإزالة في التغيير.

بعد أن يصبح المسار الصحيح نشطًا، اختبر التطبيق المستهدف بدلًا من ping. إذا وصلت الحزم إلى Azure لكن الخدمة ما زالت تفشل، فتحقّق من مجموعة أمان الشبكة ومن مسار العودة، لأن ذلك منفصل عن مسألة تعلّم الحاسوب للبادئة.