آیکون سبز، همان IP عمومی: کدام مسیر را VPN جا انداخت

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

آنچه کلاینت واقعاً نصب کرده است

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

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

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

سه شکل مسیریابی گزینشی

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

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

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

طرف مقابل باید آدرس مبدأ را بازنویسی کند

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

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

رابطی را نام ببرید که واقعاً به اینترنت نگاه می‌کند، که در توزیع‌های امروزی همیشه eth0 نیست. سرور میزبانی‌شده با آدرس ثابت می‌تواند به‌جای masquerade صریحاً به همان آدرس ترجمه کند. هر دو نیمه مهم‌اند، زیرا هدایت بدون ترجمه مبدأهای غیرقابل‌مسیریابی را نشت می‌دهد و ترجمه بدون هدایت هرگز بسته را نمی‌بیند.

تجزیهٔ نام مسیر خودش را می‌رود

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

resolvectl status | head -20
resolvectl query example.org

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

چهار مشاهده که موضوع را روشن می‌کند

آدرس خروج را با تونل خاموش ثبت کنید، سپس با تونل روشن. بررسی مقصد را در هر دو حالت اجرا کنید و هر بار رابط را یادداشت کنید.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

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