آلة GCP الافتراضية متعددة واجهات NIC: لماذا تغادر الردود الواجهة الخاطئة

إضافة واجهة ثانية إلى آلة Compute Engine تمنحها ارتباط شبكة آخر، لا مسار عودة متماثلًا. لا يزال الضيف يختار الواجهة وعنوان المصدر من مساراته وقواعده الخاصة. ثم يطبّق Google Cloud توجيه VPC وسياسة جدار الحماية حول الواجهة التي غادر منها الحزمة. وعندما يختلف هذان القراران، تصل الطلبات على إحدى واجهتي NIC وتغادر الردود عبر الأخرى، فيرى الفرع محادثة نصف مفتوحة.

تتبَّع المسار في خمس خطوات وستظهر المغايرة قبل أن تكتب قاعدة سياسة.

الخطوة 1: اربط واجهات NIC السحابية بأجهزة الضيف

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

سجّل العناوين وأسماء الأجهزة وVPC التي ينتمي إليها كل منها. تلك الخريطة ثلاثية الأعمدة هي المدخل لكل خطوة لاحقة.

الخطوة 2: سمِّ قرارَي التوجيه

القرار الأول يخص الضيف: أي واجهة وأي عنوان مصدر لهذه الحزمة. والثاني يخص السحابة: ما تسمح به مسارات VPC وسياسة جدار الحماية حول تلك الواجهة.

المسار الظاهر في VPC المواجهة لـ VPN لا يصبح مسار ضيف يختار تلك الواجهة. يصف مسار السحابة ما يمكن للشبكة توصيله، بينما يحدد مسار الضيف ما تفعله الحزمة.

الخطوة 3: اختر سياسة مسار العودة

لمجموعة صغيرة ومستقرة من بادئات الفرع، تكون مسارات الوجهة الصريحة لدى الضيف أبسط تعبير: تغادر الردود على تلك البادئات عبر الواجهة المواجهة لـ VPN. وعندما تستخدم عدة خدمات عناوين مصدر محلية مختلفة عمدًا، تُبقي القواعد المعتمدة على المصدر التي تختار جدولًا لكل واجهة كل رد في السياق الصحيح. تصف وثائق الواجهات المتعددة تسمية NIC وسلوك المسار الافتراضي الذي تعتمد عليه هذه التصاميم.

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

الخطوة 4: افحص مرشحات الضيف نفسه

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

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

الخطوة 5: اختبر تدفقًا واحدًا لكل مسار

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

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

ما لا تمنحك إياه واجهة ثانية

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

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