VPN مهمان و VPN میزبان: کدام مسیر واقعاً برنده می‌شود

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

نخست اتصال مهمان را ثبت کنید

مهمان از هر مسیری که هایپروایزر به او داده به سرور VPN خود می‌رسد: NAT پشت میزبان، یک پل به بخش فیزیکی، یا شبکه فقط-میزبان با مسیریابی افزوده روی آن. هر اتصال تغییر می‌دهد که مهمان چه می‌تواند ببیند و میزبان با ترافیک او چه می‌تواند بکند. در زیر NAT بسته‌های مهمان طوری به نظر می‌رسند که از میزبان می‌آیند، بنابراین تونل خود میزبان می‌تواند آنها را حمل کند بدون آنکه مهمان چیزی از آن بداند. در زیر پل، مهمان حضور خودش را روی بخش و دروازه پیش‌فرض خودش را دارد.

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

نقطه پایانی مهمان را به بیرون دنبال کنید

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

یک مسیر گسترده در هر یک از دو بافت ترافیکی را می‌گیرد که کلاینت دیگر انتظارش را داشت. مسیر 0.0.0.0/0 درون مهمان و کلاینت میزبان با تونل کامل هر دو مدعی همه‌چیز هستند و هر کدام دیرتر اعمال شود برنده است. هم‌پوشانی میان شبکه‌های مجازی مهمان، LAN محلی و شبکه‌های دوردست همان اثر را برای پیشوندهای خصوصی دارد، با خطاهایی که شبیه مشکلات احراز هویت‌اند؛ رفتار ترجمه نشانی همان است که برای شبکه‌بندی کانتینر توصیف شده.

ثبت پیش و پس را مقایسه کنید

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

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

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

مالکیت را در طول راه‌اندازی‌های مجدد روشن نگه دارید

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

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