بازرسی NVA در Azure: چرا پاسخ از یک فایروال دیگر عبور می‌کند

یک جریان از شعبه به 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 ورودی را بین دستگاه‌ها ارسال نمی‌کند. یا ترافیک به سمت مالک هدایت می‌شود، یا دستگاه‌ها وضعیت را از طریق سازوکار فروشنده به اشتراک می‌گذارند، یا طراحی کار نمی‌کند.

به همین دلیل دو NVA سالم یک بررسی سلامت برای بازرسی نیست. سلامت درباره دسترس‌پذیری است؛ بازرسی درباره این است که کدام نمونه نشست را نگه می‌دارد.

مدل‌های HA پشتیبانی‌شده و آنچه هر کدام وعده می‌دهد

Microsoft's guidance on قصد مسیریابی Virtual WAN رفتار محدودی را برای اتصال دو‌نقشی و NVAهای فایروال توصیف می‌کند، جایی که مسیریابی مستقیم می‌تواند اجرای متقارن عادی هاب را دور بزند. آن یادداشت‌ها را به‌عنوان محدودیت‌هایی بر توپولوژی انتخابی خود بخوانید، نه به‌عنوان ممنوعیتی برای طراحی‌های فعال-فعال. یک جفت فروشنده که وضعیت را همگام می‌کند یا به‌ازای هر جریان هدایت می‌کند می‌تواند پشتیبانی شود. جفت با هزینه برابر که هیچ‌کدام را انجام نمی‌دهد، نه.

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

پیش از اعتماد چه چیزی را آزمایش کنید

Test with inspection enabled and سیاست دسترسی بار کاری در جای خود آزمایش کنید، چون هر کدام می‌تواند عدم تقارن را پنهان کند. یک جریان مجاز جدید در هر دو جهت بفرستید و تأیید کنید که همان دستگاه هر دو نیمه را دیده است. سپس ترافیک پایدار اجرا کنید و انتقال شکست تأییدشده را فعال کنید و ببینید نشست‌های برقرارشده زنده می‌مانند یا دوباره متصل می‌شوند.

هر جریان را با دستگاهی که آن را پردازش کرده مرتبط کنید. ضبط بسته روی یک NVA تقریباً هیچ چیزی به شما نمی‌گوید اگر پاسخ هرگز به آن بازنگشته باشد.

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