چرا یک مسیر VPN در خروجی ip route هیچ دروازه‌ای نشان نمی‌دهد
خطی که واسط دارد و دروازه ندارد یک مسیر مستقیم است، نه یک مسیر خراب. مقصد، dev و scope را بخوانید و سپس با ip route get تأیید کنید.
جدول‌های مسیریابی هر بار که ستون دروازه خالی بماند به‌عنوان خراب خوانده می‌شوند، در حالی که خط معمولاً به‌تنهایی کامل است. فیلد via تنها زمانی ظاهر می‌شود که هسته بسته را به نشانی گام بعدی بسپارد؛ مسیری که به یک واسط متصل است در عوض از طریق تفکیک لایه پیوند یا از طریق همتای نقطه‌به‌نقطه به مقاصد خود می‌رسد. خواندن ستون‌ها از چپ به راست به شما می‌گوید در کدام حالت هستید، و این خواندن باید پیش از آن انجام شود که کسی یک مسیر پیش‌فرض را ویرایش کند. بیشتر تیکت‌های مربوط به دروازه گمشده در همین تمایز تمام می‌شوند.
یک خط مسیر را ستون‌به‌ستون بخوانید
هر ورودی با مقصد و طول پیشوند آن آغاز می‌شود و سپس اصلاح‌گرها را در واژگانی ثابت می‌افزاید: via، dev، proto، scope، src و metric. خطی مانند 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 فشرده اما کاملاً مشخص است. چیزی از آن کم نیست و هیچ نشانی از مسیریاب در آن تلویح نمی‌شود.
نبود via بخش جالب ماجراست. بدون گام بعدی، هسته مقصد را مستقیماً روی واسط نام‌برده تفکیک می‌کند، که برای یک تونل یعنی سپردن قاب به دستگاه تونل و واگذاشتن کپسوله‌سازی به آن از همان‌جا. proto kernel ثبت می‌کند که ورودی هنگام تخصیص یک نشانی به‌طور خودکار نصب شده است، نه اینکه مدیری آن را تایپ کرده باشد. scope link می‌گوید مقصد روی همان پیوند و بدون گذر از مسیریاب قابل دسترسی است، و src نشانی‌ای را نام می‌برد که هسته آن را به‌عنوان مبدأ برای ترافیک منطبق ترجیح می‌دهد.
حالا یک مسیر پیش‌فرض را به همان روش بخوانید: default via 192.0.2.254 dev eth0 proto static metric 100. اینجا via حاضر است چون بسته واقعاً به گام بعدی نیاز دارد، و آن گام باید خودش روی eth0 قابل دسترسی باشد. این دو خط واریانت یکدیگر نیستند؛ آن‌ها به پرسش‌های متفاوتی درباره اینکه ترافیک کجا می‌رود پاسخ می‌دهند.
دو شکل مسیر که با هم اشتباه گرفته می‌شوند
مسیر یک زیرشبکه تونل و یک مسیر پیش‌فرض در یک تصویر صفحه‌نمایش شبیه هم به نظر می‌رسند و کاملاً متفاوت رفتار می‌کنند. از جدول زیر به‌عنوان کمک‌خواندن برای فیلدها استفاده کنید و سپس اعداد واقعی را روی ماشینی که عیب‌یابی می‌کنید تأیید کنید، نه اینکه به نمونه‌ای از یک راهنما اعتماد کنید.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
چیزی که جدول نمی‌تواند به شما بگوید قصد است. مسیر مستقیم به یک بازه خصوصی از طریق تونل، طراحی عامدانه تونل تقسیم‌شده است؛ همان شکل روی میزبانی که باید همه چیز را از VPN بفرستد نشانه مشکل است. قصد در پیکربندی‌ای زندگی می‌کند که ورودی را ساخته است، پس پیش از نتیجه‌گیری اینکه هسته چیزی را اشتباه کرده به ابزاری نگاه کنید که آن را نصب کرده است.
به همین ترتیب، نبود دروازه اجازه اختراع یکی نیست. اگر مسیری واقعاً به گام بعدی نیاز دارد، آن گام باید روی واسطی که آن را حمل می‌کند قابل دسترسی باشد، و برای تونل نقطه‌به‌نقطه نشانی همتا همان شیء نشانی محلی نیست. برخورد با نشانی محلی تونل به‌عنوان یک مسیریاب اترنت روش رایجی برای ساختن مسیری است که درست به نظر می‌رسد و چیزی را ارسال نمی‌کند.
از هسته بپرسید که واقعاً کدام خط را استفاده می‌کند
خواندن جدول با انجام جست‌وجو یکی نیست، زیرا هسته پیش از پاسخ دادن با قواعد سیاست، چند جدول و ورودی‌های کش‌شده مشورت می‌کند. فعلی که جست‌وجوی واقعی را انجام می‌دهد ip route get است و مسیری را چاپ می‌کند که بسته‌ای با آن ویژگی‌ها طی می‌کند.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0مقصدی را که واقعاً برایتان مهم است جایگزین کنید، سپس وقتی ترافیک بر اساس مبدأ انتخاب می‌شود یا ارسال می‌شود from یا iif را اضافه کنید، چون یک جست‌وجوی محلی معمولی می‌تواند مسیری متفاوت از یک کارخواه ارسال‌شده انتخاب کند. پاسخ واسط، نشانی مبدأ انتخاب‌شده و هر گام بعدی را نام می‌برد، که همان اطلاعاتی است که یک بسته در آن لحظه با آن مسیریابی می‌شد.
اگر پاسخ شگفت‌زده‌تان کرد، پیش از هر تغییری قواعد را چاپ کنید: ip -4 rule show آن‌ها را به ترتیب اولویت فهرست می‌کند، و کارخواه VPN که جدول خودش یا قاعده‌ای برای بسته‌های علامت‌خورده نصب می‌کند اصلاً در جدول اصلی ظاهر نمی‌شود. فهرست کردن همه جدول‌ها آن شکاف را می‌بندد.
ip -4 route show table all | grep -E 'tun|default'پیش از جایگزینی مسیر پیش‌فرض، لایه زیرین را بررسی کنید
بسته‌های خود تونل باید به نقطه پایانی دور برسند، و این کار را از طریق واسط فیزیکی با مسیری انجام می‌دهند که پیش از بالا آمدن VPN وجود داشت. جایگزینی کل مسیر پیش‌فرض بدون سنجاق کردن آن نقطه پایانی، بسته‌های کپسوله‌شده را به تونلی می‌فرستد که قرار است بسازند، و اتصال فرو می‌ریزد. ابتدا مسیر نقطه پایانی را با جست‌وجویی تنها برای نشانی آن تأیید کنید.
هنگام ایجاد تغییر سه چیز را جدا نگه دارید: مسیر نقطه پایانی که باید روی واسط فیزیکی بماند، بازه‌های خصوصی که باید وارد تونل شوند، و مسیر پیش‌فرضی که درباره بقیه چیزها تصمیم می‌گیرد. آن‌ها را به همین ترتیب از هم جدا کنید، یکی‌یکی اعمال کنید، و پس از هر گام جست‌وجو را دوباره اجرا کنید. یک ping ناموفق پس از آن به‌تنهایی چیز زیادی ثابت نمی‌کند، چون مجوزها، مسیریابی پاسخ، DNS و خود سرویس همه در پایین‌دست یک مسیر درست قرار دارند.
چهار مقداری را که خط پیش از ویرایش به شما داد بنویسید: مقصد، گام بعدی یا نبودش، دستگاه، و مبدأ انتخاب‌شده. اگر تغییری در آینده هر یک از آن‌ها را جابه‌جا کند، می‌دانید کدام تصمیم واقعاً عوض شده است، و می‌توانید یک ورودی را بازگردانید به‌جای اینکه درباره کل جدول حدس بزنید.