سرور و کلاینت OpenVPN روی یک میزبان: چرا کلاینت‌ها قطع می‌شوند

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

یک ماشین، دو نقش، و دو پاسخ ناسازگار دربارهٔ اینکه پاسخ‌ها باید کجا بروند.

همان استخر، دو سرور: کدام برنده می‌شود

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

پیش از ویرایش فهرست کنید چه چیزی فعال است: ip -4 addr show دستگاه‌های تونل را فهرست می‌کند، ss -lunp شنوندگان را فهرست می‌کند، و systemctl list-units واحدها را نام می‌برد. یک نگاه به نشانی‌های تونل روشن می‌کند که آیا استخرها برخورد دارند یا نه.

پروفایل کلاینت چه چیزی به جدول اضافه می‌کند

نیمهٔ کلاینت به‌محض اتصال مسیرها را می‌نویسد. redirect-gateway def1 مسیر پیش‌فرض را به 0.0.0.0/1 به‌علاوهٔ 128.0.0.0/1 تقسیم می‌کند، هر دو از دستگاه جدید مسیریابی می‌شوند، همراه با یک مسیر میزبان به سرور دور که عمداً به رابط فیزیکی سنجاق شده است. این سنجاق برای آن است که تونل مسیری برای ترابری خودش داشته باشد. هر چیز دیگری، از جمله پاسخ‌هایی که سرور محلی به کلاینت‌های خودش بدهکار است، اکنون از پیش‌فرض جدید پیروی می‌کند و از پیوند دور خارج می‌شود.

پس برخورد دوم یک تونل خراب نیست. تونلی کارکن است که در جای اشتباه جدول قرار دارد.

سه راه برای جدا نگه داشتن نقش‌ها

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

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

کدام یک از دو نمونه مقصر است

نمونهٔ کلاینت را متوقف کنید و کلاینت‌های اصلی را دوباره آزمایش کنید. بازیابی فوری یعنی مسیریابی، نه سرور. کلاینت را برگردانید و یک پاسخ را با ip route get که هم نشانی مبدأ و هم مقصد به آن داده شده ردیابی کنید، که مسیری را نشان می‌دهد که هسته انتخاب می‌کرد، سپس با tcpdump -ni any port 1194 رابطی را که بسته‌ها واقعاً استفاده می‌کنند ببینید. پروندهٔ وضعیت سرور که هر چند ثانیه از طریق دستور status نوشته می‌شود، فهرست کلاینت‌های متصل و شمارنده‌های بایت هر دو جهت را دارد.

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