چرا مسیر میزبان /32 نقطه پایانی VPN را در دسترس نگه می‌دارد
مسیر میزبان یک نشانی را انتخاب می‌کند، نه یک زیرشبکه. می‌تواند نقطه پایانی تونل را در دسترس نگه دارد یا یک منبع را سنجاق کند، اما با تغییر نشانی‌ها کهنه می‌شود.
پس از اتصال، جدول مسیریابی را باز می‌کنید و می‌بینید یک نشانی از تونل عبور می‌کند، در حالی که زیرشبکه اطراف آن هنوز به دروازه محلی می‌رود. آن ورودی یک مسیر میزبان است: یک نشانی، که با پیشوندی از همه یک‌ها تطبیق داده می‌شود. اهمیت دارد چون تصمیم‌های مسیریابی از طولانی‌ترین پیشوند منطبق استفاده می‌کنند، پس یک /32 می‌تواند بر /24 یا مسیر پیش‌فرض چیره شود بدون آنکه هیچ‌کدام را تغییر دهد. اینکه این یک استثنای دقیق است یا یک قطعی آینده، به این بستگی دارد که کدام نشانی را نام می‌برد و چه کسی آن را نگه می‌دارد.
یک نشانی، یک ورودی در جدول
یک مسیر میزبان IPv4 پیشوند /32 دارد و یک مسیر میزبان IPv6 پیشوند /128، یعنی ورودی می‌تواند دقیقاً با یک نشانی مقصد منطبق شود. چیز دیگری در جدول جابه‌جا نمی‌شود: زیرشبکه پوشاننده و مسیر پیش‌فرض همان‌جا می‌مانند که بودند. ورودی باریک برای آن نشانی برنده می‌شود چون پیشوندش طولانی‌تر است، نه چون بعداً افزوده شده است.
این ویژگی مسیر میزبان را استثنایی خوب و عادتی بد می‌کند. دو ورودی /32 که درِ ورودی یک سرویس را نام می‌برند، نشانی دومش، نشانی IPv6اش یا نشانی‌ای که ماه بعد به آن منتقل می‌شود را پوشش نمی‌دهند. جدولی پر از ورودی‌های تک‌نشانی توضیح‌نشده معمولاً یعنی کسی به‌جای گرفتن تصمیم زیرشبکه، مدام دور آن وصله می‌زده است. اول طول پیشوند را بخوانید، بعد بپرسید ورودی قرار است از چه چیزی محافظت کند.
ورودی را از سمت کارخواه به بیرون بخوانید
از ماشینی شروع کنید که مشکل دارد، چون همان نشانی می‌تواند روی یک لپ‌تاپ و روی دروازه جلوی آن متفاوت مسیریابی شود. از هسته بپرسید برای نشانی دقیقی که برنامه استفاده می‌کند کدام مسیر را انتخاب می‌کند، به‌جای خواندن جدول از بالا. پاسخ شامل رابط و گام بعدی است که با هم همان تصمیم‌اند.
ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25پرسش را برای خانواده نشانی‌ای که برنامه واقعاً انتخاب می‌کند تکرار کنید، چون کارخواه می‌تواند IPv6 را ترجیح دهد و بی‌صدا از یک استثنای IPv4 عبور کند. نتیجه را پیش و پس از بالا آمدن تونل مقایسه کنید و هر دو خروجی را نگه دارید. این مقایسه نشان می‌دهد کارخواه ورودی را هنگام اتصال افزوده یا از قبل آنجا بوده است.
ورودی پایدار و ورودی زمان اجرا متفاوت شکست می‌خورند. ورودی زمان اجرا با نشست ناپدید می‌شود، در حالی که پایدار از راه‌اندازی دوباره جان سالم به در می‌برد و همچنان ترافیک را به دروازه‌ای می‌فرستد که دیگر وجود ندارد.
استثنای نقطه پایانی و تله بازگشت
کارخواه‌های VPN معمولاً یک مسیر میزبان به نشانی بیرونی سرور را از طریق دروازه اصلی پیش از تغییر مسیر پیش‌فرض نصب می‌کنند. بدون آن ورودی، بسته‌های رمزنگاری‌شده به درون تونلی فرستاده می‌شدند که در تلاش برای ساختنش هستند و اتصال تا پایان مهلت در حلقه می‌ماند.
تله وقتی ظاهر می‌شود که زیرشبکه‌های پذیرفته‌شده تونل تصادفاً آن نشانی نقطه پایانی را در بر بگیرند، یا وقتی پروفایل دومی بعداً مسیر گسترده‌تری بیفزاید. آن‌گاه ورودی نقطه پایانی به پیشوندی طولانی‌تر می‌بازد و نشست به‌محض شروع عبور ترافیک فرو می‌ریزد. نوشتن نشانی نقطه پایانی در کنار زیرشبکه‌های پذیرفته‌شده ارزان‌ترین راه برای دیدن برخورد پیش از کاربران است. همچنین توضیح می‌دهد چرا همان پروفایل از یک شبکه کار می‌کند و از شبکه‌ای دیگر شکست می‌خورد.
مسیری را که برنامه واقعاً استفاده می‌کند بررسی کنید
ping موفق به نام میزبان شواهد ضعیفی است وقتی برنامه به نشانی دیگری یا خانواده دیگری وصل می‌شود. ترکیب دقیق نشانی، خانواده، درگاه و رابط را از ماشینی که کارخواه را اجرا می‌کند بررسی کنید.
ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.netاگر مسیر غلط است، پیش از تغییر هر چیزی تصمیم بگیرید نیاز یک شبکه است یا یک نشانی. نیاز به یک نشانی، مسیر میزبان را با یک توضیح و یک مالک توجیه می‌کند؛ سرویسی با نشانی‌های چرخشی به مسیریابی مبتنی بر دامنه یا تصمیمی صادقانه درباره زیرشبکه نیاز دارد.
ورودی‌هایی را که دیگر به مقصد واقعی نگاشت نمی‌شوند بردارید و آن‌هایی را که نگه می‌دارید یادداشت کنید. یک /32 توضیح‌نشده سه ماه بعد از یک باگ قابل تشخیص نیست و نفر بعدی آن را حذف می‌کند بدون اینکه بداند چه چیزی به آن وابسته بوده است.