دو کلاینت VPN به‌طور همزمان: کدام یک مسیر پیش‌فرض را می‌برد؟

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

جدول مسیر یک برنده را انتخاب می‌کند

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

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

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

ip rule show

ویندوز با متریک‌ها آن را حل می‌کند

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

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

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

دو ناظر، دو دیدگاه متفاوت

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

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

DNS و IPv6 همان جایی هستند که زنجیره نشت می‌کند

DNS از هر تنظیم resolver که برنده شود پیروی می‌کند، و این لزوماً مسیری نیست که بسته‌ها طی می‌کنند. resolver شرکتی که از طریق تونل شرکتی به‌دست می‌آید با طراحی سازگار است؛ resolver محلی که از بیرون آن به‌دست می‌آید نه، و نام‌هایی را افشا می‌کند که تونل قرار بود پنهان کند. IPv6 نشت دوم است: میزبان دوپشته همچنان IPv6 را به سمت مقاصدی به کار می‌برد که تونل فقط از طریق IPv4 حمل می‌کند. خانواده‌ها را جداگانه بررسی کنید، چون تونل فقط IPv4 هیچ چیزی درباره مسیرها یا resolverهای IPv6 نمی‌گوید.

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

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