دو کلاینت VPN، یک جدول مسیریابی: مسیر پیش‌فرض به چه کسی می‌رسد

به نظر می‌رسد دو کلاینت VPN بر سر یک سوکت می‌جنگند و راه‌حل آشکار باید حذف یکی باشد. در عمل به‌ندرت همان سوکت را لمس می‌کنند. هر اتصال جدول مسیریابی سیستم‌عامل را بازنویسی می‌کند و نمایه تونل کامل مسیر پیش‌فرض را تصاحب می‌کند. معمولاً کسی که آخر وصل شده برنده می‌شود و به همین دلیل به نظر می‌رسد نشانه بین کلاینت‌ها جابه‌جا می‌شود.

تضاد در جدول مسیریابی زندگی می‌کند

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

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

بخوانید کدام تونل صاحب مسیر کنونی است

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

ip route get 10.20.0.5
route print -4

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

جلوی تصاحب همه‌چیز توسط کلاینت دوم را بگیرید

یک کلاینت باید صاحب مسیر پیش‌فرض باشد و دیگری فقط پیشوندهای خودش را حمل کند. OpenVPN کلاینت‌ها می‌توانند آنچه را سرور هل می‌دهد رد کنند.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull هر مسیر هل‌داده‌شده را نادیده می‌گیرد، در حالی که pull-filter ignore "redirect-gateway" فقط دستور مسیر پیش‌فرض را دور می‌ریزد و DNS و گزینه‌های دیگر هل‌داده‌شده را نگه می‌دارد. بین این دو بر پایه اینکه چه مقدار از پیکربندی سرور را هنوز می‌خواهید انتخاب کنید، سپس پیشوندهای مشخصی را که شبکه دوم لازم دارد بیفزایید. DNS را در نظر داشته باشید، چون حل‌کننده‌ای که تونلی هل می‌دهد که پرس‌وجوها را حمل نمی‌کند چیزی برنمی‌گرداند. یک میزبان شناخته‌شده را در هر شبکه آزمایش کنید و آدرس مبدئی را که طرف دور می‌بیند تأیید کنید.

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

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

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