آداپتور VPN عدد /32 را نشان می‌دهد: معنایش یک مقصد نیست

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

افسانه: ماسک میزبان یعنی یک میزبان قابل‌دسترسی

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

این سردرگمی ریشهٔ واقعی دارد: روی اترنت، ماسک میزبان واقعاً به معنای یک نشانی واحد در آن قطعه بود. تونل یک قطعهٔ اترنت نیست و این که چه چیزی از آن می‌گذرد را جدول مسیریابی کلاینت تعیین می‌کند، نه ماسک. به همین دلیل همان /32 می‌تواند جلوی یک مرکز دادهٔ کامل بنشیند.

نشانی و مسیرها را دو شیء جدا بخوانید

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

ip addr show tun0
ip route show
ip route get 10.60.5.10

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

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

اگر جست‌وجو به واسط اشتباه اشاره کرد، متوقف شوید. این مشکل مسیریابی کلاینت است و روی کلاینت رفع می‌شود.

چرا پهن‌تر کردن ماسک معمولاً اوضاع را بدتر می‌کند

تغییر تخصیص به /24 تا شبیه LAN دفتر شود می‌تواند یک پیشوند روی پیوند بسازد: هسته اکنون باور دارد که تمام /24 مستقیماً به واسط تونل وصل است. ترافیک نشانی‌هایی که باید از دروازه مسیریابی شوند آن‌گاه طوری فرستاده می‌شود که گویی همسایه‌ای روی پیوند است. نتیجه یک چالهٔ سیاه است که شبیه قطعی سرور به نظر می‌رسد.

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

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

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

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

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

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

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