VPN تودرتو: کدام تونل اتصال بیرونی را حمل میکند؟
تونل درونی به مسیری بیرونی تا نقطه پایانی خود نیاز دارد. دو کلاینتی که با ترتیب اشتباه شروع شوند تعارض مسیر میسازند، پس نخست تودرتویی را درست کنید.
دو کلاینت VPN که همزمان کار میکنند تونل تودرتو نمیسازند؛ دو تونل و دعوایی بر سر مسیریابی میسازند. تونل تودرتو زمانی وجود دارد که اتصال کلاینت درونی به سرور خودش را خودِ تونل بیرونی حمل کند، و این چیدمانی است که عمداً ساخته میشود. اگر درست باشد، سرور درونی نشانی سرور بیرونی را میبیند؛ اگر غلط باشد، یک کلاینت بیصدا دور دیگری دوباره وصل میشود. سه شرط تعیین میکند که تودرتویی واقعی است یا تصادفی.
سه شرط تودرتویی را تعیین میکند
نخستین این است که کدام نقطه پایانی به کدام مسیر نیاز دارد. نشانی سرور درونی را نام ببرید، نشانی سرور بیرونی را نام ببرید و صریح بگویید که سرور درونی فقط از راه تونل بیرونی در دسترس است. هر چیز دیگری از همان جمله برمیآید، از جمله اینکه کدام مسیرها به کدام جدول تعلق دارند.
دومین این است که آیا میتوانید مسیر را در هر لایه ببینید. اگر نتوانید از هسته بپرسید که یک مقصد مشخص از کدام مسیر استفاده میکند، زنجیره را از یک IP خروجی نهایی استنتاج میکنید، و این دقیقاً همان شاهدی است که نمیتواند تودرتویی را از تصادف جدا کند.
سومین این است که وقتی تونل بیرونی میافتد چه میشود. تونل درونی میتواند با آن متوقف شود، از راه شبکه معمولی دوباره وصل شود یا تا بازگشت مسیر بیرونی مسدود بماند، و هر سه سیاستهای قابل دفاعی هستند. آنها یک سیاست نیستند، و رفتار پیشفرض بیشتر کلاینتها دومی است. کلاینتی که نقطه پایانی خود را از راه شبکه فیزیکی دوباره وصل میکند و در همان حال اتصال سالم نشان میدهد، رایجترین راهی است که یک زنجیرهٔ عمدی بیصدا به دو تونل بیربط تبدیل میشود.
شرط یکم: کدام نقطه پایانی به کدام مسیر نیاز دارد
ip route get 203.0.113.10 مستقیم به آن پرسش پاسخ میدهد: مسیر، نشانی مبدأ و رابطی را چاپ میکند که هسته همین حالا برای آن مقصد استفاده میکند.
آن را برای سرور درونی پیش از شروع کلاینت درونی و بار دیگر پس از آن اجرا کنید و مقایسه کنید. اگر پاسخ از رابط فیزیکی به رابط تونل بیرونی تغییر کند، تودرتویی در آن لحظه واقعی است. اگر تغییر نکند، کلاینت درونی مستقیم وصل میشود، هر چه پنل بگوید. آن را برای نشانی سرور بیرونی تکرار کنید که هنوز باید از راه رابط فیزیکی حل شود، زیرا مسیری که هر دو نقطه پایانی را بهصورت بازگشتی میگیرد همان خرابیای است که ماشین را کاملاً از شبکه بیرون میبرد.
شرط دوم: مسیر را در هر لایه بررسی کنید
انتخاب مسیر در یک کلاینت مدرن بیش از جدول اصلی است. قواعد سیاست میتوانند بستههای علامتخورده را به جدول دیگری بفرستند، کلاینت میتواند سوکت خود را به یک رابط ببندد، و کانتینر یا فضای نام جدولهای خودش را دارد. ip rule و ip route show table all راه پی بردن به این است که کدامیک از این سازوکارها در جریان است.
کلاینتی که SO_MARK را روی سوکت خودش میگذارد، یا طوری پیکربندی شده که به دستگاه مشخصی ببندد، از مسیر پیشفرضی که فکر میکردید ترتیب دادهاید عبور میکند. این یک ویژگی است نه اشکال، و یعنی تنها بررسی قابل اعتماد همانی است که در همان فضای نام کلاینت اجرا میشود. اگر کلاینتها در کانتینر اجرا میشوند، بررسیها را در همان کانتینرها اجرا کنید نه روی میزبان.
شرط سوم: وقتی تونل بیرونی میافتد چه میشود
رفتار در خرابی به تصمیم نیاز دارد، نه به مقدار پیشفرض. بنویسید وقتی تونل بیرونی ناپدید میشود با تونل درونی چه باید بشود، سپس کلاینتها را وادار کنید همان کار را بکنند.
گزینهها مشخصاند. توقف کلاینت درونی وقتی مسیر بیرونی ناپدید میشود زنجیرهای پاک و قطعی آشکار میدهد. اجازه دادن به آن برای اتصال مستقیم دوباره دسترسپذیری میدهد و ویژگیای را که زنجیره برایش ساخته شده بود بیصدا حذف میکند. مسدود کردن تا بازگشت مسیر بیرونی سختگیرانهترین و آزاردهندهترین گزینه برای بهرهبرداری است، چون هر لرزش تونل بیرونی به یک رخداد دیدنی تبدیل میشود.
هر سه را با ترافیک بیخطر و یک خرابی عمدی تونل بیرونی بیازمایید، چون خواندن پیکربندی به شما نمیگوید کدام را دارید. تونل بیرونی را بکشید، ببینید کلاینت درونی چه میکند و در حالی که افتاده مسیر را دوباره بررسی کنید. سپس تونل بیرونی را برگردانید و تأیید کنید که زنجیره دوباره شکل میگیرد و کلاینت درونی را روی مسیر مستقیمی که در این میان انتخاب کرده رها نمیکند.
آنچه زنجیره به شما نمیدهد
لایههای بیشتر نقاط پایانی، کلیدها و حالتهای خرابی اضافه میکنند؛ هیچ تضمینی برای ناشناسی اضافه نمیکنند و مانع نمیشوند که اپراتور بیرونی ببیند تونلی وجود دارد. هر ادعایی درباره اینکه تودرتویی از چه چیزی محافظت میکند باید ناظری را که از آن محافظت میکند نام ببرد.
خروجی یک سند کوتاه است نه یک اتصال کارکننده: کدام نقطه پایانی از کدام مسیر استفاده میکند، در خرابی بیرونی چه میشود و سه فرمانی که وضعیت کنونی را نشان میدهند. مستندات strongSwan درباره ارسال به جلو مرجع سودمندی است برای اینکه ترافیک تونل روی یک میزبان Linux چگونه میان رابطها ارسال میشود. بررسیها را پس از هر بهروزرسانی کلاینت دوباره اجرا کنید، چون پیشفرضهایی که زنجیره شما را ساختند قرارداد نیستند. تونل تودرتویی که نمیتوانید بررسی کنید شایعهای با چراغ وضعیت است.