ماشین مجازی GCP با چند NIC: چرا پاسخ‌ها از رابط اشتباه خارج می‌شوند

افزودن رابط دوم به ماشین مجازی Compute Engine به آن یک اتصال شبکه دیگر می‌دهد، نه مسیر بازگشت متقارن. مهمان همچنان رابط و آدرس مبدأ را از مسیرها و قواعد خودش انتخاب می‌کند. سپس Google Cloud مسیریابی VPC و سیاست دیوار آتش را حول همان رابطی اعمال می‌کند که بسته از آن خارج شده است. وقتی این دو تصمیم با هم نمی‌خوانند، درخواست‌ها از یک NIC می‌رسند و پاسخ‌ها از دیگری خارج می‌شوند، و شعبه یک گفت‌وگوی نیمه‌باز می‌بیند.

مسیر را در پنج گام طی کنید و ناسازگاری پیش از نوشتن یک قاعده سیاست آشکار می‌شود.

مرحله 1: NICهای ابر را به دستگاه‌های مهمان نگاشت کنید

ابر رابط‌ها را nic0، nic1 و غیره می‌نامد، در حالی که مهمان نام دستگاه‌هایی را می‌بیند که لازم نیست مطابقت داشته باشند. نگاشت را پیش از هر چیز از فراداده نمونه یا از آدرس خود رابط روشن کنید. مسیر پیش‌فرض معمول که DHCP ارائه می‌دهد به nic0 مرتبط است، و به همین دلیل مسیر رو به اینترنت این‌قدر اغلب به‌طور تصادفی برنده می‌شود. نوشتن سیاست بر اساس یک نام دستگاه حدسی همان راهی است که یک قاعده درست روی رابط اشتباه می‌نشیند.

آدرس‌ها، نام دستگاه‌ها و VPCای که هر کدام به آن تعلق دارد را ثبت کنید. آن نقشه سه‌ستونی ورودی هر گام بعدی است.

مرحله 2: دو تصمیم مسیریابی را نام‌گذاری کنید

تصمیم اول متعلق به مهمان است: کدام رابط و کدام آدرس مبدأ برای این بسته. تصمیم دوم متعلق به ابر است: مسیرهای VPC و سیاست دیوار آتش حول آن رابط چه چیزی را مجاز می‌کنند.

مسیری که در VPC رو به VPN دیده می‌شود به مسیر مهمانی که آن NIC را انتخاب کند تبدیل نمی‌شود. مسیر ابر توصیف می‌کند که شبکه چه چیزی می‌تواند تحویل دهد، در حالی که مسیر مهمان تعیین می‌کند بسته چه می‌کند.

مرحله 3: یک سیاست مسیر بازگشت انتخاب کنید

برای مجموعه‌ای کوچک و پایدار از پیشوندهای شعبه، مسیرهای مقصد صریح در مهمان ساده‌ترین بیان‌اند: پاسخ‌ها به آن پیشوندها از رابط رو به VPN خارج می‌شوند. وقتی چند سرویس به‌طور عمدی از آدرس‌های مبدأ محلی متفاوت استفاده می‌کنند، قواعد مبتنی بر مبدأ که برای هر رابط یک جدول انتخاب می‌کنند هر پاسخ را در بافت درست نگه می‌دارند. مستندات چند رابط نام‌گذاری NIC و رفتار مسیر پیش‌فرضی را که این طرح‌ها بر آن تکیه دارند توصیف می‌کند.

هر جدول به مسیرهای متصل معتبر و گام‌های بعدی نیاز دارد، به‌علاوه مقصدهایی که از آن پرسیده می‌شود. قاعده‌ای که به جدولی ناقص اشاره می‌کند طرح مسیر بازگشت نیست. از دروازه مستندشده برای آن NIC استفاده کنید، نه اینکه از ظاهر زیرشبکه یک دروازه اترنت بسازید.

مرحله 4: فیلترهای خود مهمان را بررسی کنید

بررسی کنید سرور کجا گوش می‌دهد و پاسخ کدام مبدأ محلی را حمل می‌کند. شنونده‌ای که همه آدرس‌ها را می‌پذیرد سیاست مسیریابی را باطل نمی‌کند، بنابراین اتصال به همه آدرس‌ها چیزی را درباره رابطی که پاسخ از آن خارج می‌شود تغییر نمی‌دهد.

در Linux اعتبارسنجی مسیر معکوس را در برابر طرح موردنظر بازبینی کنید. غیرفعال کردن سراسری آن به‌عنوان نخستین اقدام، یک باگ مسیریابی را با در معرض جعل قرار گرفتن عوض می‌کند و عدم تقارنی را که در جست‌وجویش بودید پنهان می‌کند.

مرحله 5: برای هر مسیر یک جریان را آزمایش کنید

یک درخواست مجاز شعبه و یک درخواست اینترنت نامرتبط را جداگانه بررسی کنید، هر کدام با مبدأ و مقصد واقعی خودش. وقتی می‌توانید روی هر دو رابط ضبط کنید، زیرا شاهد مفید این است که کدام رابط پاسخ را حمل کرده است. سپس تأیید کنید که سیاست سمت ابر مسیری را که طراحی کردید محترم شمرده است. یک درخواست موفق یک جریان را اثبات می‌کند، نه یک طرح متقارن.

دو آزمون را در یادداشت‌هایتان جدا نگه دارید، چون مسیرهای متفاوت و قواعد دیوار آتش متفاوتی را به کار می‌گیرند.

آنچه یک NIC دوم به شما نمی‌دهد

رابط دوم یک اتصال شبکه و یک آدرس دیگر اضافه می‌کند. مسیریابی متقارن خودکار اضافه نمی‌کند و از سیاست دیوار آتش عبور نمی‌کند. برخورد با آن به‌عنوان یک اصلاح مسیریابی دلیل آن است که طرح‌های چند NIC قواعدی را انباشته می‌کنند که بعداً هیچ‌کس نمی‌تواند توضیح دهد.

اگر ماشین مجازی باید ترافیک ماشین‌های دیگر را هدایت کند، آن نقش مسیریاب را صریحاً برنامه‌ریزی کنید، از جمله تنظیم ابر که هدایت را مجاز می‌کند و فیلترهای مهمان که همراه آن می‌آیند.