VPN من موقع إلى موقع في Azure متصل بلا حركة: اقرأ سجل IKE

تقول البوابة Connected، وللنفق عدّاد وقت تشغيل، بينما يفشل تتبّع من جهازك الافتراضي عند القفزة الثانية. حالة الاتصال تصف تفاوض IKE وIPsec، لا ما إذا كانت حزمة واحدة تنجو من طبقة السياسات على أي من الجانبين. عطلان يفسّران معظم هذه التذاكر، ولا يُصلَح أي منهما بتغيير مسار في Azure. كلاهما مكتوب أصلاً في السجل الذي أنتجته البوابة، ولهذا أبدأ من هناك لا من جدول المسارات.

ما الذي يشهد عليه Connected فعلاً

الاتصال المتصل من موقع إلى موقع يعني اكتمال المرحلتين 1 و2 وأن ارتباطات الأمان قائمة. هذا تصريح عن التفاوض: اتفق الطرفان على اقتراح، وتبادلا المفاتيح، وثبّتا زوج SA. ولا يقول شيئاً عن مطابقة محدّدات الحركة للشبكات الفرعية التي تظن أنها محمية، ولا عن إمكانية توجيه الطرف البعيد للحزمة بعد فك التشفير. قد يبقى النفق قائماً أسابيع وهو يُسقط كل تدفّق مهم، وهذا بالضبط النمط الذي يدفع الناس إلى إعادة بناء بوابة سليمة.

العطلان الجديران بالفحص أولاً هما طرف يعرض AH بدلاً من ESP، وشبكة افتراضية مرقّمة في نطاق لا تعتبره البوابة داخلياً.

افتح السجل المُصدَّر قبل لمس المسارات

في البوابة، افتح بوابة الشبكة الافتراضية ونفّذ عملية استكشاف أخطاء VPN على الاتصال، ثم نزّل الحزمة التي تنتجها وفكّ ضغطها. بداخلها سجل IKE يتضمّن تبادلات المرحلتين 1 و2، مختوم بالوقت وقابل للقراءة كنص عادي. ابحث فيه عن سطر التحويل بدلاً من القراءة من الأعلى إلى الأسفل، لأن المدخل المهم عادةً يقع بعد بضع مئات من الأسطر. إن لم تكن لديك صلاحية الوصول إلى البوابة، تظهر التشخيصات نفسها في وجهة سجل البوابة عند تفعيل إعدادات التشخيص.

مدخلان يحملان معظم القيمة. الأول يقول في معناه expected ESP with combined authentication and cipher, received AH. والثاني خطأ حمولة غير صالحة أثناء تبادل IKE، ويعني عادةً حقل اقتراح مشوّهاً أو غير مدعوم.

كلاهما يصف ما عرضه جهاز المقر، لذا كلاهما إعدادات على جانب الطرف الآخر. إعادة توليد جانب Azure من الاتصال لا تغيّر الاقتراح الذي يرسله جدار الحماية، وفعل ذلك مع ذلك هو أكثر ساعة مهدورة شيوعاً في هذا المسار. على الطرف الآخر، اضبط المرحلة 2 على ESP مع التوثيق والتشفير المدمجين ودعه يتفاوض على الخوارزمية، ثم تحقّق مما إذا كان مربع اختيار لدى المورّد باسم مثل combined mode يختار بصمت اقتراح AH تحته.

تأكيد مساحة عنوان الشبكة الافتراضية

تتوقع البوابة أن تقع الشبكة الافتراضية في نطاقات خاصة. شبكة مرقّمة في كتلة عامة، مثل التي تبدأ بـ 111.x، قد ترفع النفق بينما يرفض Azure اعتبار تلك المساحة داخلية، فيبدو الاتصال سليماً ولا يُقبل أي تدفّق. أكّد مساحة العنوان قبل أن تصرف عصراً كاملاً على المحدّدات. وإن كان الترقيم مطلباً صارماً من تخصيص قديم، فالعلاج تغيير خطة العناوين لا استبدال البوابة.

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

تحقّق من البادئات في الاتجاهين

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

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

اختبر مساراً لا ping

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

اكتب اقتراح الطرف الآخر ومساحتي العنوانين ووقت إنشاء الاتصال في التذكرة، ليعرف المهندس التالي أي القيم أُعيد بناؤها وأيها لم يُلمس أبداً.

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