دو کلاینت OpenVPN روی یک دروازه لینوکس: سیاست را تقسیم کنید

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

هسته تصمیم می‌گیرد، نه دیمن

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

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

به هر نمونه مجموعه منابع خودش را بدهید

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull مسیرهایی را که سرور هل می‌دهد از جدول محلی بیرون نگه می‌دارد، و این دقیقاً همان چیزی است که وقتی جدول‌های سیاست باید صریح باشند می‌خواهید. اینکه سرور مشخصی گزینهٔ redirect-gateway را هم هل می‌دهد یا نه، و اینکه نسخهٔ کلاینت شما شکل فیلتر را پشتیبانی می‌کند یا نه، ارزش دارد در راهنما بررسی شود نه اینکه فرض شود.

ماتریس را بنویسید: مبدأ، جدول، دستگاه

برای هر گروه کلاینت، قاعده‌ای بیفزایید که جدولی را بر پایهٔ نشانی مبدأ برمی‌گزیند، سپس مسیر مورد نظر را در آن جدول بگذارید:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

ترابری خود تونل در گروه کلاینت نیست

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

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

برگزیدن یک مسیر آن را مجاز نمی‌کند

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

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

وقتی یک تونل می‌افتد چه می‌شود

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

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