تغییرمسیرهای ICMP در برابر مسیرهای VPN شما: واقعاً چه چیزی تغییر می‌کند
تغییرمسیر یک پیشنهاد از سوی روتر است، نه تغییر مسیر. اینکه میزبان از آن پیروی کند به خط‌مشی هر واسط بستگی دارد که میان IPv4 و IPv6 متفاوت است.
جریانی که باید از تونل بگذرد گام بعدی متفاوتی برمی‌گزیند و کسی یک تغییرمسیر ICMP در یک ضبط پیدا می‌کند. این یک فرضیه است، نه تشخیص. تغییرمسیر پیشنهاد روتر درباره گام بعدی بهتر است و اینکه میزبان بر اساس آن عمل کند به تنظیماتی بستگی دارد که بر پایه سکو، واسط و خانواده نشانی فرق می‌کند.
تغییرمسیر پیشنهادی از سوی روتر است
تغییرمسیرهای ICMP در IPv4 نوع پیام خودشان و مجموعه تنگی از شرایط را دارند: روتر بسته را از همان واسطی که وارد شده بود به بیرون می‌فرستد و گام بعدی‌ای روی همان پیوند می‌شناسد که به مقصد نزدیک‌تر است. سپس به فرستنده می‌گوید همان گام بعدی را مستقیم به کار ببرد. پیام دروازه جدید را نام می‌برد و بخشی از بسته اصلی را دربر دارد تا فرستنده بتواند آن را با یک جریان تطبیق دهد. این پیامی محترمانه درباره توپولوژی محلی است و فرض می‌کند فرستنده پیوندی با دروازه پیشنهادی مشترک دارد.
فرستنده آزاد است آن را نادیده بگیرد. هیچ چیز در پروتکل ایجاب نمی‌کند که میزبان جدول خود را عوض کند و یک تغییرمسیر ضبط‌شده فقط اثبات می‌کند که روتری آن را فرستاده است.
همین تمایز جایی است که بیشتر بررسی‌های تغییرمسیر به بیراهه می‌رود.
IPv4 و IPv6 آن را متفاوت تحویل می‌دهند
IPv6 سازوکار مشابهی درون کشف همسایه دارد نه در ICMPv4، با قالب‌های پیام و قواعد اعتبارسنجی متفاوت. مفاهیم هم‌قافیه‌اند و بسته‌ها نه. یک فیلتر ضبط که برای نوع 5 ICMP نوشته شده باشد در شبکه IPv6 چیزی نشان نمی‌دهد و این گاهی به‌عنوان مدرکی خوانده می‌شود که هیچ تغییرمسیری رخ نداده است.
کلیدهای خط‌مشی هم جدا هستند، پس میزبان می‌تواند تغییرمسیرهای IPv4 را بپذیرد و IPv6 را نادیده بگیرد، یا برعکس.
اگر جریان مورد نطر می‌تواند از هر یک از این دو استفاده کند، هر دو خانواده را بررسی کنید.
پذیرش خط‌مشی میزبان است، نه واقعیت شبکه
در لینوکس پذیرش تغییرمسیر هم به‌ازای هر واسط و هم به‌صورت کلی کنترل می‌شود و مقادیر پیش‌فرض میان نقش میزبان و روتر فرق می‌کند. واسط تونلی که تغییرمسیر را می‌پذیرد طراحی عجیبی است، چون درون یک تونل نقطه‌به‌نقطه گام بعدی جایگزین معناداری روی همان پیوند وجود ندارد. همین باعث می‌شود خواندن این تنظیم ارزش داشته باشد، نه فرض کردن آن.
تنظیمات تغییرمسیر امن بیشتر محدود می‌کند که به کدام دروازه‌ها می‌توان باور داشت.
اگر میزبانی را سخت‌گیرتر می‌کنید، این‌ها همان کلیدهایی هستند که باید مرور شوند و همین دلیل آن است که دو ماشین در یک شبکه می‌توانند رفتار متفاوت داشته باشند. آن‌ها را به‌عنوان خط‌مشی تغییر دهید، نه میان‌بر اشکال‌زدایی.
چیزی که تغییرمسیر نمی‌تواند توضیح دهد
مسیرهای مشخص، قواعد مسیریابی خط‌مشی و واسط‌های محلی بیشتر مسیرهای غیرمنتظره را بدون هیچ تغییرمسیری توضیح می‌دهند. یک پیشوند مشخص‌تر، قاعده‌ای که با نشانی مبدأ می‌خواند، یا یک پیش‌فرض دوم در جدولی دیگر هر یک بر مسیری که انتظار داشتید چیره خواهد شد. نخست همان‌ها را بررسی کنید، چون قطعی و دیدنی‌اند.
ضبط‌های کهنه تله دیگرند، چون کارخواهی که شبکه‌اش را عوض کرده دروازه محلی دیگری دارد.
یک تغییرمسیر قدیمی از اتصال پیشین هیچ چیز درباره مسیر کنونی توضیح نمی‌دهد، پس ثبت کنید کدام واسط اکنون ترافیک کنترل را می‌گیرد.
پیش از سرزنش تونل، مسیر را بررسی کنید
از هسته بپرسید برای مقصد از کدام مسیر استفاده می‌کند، سپس آن را با جدولی که در نظر داشتید بسنجید. اگر پاسخ با جدول بخواند، هیچ تغییرمسیری چیزی را عوض نکرده و بررسی جای دیگری است. اگر نخواند، پیش از فرض خطاکار بودن تونل، به دنبال تغییرمسیر ذخیره‌شده، قاعده خط‌مشی یا جدول دومی بگردید. جست‌وجو حقیقت پایه است و هر چیز دیگر داستانی است درباره اینکه چطور به آنجا رسید.
تغییرمسیر هرگز نباید دلیلی باشد که مسیری محافظت‌شده بی‌صدا به مسیری بی‌محافظت تبدیل شود، و همین است که خط‌مشی پذیرش را به بازبینی طراحی می‌آورد. تعریف RFC 792 همچنان مرجع این است که پیام IPv4 اجازه دارد چه بگوید.
جست‌وجوی مسیر و مهر زمانی ضبط را با هم بنویسید تا نفر بعد بتواند نتیجه شما را بازتولید کند.