فحص NVA في Azure: لماذا يمر الرد عبر جدار حماية آخر
يوزّع Route Server مسارين متساويين ولا شيء غير ذلك. وعندما يختار الرد جهازًا مختلفًا، لا توجد حالة لتلك الجلسة هناك، فيموت التدفق.
قد يُوجَّه تدفق من الفرع إلى Azure بشكل صحيح في الاتجاهين ومع ذلك يفشل، لأن الاتجاهين يسلكان جهازين مختلفين. يغادر الطلب الفرع عبر VPN، ويهبط على NVA A، ويصل إلى حمل العمل. ويغادر الرد حمل العمل، ويطابق مسارًا يشير إلى NVA B، ويموت هناك. كل مسار في تلك الصورة صالح، ومع ذلك تظل جلسة TCP مكسورة.
Request: branch -> VPN gateway -> NVA A -> workload
Reply: workload -> NVA B -> VPN gateway -> branch
هذه الفجوة هي موضوعنا كله هنا: تقارب التوجيه وملكية حالة الجلسة مشكلتان مختلفتان تبدوان متطابقتين في الرسم التخطيطي.
ما الذي يبرمجه Route Server فعليًا
يتصل Azure Route Server بمتحدثي BGP المدعومين، ويتعلّم مساراتهم، ويبرمجها في المسارات الفعّالة للشبكة الظاهرية. هذه مهمة مستوى التحكم. وهو لا يقرأ جدول جلسات جدار حماية من بائع، ولا يعرف أي جهاز سمح باتصال معين. القفزتان المتساويتان في التكلفة هما، بالنسبة للنسيج، مجرد طريقتين للوصول إلى البادئة نفسها، وسيستخدم أيًّا منهما.
تعلّم مسار ما يثبت بالتالي إمكانية الوصول. ولا يثبت شيئًا عمّا إذا كان الجهاز في الطرف الآخر قد رأى هذا التدفق من قبل.
اقرأ الاتجاهين قبل أن تصمم
ابدأ بتدوين التوجيه الذي لديك فعليًا في كل اتجاه، لا الذي كنت تنوي. مسارات BGP الأكثر تحديدًا ومسارات المستخدم المحددة وسلوك البوابة تتنافس كلها، ويُحسم الفائز لكل وجهة، لا لكل جلسة. ومسار افتراضي على NVA لا يعني أن كل بادئة خاصة تعبره.
من الفحوص المفيدة أن تسأل، لعنوان IP محدد لحمل العمل، عن القفزة التالية التي يحلّها كل اتجاه. إذا كانت الإجابة جهازين مختلفين، فلديك مشكلة عدم تناظر سواء ظهرت أم لا.
أين تعيش الحالة
جدار حماية ذو حالة يقبل الاتصال ويحتفظ بمدخل جدول مفتاحه الخماسي. يجب أن يصل الرد إلى الجهاز الذي يحتفظ بذلك المدخل، أو أن يحصل ذلك الجهاز على الحالة بطريقة أخرى. لا شيء في مستوى بيانات Azure يمرر المدخل بين الأجهزة. إما أن يُوجّه المرور عائدًا إلى المالك، أو تتشارك الأجهزة الحالة عبر آلية من البائع، أو لا يعمل التصميم.
لهذا فإن وجود اثنين من NVAs سليمين ليس فحصًا صحيًا للفحص. الصحة تتعلق بإمكانية الوصول؛ والفحص يتعلق بأي نسخة تحتفظ بالجلسة.
نماذج HA المدعومة وما يعد به كل منها
Microsoft's guidance on نية توجيه Virtual WAN سلوكًا محدود النطاق للاتصال ثنائي الدور وNVAs جدران الحماية، حيث يمكن للتوجيه المباشر أن يتجاوز الإنفاذ المتماثل الطبيعي للمحور. اقرأ تلك الملاحظات كقيود على الطوبولوجيا التي اخترتها، لا كحظر على تصاميم نشط-نشط. يمكن دعم زوج من البائع يزامن الحالة، أو يوجّه لكل تدفق. الزوج المتساوي التكلفة الذي لا يفعل أيًّا من الاثنين ليس كذلك.
ثم حدد ما يحدث للجلسات القائمة عند فشل عقدة. تقارب التوجيه يعيد إمكانية الوصول للتدفقات الجديدة خلال ثوانٍ، بينما حالة جدار الحماية القديمة تكون قد ذهبت ببساطة. قد تكون إعادة اتصال العميل هي النتيجة الموثقة، وذلك قرار يُتخذ قبل الحادثة لا أثناءها.
ما يجب اختباره قبل أن تثق به
Test with inspection enabled and سياسة وصول حمل العمل في مكانها، لأن أيًّا منهما يمكن أن يخفي عدم التناظر. أرسل تدفقًا مصرحًا جديدًا في الاتجاهين وتأكد من أن الجهاز نفسه رأى النصفين. ثم شغّل مرورًا مستمرًا وأطلق تجاوز الفشل المعتمد، وراقب ما إذا كانت الجلسات القائمة تصمد أو تعيد الاتصال.
اربط كل تدفق بالجهاز الذي عالجه. التقاط الحزم على NVA واحد لا يخبرك تقريبًا بشيء إذا لم يعد الرد إليه أبدًا.
أخيرًا، اكتب الخطة في ثلاثة أسطر منفصلة: ملكية المسارات، وتوجيه المرور، وملكية حالة الجلسة. تتعطل التصاميم عندما يُحلّ الأولان ويُفترض الثالث.