چرا مسیرهای هم‌هزینه یافتن خطاهای VPN را دشوار می‌کنند
وقتی چند تونل هزینه یکسانی دارند، هر جریان می‌تواند یکی دیگر را انتخاب کند. یک ping موفق هیچ چیزی درباره مسیری که برنامه شما واقعاً استفاده می‌کند نمی‌گوید.
کاربری گزارش می‌دهد که برنامه داخلی از یک ماشین کار می‌کند و از ماشین دیگر شکست می‌خورد، در حالی که pingی که از دروازه اجرا می‌کنید در هر دو حالت موفق است. با چند تونل هم‌هزینه، این تناقض نیست. هر جریان روی گام بعدی خود قرار می‌گیرد، بنابراین بررسی شما و نشست کاربر ممکن است صرفاً مسیرهای متفاوتی را به کار ببرند. راهنمای زیر این انتخاب را پیش از هر تغییری بازتولید می‌کند.
یک ping، چند مسیر ممکن
وقتی یک مسیر بیش از یک گام بعدی با هزینه یکسان دارد، مسیریاب باید برای هر بسته یکی را انتخاب کند. بیشتر پیاده‌سازی‌ها فیلدهای بسته را هش می‌کنند، معمولاً نشانی مبدأ و مقصد همراه با پروتکل و پورت‌ها، تا پاسخ‌ها روی همان مسیر بمانند. برنامه‌های مختلف، یا حتی اتصال‌های مختلف یک برنامه، هش‌های متفاوتی تولید می‌کنند.
به همین دلیل یک تشخیص از دروازه چیز کمی را اثبات می‌کند. بررسی خود دروازه نشانی‌ها و پورت‌های خودش و در نتیجه هش خودش را دارد. ممکن است روی تونل سالم فرود بیاید در حالی که کاربر همچنان روی تونل خراب فرود می‌آید.
چگونه پلتفرم گام بعدی را انتخاب می‌کند
انتخاب را بازتولید کنید، نه حدس بزنید. از هسته بپرسید برای همان مبدأ و مقصدی که نشست ناموفق دارد کدام مسیر را به کار می‌برد. آن جست‌وجو فیلدهایی را در بر می‌گیرد که یک جست‌وجوی ساده مقصد نادیده می‌گیرد. آن را از یک کلاینت سالم هم اجرا کنید و دو پاسخ را مقایسه کنید:
ip route get 10.20.5.7 from 10.20.0.14نسخه‌های جدیدتر iproute2 پروتکل و پورت مقصد را هم می‌پذیرند، که وقتی هش آن‌ها را در بر می‌گیرد اهمیت دارد. آن خروجی را با همان جست‌وجو از یک کلاینت سالم مقایسه کنید؛ تفاوت همان شواهدی است که کم داشتید.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
جریان ناموفق را دنبال کنید، نه جدول مسیرها را
جدول مسیرها هر دو تونل را فهرست می‌کند و طبق تعریف درست به نظر می‌رسد. پرسش این است که هر تونل پس از انتخاب، با بسته چه می‌کند. بررسی کنید که هر دو همان پیشوندهای محافظت‌شده، همان اجازه ارسال و مسیر بازگشتی را داشته باشند که به همان کلاینت می‌رسد.
به دستگاه‌های حالت‌دار در میانه توجه کنید. اگر درخواستی از یک تونل خارج شود و پاسخ از تونل دیگر بازگردد، دیوار آتش یا NATی که هرگز جریان اصلی را ندیده آن را دور می‌ریزد. دو تونل هر دو ترافیک را درست ارسال می‌کنند و اتصال همچنان شکست می‌خورد.
MTU هر مسیر را هم بررسی کنید. مسیری با کپسوله‌سازی اضافی اندازه قابل‌استفاده را کوچک می‌کند و انتقالی که از یک تونل موفق می‌شود روی دیگری دقیقاً در همان اندازه‌ای متوقف می‌شود که تونل کوچک‌تر می‌شکند.
هر بار یک مسیر را مقایسه کنید
جایی که طراحی اجازه نگهداری می‌دهد، یک تونل را از سرویس خارج کنید و وظیفه کاربر را تکرار کنید. اگر خطا از میان رفت، مشکل به مسیر حذف‌شده تعلق دارد و گام بعدی مقایسه پیکربندی آن با همسایه‌اش است، نه بازبینی دوباره جدول مسیریابی.
برنامه واقعی را مقایسه کنید، نه pingهای تکراری. ثبت کنید که آیا خطا از یک گام بعدی مشخص، یک اندازه بسته یا گذاری پس از اتصال دوباره پیروی می‌کند، زیرا این سه الگو به تعمیرهای متفاوتی اشاره دارند.
در پایان بنویسید چرا مسیرها هم‌ارز شمرده می‌شوند و چگونه یک خطا باید یکی از آن‌ها را از سرویس خارج کند. چندمسیری فقط زمانی ایمن است که مسیرها واقعاً قابل تعویض باشند و این یک گزاره طراحی است که ارزش بررسی دارد، نه فرض کردن.