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

از کاری آغاز کنید که پیوند دوم باید انجام دهد

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

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

فرمان نخست نمونه‌های در حال اجرا را فهرست می‌کند، از جمله هر نمونه‌ای که دستی بیرون از مدیر آغاز شده باشد. دومین فرمان ادعای مسیر پیش‌فرض کنونی را چاپ می‌کند، همان وضعیتی که بعداً باید توضیح دهید.

استخرهای هم‌پوشان پیش از مسیریابی می‌شکنند

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

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

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

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

به هر نمایه واحد خودش و به هر پیشوند یک مالک بدهید

هر نمایه نام نمونهٔ خود و پروندهٔ پیکربندی خود را دارد، پس نمونه‌ای به نام office پروندهٔ office.conf را بار می‌کند در حالی که نمونهٔ lab پروندهٔ lab.conf را بار می‌کند. این نگاشت را از طریق مدیر سرویس تأیید کنید نه با اعتماد به فهرست پوشه، چون یک drop-in می‌تواند تغییر دهد کدام پرونده بار می‌شود. اشتباه در نگاشت یعنی نمایه‌ای را تنظیم می‌کنید که اجرا نمی‌شود.

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

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

نشانه‌ها پاسخ‌ها را روی همان واسطی نگه می‌دارند که از آن آمده‌اند

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

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

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

انزوا را با متوقف کردن یک پیوند اثبات کنید

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

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

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

مقالات مرتبط