دو تونل فعال IPsec هنوز به طرح مسیر بازگشت نیاز دارند

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

پیش از رسم مسیر، چهار دروازه بکشید

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

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

مسیر رفت چگونه انتخاب می‌شود

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

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

مسیر بازگشت واقعاً به چه چیزی نیاز دارد

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

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

جایی که ترجمه به‌جای شما تصمیم می‌گیرد

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

اگر الزام تنها این است که هر دو مسیر ترافیک را حمل کنند و هر یک از آن‌ها از دست رفتن یک ارائه‌دهنده جان سالم به در ببرد، چندمسیرهٔ سادهٔ هر جریان با مسیریابی بازگشت منسجم معمولاً طرح کوچک‌تر است.

پذیرش را به ترتیب بگذرانید

به این ترتیب آزمایش کنید و نشانی‌ها را در هر گام ثبت کنید: یک اتصال تازه روی مسیر A و مسیر پاسخش، همان چیز روی مسیر B، سپس از دست رفتن یک ارائه‌دهنده، سپس بازگردانی. برای هر نتیجه بنویسید کدام جریان‌های برقرارشده جابه‌جا شدند، کدام‌ها مجبور به اتصال دوباره شدند و جریان‌های تازه بعداً کجا رفتند. ابتدا مقدار انتظاری را بنویسید، سپس آن را با ضبط مقایسه کنید. دو تونل برقرارشده هیچ‌یک از این‌ها را اثبات نمی‌کند.

طرح زمانی تمام است که جدولی که نوشته‌اید با آنچه ضبط نشان می‌دهد بخواند، نه وقتی هر دو تونل بالا هستند.