چرا تونل VPN دوم تونل اول را خراب می‌کند؟

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

نشانه: کلاینت دوم بی‌صدا برنده می‌شود

OpenVPN: گزینه redirect-gateway def1 مسیر 0.0.0.0/0 را بازنویسی نمی‌کند. 0.0.0.0/1 و 128.0.0.0/1 را اضافه می‌کند: این دو با هم همه نشانی‌های IPv4 را پوشش می‌دهند و هر پیشوند از نظر طول بر یک مسیر پیش‌فرض ساده می‌چربد. مسیر پیش‌فرض اصلی در جدول می‌ماند و دیگر برای ترافیک معمولی استفاده نمی‌شود، و یک مسیر میزبان به سرور VPN مانع از آن می‌شود که تونل بسته‌های بیرونی خودش را بگیرد. هر دو کلاینت این کار را می‌کنند و دومی به‌سادگی جفت خود را دیرتر نصب می‌کند.

به همین دلیل تونل اول مرده به نظر می‌رسد نه قطع‌شده. رابطش بالاست، کانال کنترلی‌اش زنده است و دیگر هیچ ترافیک برنامه‌ای به آن نمی‌رسد. شکایت برعکس هم همان نبود push را دارد: تلفنی که وصل می‌شود اما چیزی نمی‌فرستد معمولاً با سروری حرف می‌زند که هرگز redirect-gateway را اعلام نکرده، پس دستگاه پیش‌فرض خودش را نگه می‌دارد و فقط به استخر می‌رسد.

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

بخوانید کدام تونل واقعاً برنده است

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

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

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

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

ویندوز: نگذارید یک پروفایل مالک پیش‌فرض باشد

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

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

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

پروفایل‌های راه‌اندازی‌شده با برنامه ویژگی دیگری است و ارزش دانستن دارد: پروفایل ویندوز می‌تواند با اجرای یک فایل اجرایی نام‌برده شروع شود و فیلترهای ترافیک تعیین می‌کنند چه چیزی حمل می‌کند. این تنظیم پروفایل است نه قاعده فایروال، و مسئله‌ای متفاوت از تعارض مسیر پیش‌فرض را حل می‌کند.

لینوکس: تونل دوم را از جدول اصلی بیرون نگه دارید

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

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

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

فضاهای نام شبکه سنگین‌ترین و تمیزترین گزینه‌اند. کلاینت دوم را درون ip netns شروع کنید، به آن یک جفت veth بدهید و برای استفاده وارد آن فضای نام شوید. تداخل از بین می‌رود چون هر فضای نام جدول‌های خودش را دارد نه یکی مشترک، و وقتی هر دو تونل باید هفته‌ها بالا بمانند این راه‌اندازی اضافی می‌ارزد.

بر اساس برنامه، و زنجیره‌سازی به‌عنوان مسئله‌ای جدا

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

زنجیره‌سازی عملیاتی متفاوت از اجرای دو تونل در کنار هم است. زنجیره‌سازی A روی B یعنی نشانی سرور درونی باید از درون تونل بیرونی قابل دسترسی باشد. کلاینت بیرونی هم نباید بسته‌های رمزنگاری‌شده کلاینت درونی را نشتی بگیرد. یک کلاینت درون ماشین مجازی نسخه خشن اما مطمئن است؛ هر دو روی یک میزبان به کار مسیریابی بالا به‌علاوه مسیری بیرونی به‌سوی سرور درونی نیاز دارد که هرگز وارد تونل درونی نشود.

مالک پیش‌فرض، فهرست پیشوندهای هر تونل و مسیر DNS را بنویسید. این سه واقعیت حادثه بعدی را به یک جست‌وجو تبدیل می‌کند نه یک بررسی.