دو دروازه، یک VPN: چرا OpenVPN پیوند بالا را اشتباه انتخاب می‌کند

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

آدرس تونل نقطه پایانی نیست

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

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

آدرسی را پیدا کنید که کلاینت واقعاً با آن تماس گرفت

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

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

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

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

نقطه پایانی را سنجاق کنید و ترتیب سیاست را بخوانید

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

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

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

ip rule show
ip route get 203.0.113.40

دستور دوم را با همان آدرس مبدأ یا نشانه‌ای که کلاینت استفاده می‌کند بپرسید، هنگامی که سیاست به آن‌ها وابسته است. این دستور مسیری را گزارش می‌کند که کرنل انتخاب می‌کرد، که شاهدی درباره جست‌وجو است و نه اثباتی بر اینکه سوکت زنده از آن مسیر استفاده می‌کند.

وقتی نقطه پایانی جابه‌جا می‌شود

نام میزبانی که به چندین آدرس حل می‌شود، به‌محض تغییر پاسخ یک /32 دائمی را باطل می‌کند. پروفایلی با چند خط remote همین مشکل را دارد، چون کلاینت ممکن است روی هر یک از آن‌ها فرود بیاید. مسیر را از قلاب‌های چرخه عمر خود کلاینت تازه کنید، نه اینکه آن را دستی اضافه کنید. اسکریپت up که همتای مذاکره‌شده را می‌خواند و مسیر میزبان را نصب می‌کند، استثنا را با واقعیت هم‌راستا نگه می‌دارد، و اسکریپت down متناظر آن را حذف می‌کند.

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

سیاست درونی را جدا نگه دارید

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

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

نتیجه را با دو مشاهده مستقل تأیید کنید: آدرس محلی و دستگاه سوکت، و مسیری که مقصد خصوصی به آن حل می‌شود. وقتی هر دو با قصد شما هم‌خوان باشند، تقسیم واقعی است. راهنمای OpenVPN 2.6 گزینه‌های remote و اتصال محلی را پوشش می‌دهد که تعیین می‌کنند کلاینت با کدام آدرس تماس می‌گیرد.