جدول مسیریابی در برابر جستجوی واقعی: ترافیک VPN کجا می‌رود
از یک مقصد و منبعش شروع کنید، سپس بررسی کنید کدام قاعده و جدول واقعاً مسیر را تعیین می‌کنند. تخلیه کامل جدول بدون آن بافت گمراه می‌کند.
تخلیه جدول مسیریابی کم‌فایده‌ترین ابزار تشخیصی در عیب‌یابی VPN و پرکاربردترین چیزی است که کپی می‌شود. چهل خط پیشوند به شما می‌گوید ماشین چه کاری می‌توانست انجام دهد، نه اینکه برای درخواست ناموفق چه کرد. سازوکاری که واقعاً می‌خواهید همان جستجو است: با داشتن این منبع و این مقصد، کدام قاعده مطابقت کرد، کدام جدول مشورت شد و کدام رابط و گام بعدی بیرون آمد. از یک مقصد و یک منبع شروع کنید، سپس جدول را با آن پرسش در ذهن بخوانید و همان خروجی به جای نویز، شاهد می‌شود.
جدول مجموعه‌ای از نامزدهاست، نه تصمیم
هر ورودی یک پیشوند و آنچه باید با ترافیک منطبق با آن کرد را توصیف می‌کند: آن را به یک رابط بفرست، به گام بعدی بسپار یا دور بینداز. هیچ چیز در آن فهرست بر اساس قصد مرتب نشده است و ورودی که به نظر انسان مشخص‌ترین می‌آید همیشه آن نیست که هسته انتخاب می‌کند، زیرا انتخاب از تطبیق بلندترین پیشوند و در میان پیشوندهای برابر از متریک پیروی می‌کند.
پس نخستین گام پرسیدن از هسته است، نه خواندن فهرست. فرمان جستجو برای یک مقصد پاسخ می‌دهد و با آرگومان منبع برای همان جفت دقیقی پاسخ می‌دهد که یک اتصال هدایت‌شده یا مقید به کار می‌برد:
ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40هر نشانی بالا یک نمونه مستندسازی است. نکته شکل پاسخ است: رابط، نشانی منبع انتخاب‌شده، دروازه و جدولی که ورودی از آن آمده است. اگر آن خروجی با رابطی که انتظار داشتید مطابقت نداشته باشد، مشکل را با یک فرمان محدود کرده‌اید و هیچ مقدار خواندن جدول کامل به شما نمی‌گفت کدام نامزد برنده شد.
جستجو نخست از قاعده‌ها و سپس از جدول‌ها می‌گذرد
در Linux تصمیم دو مرحله‌ای است. قاعده‌های سیاست به ترتیب اولویت ارزیابی می‌شوند و نخستین قاعده‌ای که مطابقت کند جدولی را برای مشورت نام می‌برد؛ آن جدول سپس تطبیق بلندترین پیشوند را انجام می‌دهد. یک قاعده می‌تواند بر اساس منبع، مقصد، نشان فایروال، رابط یا ترکیبی مطابقت کند، و به همین دلیل تخلیه جدول اصلی می‌تواند کاملاً دقیق و برای بسته‌ای که بررسی می‌کنید کاملاً بی‌ربط باشد.
ip rule show
ip route show table all | head -40
ip route show table 100اگر قاعده‌ای ترافیک را از مجموعه VPN شما به جدول 100 بفرستد، آنگاه جدول 100 همان است که اهمیت دارد، و جدول اصلی یک طعمه است. این همچنین سازوکار مسیریابی مبتنی بر منبع روی یک مسیریاب است: یک مقصد می‌تواند بسته به اینکه بسته از کجا آمده دو پاسخ متفاوت داشته باشد و تنها جستجو با آرگومان منبع آشکار می‌کند کدام یک اعمال می‌شود.
IPv6 قاعده‌ها و جدول‌های خودش را دارد. طراحی‌ای که هر دو خانواده را اجرا می‌کند به هر دو جستجو نیاز دارد و یک پاسخ کارآمد IPv4 هیچ چیزی درباره مسیر v6 که یک کلاینت دواستکه ممکن است ترجیح دهد نمی‌گوید.
کلاینت VPN چه چیزی نصب می‌کند
کلاینت‌ها معمولاً مسیر پیش‌فرض را جایگزین نمی‌کنند، زیرا این کار مسیر بیرونی خود تونل را می‌شکند. چیزی مشخص‌تر نصب می‌کنند که با طول پیشوند برنده می‌شود: یک جفت نیمه‌پیش‌فرض که 0.0.0.0/1 و 128.0.0.0/1 را پوشش می‌دهند ترفند کلاسیک است، چون هر دو پیشوندهایی بلندتر از 0.0.0.0/0 هستند و با هم کل فضا را پوشش می‌دهند. دیگران پیشوندهای خصوصی مشخص به‌همراه یک قاعده سیاست نصب می‌کنند و برخی نشانه‌ای اضافه می‌کنند تا فقط ترافیک انتخابی گرفته شود.
به همین دلیل "VPN مسیر پیش‌فرض من را تغییر نداد" مدرکی بر شکست نیست. بررسی کنید واقعاً چه چیزی اضافه کرد و آیا مقصد مورد نظر درون آن پیشوندها می‌افتد:
ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25دو نیمه‌مسیر در یک تخلیه به‌راحتی از چشم می‌افتند زیرا شبیه پیش‌فرض نیستند. پیکربندی تونل تقسیم‌شده‌ای که فراموش کرده پیشوندی را شامل شود دقیقاً همان نشانه‌ای را تولید می‌کند که دنبالش هستید: برنامه‌ای که باید از تونل استفاده کند به‌جای آن به‌صورت محلی حل و وصل می‌شود. پیشوندهای نصب‌شده را با مقصدهایی که کاربر واقعاً نیاز دارد مقایسه کنید، نه با نشانی‌هایی که تصادفاً آزمایش کردید. فهرست تونل تقسیم‌شده‌ای که سرور فایل را پوشش می‌دهد اما حل‌کننده آن را نه، اتصالی تولید می‌کند که به یک نشانی عمومی حل می‌شود و سپس در احراز هویت شکست می‌خورد، که شبیه مشکل رمز عبور است و مشکل مسیر است.
مسیر بیرونی هم باید زنده بماند
تونل خودش ترافیک است. بسته‌هایی که بار کپسول‌شده را حمل می‌کنند از طریق رابط فیزیکی به نشانی همتا می‌روند و آن مسیر نباید به داخل تونل مسیریابی شود. وقتی این اتفاق بیفتد، شکست مشخصی می‌گیرید که تونل برقرار می‌شود و سپس از عبور ترافیک بازمی‌ماند، چون انتقال تونل اکنون داخل تونل است.
نشانی همتا را همان‌گونه که مقصد داخلی را بررسی کردید بررسی کنید و تأیید کنید که به رابط فیزیکی حل می‌شود نه به تونل:
ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10یک مسیر بازگشتی، یک قاعده سیاست که همتا را می‌گیرد، یا یک مسیر پیش‌فرض که با کلاینت تونل کامل جایگزین شده است سه علت معمول هستند. هر سه در جستجوی بیرونی دیده می‌شوند و هیچ‌یک در تخلیه جدول اصلی که بعد از واقعه گرفته شود دیده نمی‌شوند.
آنچه خروجی مسیریابی نمی‌تواند به شما بگوید
جستجوی درست یعنی هسته بسته را به جایی منطقی می‌فرستاد. این معنا را نمی‌دهد که فایروال اجازه می‌دهد، سیاست IPsec آن را پوشش می‌دهد، قاعده NAT آن را ترجمه می‌کند یا طرف دور مسیر بازگشت دارد. هر یک از این‌ها مرحله بعدی است، و یادداشت‌های strongSwan درباره هدایت زنجیره‌ای را توصیف می‌کنند که بسته باید در هر دو سر از آن بگذرد.
همچنین اتصال در سطح برنامه را در نظر نمی‌گیرد. یک فرایند می‌تواند به یک رابط مقید شود، نشانه‌ای تنظیم کند یا از حل‌کننده خودش استفاده کند و با نامی وصل شود که متفاوت از آنچه آزمایش کردید حل می‌شود. وقتی جستجو درست است و اتصال همچنان شکست می‌خورد، پرسش بعدی این است که کدام فرایند آن را می‌سازد و آیا آن فرایند همان جدولی را می‌بیند که شما می‌بینید.
پس تشخیص را منظم نگه دارید: مقصد و منبع را نام ببرید، جستجو را اجرا کنید، فقط جدول و قاعده‌ای را بخوانید که جستجو نام برد، سپس مرحله بعد را آزمایش کنید. این توالی تحقیق مسیریابی را در چند دقیقه نگه می‌دارد و سندی باقی می‌گذارد که دیگری می‌تواند دنبال کند، چیزی که جدول چسبانده‌شده هرگز انجام نمی‌دهد.