لماذا تُسقط آلة VPN ظاهرية في Azure مسار الإرجاع
يحتاج جهاز VPN داخل آلة ظاهرية في Azure إلى توافق UDR وعلَم إعادة التوجيه في بطاقة الشبكة وسياسة الضيف. تتبّع طلب فرع واحد عبر الثلاثة.
تقع آلة Azure الظاهرية التي تشغّل جهاز VPN داخل نظامَي قرار مستقلين. يقرّر Azure من أين تغادر الرزمة الشبكة الفرعية، باستخدام جداول التوجيه وإعداد إعادة التوجيه في بطاقة الشبكة. ويقرّر نظام التشغيل الخاص بالجهاز بدوره ما إذا كان سيمرّر الرزمة مفكوكة التشفير إلى الأمام. النفق الذي يعمل بشكل مثالي قد يفشل مع ذلك في النظام الثاني، وهنا تتوقّف معظم عمليات النشر هذه.
ثلاثة مالكين لمسار واحد
خذ شبكة فرع من 192.168.50.0/24 وشبكة فرعية لأحمال العمل من 10.0.10.0/24، مع وجود الجهاز في 10.0.0.4 داخل شبكته الفرعية. يلمس طلب واحد ثلاثة إعدادات منفصلة.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
كل صف يملكه فريق مختلف في معظم المؤسسات، ولهذا تصل هذه المشكلة عادةً في ثلاث تذاكر بدلًا من تذكرة واحدة.
المسار الذي يشير إلى الجهاز
اربط جدول توجيه بالشبكة الفرعية لأحمال العمل وأعطِ بادئة الفرع خطوة تالية من النوع Virtual appliance مع 10.0.0.4 كعنوان. استخدم العنوان الخاص القابل للوصول للجهاز، ولا تستخدم أبدًا نقطة دخوله العامة إلى VPN. يجب أن تكون الخطوة التالية عنوانًا يمكن للشبكة الفرعية لأحمال العمل الوصول إليه أصلًا. اترك بقية توجيه أحمال العمل كما هو ما لم تكن قد قرّرت عن قصد استبدال المسار الافتراضي.
أبقِ الجهاز في شبكته الفرعية الخاصة، وتأكّد من أن المسار الذي يرسل حركة الفرع إلى الجهاز لا يلتقط أيضًا مسار الخروج الخاص بالجهاز. تبدو تلك الحلقة كنفق سليم بلا أي ردود، وهذا شيء بائس لتصحيح أخطائه في الساعة 2 صباحًا.
علَم بطاقة الشبكة الذي ينساه الجميع
يمتلك Azure إعداد إعادة توجيه IP لكل بطاقة شبكة، وهو معطّل افتراضيًا. وهو موجود لأن بطاقة الشبكة التي تمرّر الحركة تستقبل رزمًا موجّهة إلى شيء غيرها، وإسقاطها بصمت هو الافتراضي الآمن للجميع.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true يشغّله لواجهة واحدة. تفرض إرشادات إعادة التوجيه في بطاقة الشبكة من Microsoft هذا الإعداد على كل بطاقة شبكة متصلة تمرّر الحركة، لذا يحتاج الجهاز ذو البطاقة الواحدة إلى ضبطه على تلك البطاقة.
العلَم ليس مسارًا وليس قاعدة جدار حماية. تشغيله يمنح الإذن ولا شيء غير ذلك.
ما يفعله الضيف بالرزمة مفكوكة التشفير
بمجرد انتهاء النفق، تتخذ حزمة الجهاز الخاصة القرار التالي. على ضيف Linux، إعادة توجيه IPv4 إعداد وقت تشغيل، و sysctl -w net.ipv4.ip_forward=1 يبقى حتى الإقلاع التالي. اجعله دائمًا في ملف تحت /etc/sysctl.d/ بدلًا من ذلك. لجهاز المورّد مكافئه الخاص، وتعليمات Linux التي تُلصق في منصة مورّد لا تفعل عادةً شيئًا على الإطلاق.
سياسة جدار حماية الضيف منفصلة مرة أخرى، وكذلك مجموعة أمان الشبكة لأحمال العمل. السماح بمنفذي UDP 500 و4500 إلى العنوان العام للآلة الظاهرية يحمي النفق؛ لكنه لا يقول شيئًا عن إمكانية وصول طلب فرع مفكوك التشفير إلى منفذ حمل عمل.
تتبّع طلبًا واحدًا وردّه
اختر تدفقًا مسموحًا واحدًا وتتبّعه من أوله إلى آخره. يحتاج الفرع إلى مسار نحو 10.0.10.0/24 عبر اتصال الموقع، ويحتاج الجهاز إلى مسار تسليم إلى الشبكة الفرعية لأحمال العمل، وتحتاج تلك الشبكة الفرعية إلى مسار إرجاع نحو الفرع.
قرّر مبكرًا ما إذا كان التصميم يحافظ على عنوان مصدر الفرع أم يترجمه. يغيّر NAT ما تراه أحمال العمل، لذا يجب أن تصف قواعد الوصول النموذج الذي اخترته فعلًا لا عنوان بوابة مخمّنًا.
المصافحة الناجحة تثبت حلقة واحدة من تلك السلسلة. يكتمل المسار عندما يعود الرد عبر الجهاز نفسه وتسمح به سياسة أحمال العمل نفسها.