UDR في Azure إلى بوابة VPN: وجهة واحدة، وليس كل حركة الخروج

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

الخطوة التالية بوابة، وليست عنوان IP لجهاز

يرسل UDR بادئة مطابقة إلى نوع الخطوة التالية، وVirtualNetworkGateway نوع وليس عنوانًا. يلصق الناس عنوان IP الخاص للبوابة في مسار VirtualAppliance ثم يتساءلون لماذا لا يطابق شيء، لأن ذلك النوع يتوقع بطاقة شبكة أو موازن تحميل داخلي بدلًا من ذلك. كما تقصر وثائق التوجيه من Microsoft الخطوة التالية للبوابة على شبكة ظاهرية تكون بوابتها بوابة VPN. ولا يشمل ذلك الخيار ExpressRoute أو Route Server أو محور Virtual WAN.

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

اقرأ المسار الفعلي قبل تعديل أي شيء

يجمع Azure مسارات النظام والبادئات المستفادة عبر BGP ومسارات UDR في جدول مسارات فعلي لكل بطاقة شبكة، وتفوز أطول بادئة مطابقة بغض النظر عن مصدرها. وللبادئة نفسها، يتفوق UDR على مسار BGP. هذا الترتيب هو سبب قدرة UDR قديم من تجربة سابقة على تجاوز البادئة التي تعلمتها للتو عبر النفق بهدوء.

انظر إلى الجدول الفعلي أولًا، ثم قرر إن كنت تضيف مسارًا أم تستبدل واحدًا:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

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

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

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

أنشئ المسار، ثم اربط الجدول بالشبكة الفرعية التي تستضيف الحمل:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

الانتشار مهم أيضًا. مع تمكين انتشار BGP على ذلك الجدول، تظهر البادئات المستفادة إلى جانب التي كتبتها، وقد تفوز بادئة مستفادة أكثر تحديدًا على UDR أوسع. عطّل الانتشار فقط عندما تريد أن تكون مجموعة UDR هي المرجع لتلك الشبكة الفرعية.

أكمل النصف المحلي وإلا مات التدفق هناك

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

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

المحددات وقوائم السماح منفصلة عن كل هذا. اختيار خطوة تالية في Azure لا يوسّع محددات حركة VPN، ولا يغيّر قائمة سماح المصادر لخدمة خارجية.

تحقق من المصدر الذي تراه الوجهة

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

العبور عبر بادئة مختارة تغيير أضيق بكثير من الأنفاق القسرية. أبقِه ضيقًا فيكون التراجع حذف مسار واحد.