پینگ از دروازه IPsec از نشانی مبدأ متفاوتی استفاده میکند
پینگی که روی خود دروازه آغاز میشود مبدأ خودش را انتخاب میکند و این مبدأ سیاست و مسیر بازگشت را تغییر میدهد. آزمونی را انتخاب کنید که آنچه لازم دارید را اثبات کند.
از دروازه IPsec به سمت دور پینگ بزنید، پاسخی نگیرید و نتیجه بگیرید که تونل خراب است، در حالی که هر بار کاری پشت دروازه بهطور عادی ترافیک را عبور میدهد. این دو نتیجه متناقض نیستند. پینگی که روی دروازه آغاز میشود بستهای با مبدأ محلی است و دروازه نشانی مبدأ را از جدول مسیریابی خودش انتخاب میکند. این انتخاب میتواند با نشانیهایی که ترافیک واقعی سایت استفاده میکند متفاوت باشد، و همین تغییر میدهد کدام سیاست مطابقت دارد و کدام مسیر بازگشت اعمال میشود. پیش از هر برداشتی از نتیجه، تصمیم بگیرید آزمون باید چه چیزی را اثبات کند.
سه پرسش متفاوت که یک پینگ میتواند پاسخ دهد
پرسش اول این است که آیا سمت دور از این میزبان اصلاً قابل دسترسی است. پرسش دوم این است که آیا انتخابگرهای تونل یا سیاست مبتنی بر مسیر، ترافیک از یک مبدأ مشخص را میپذیرند. پرسش سوم این است که آیا ترافیک ارسالشده از یک بار کاری پشت دروازه، سرتاسر کار میکند. یک فرمان نمیتواند به هر سه پاسخ دهد، و نشانی مبدأ همان چیزی است که آنها را جدا میکند.
اول پرسش را انتخاب کنید. وگرنه پینگ ناموفق به شواهدی برای همان نظریهای تبدیل میشود که از قبل داشتید.
چرا دروازه نشانیای را انتخاب میکند که انتظارش را نداشتید
وقتی به مقصدی پینگ میزنید، پشته محلی مبدأ را از مسیری انتخاب میکند که با آن مطابقت دارد. در تونل مبتنی بر مسیر این میتواند نشانی پیوند واسط تونل باشد که در بسیاری از طراحیهای سایت جفت 169.254.x.x است که برای گام نقطهبهنقطه انتخاب شده است. این نشانیها برای کارکردن پیوند وجود دارند؛ در سمت دور بهعنوان شبکههای مبدأ برنامه اعلام نمیشوند.
بنابراین سمت دور ممکن است درخواست پژواک را از نشانیای دریافت کند که مسیر بازگشتی به آن ندارد، یا از نشانیای که هیچ انتخابگری با آن مطابقت ندارد. تونل میتواند سالم باشد و پینگ باز هم شکست بخورد، و این دقیقاً همان منفی کاذبی است که این مقاله درباره آن است.
مبدأ را عمداً انتخاب کنید
روی یک دروازه Linux کنترلشده، مبدأیی را انتخاب کنید که از قبل بهصورت محلی تخصیص یافته است: ping -c 4 -I 10.30.0.1 10.40.0.20. نشانیهای اینجا نمونهاند، پس نشانی داخلی واقعی دروازه و یک مقصد دور واقعی را جایگزین کنید و مطمئن شوید مبدأیی که انتخاب میکنید متعلق به این دستگاه است و سیاست سایت آن را میپذیرد.
نشانی یک بار کاری را برای آزمون قرض نگیرید. جعل هویت میزبانی که به دروازه تخصیص نیافته، نتیجهای میسازد که هیچکس نمیتواند بازتولید کند، و روی برخی پشتهها به شکلهایی شکست میخورد که شبیه خرابی تونل است.
مسیر بازگشت را بخوانید، نه فقط درخواست را
بررسی کنید کدام مبدأ واقعاً به مقصد دور میرسد، با احتساب هر ترجمه عمدی در مسیر. سپس مسیر بازگشت سمت دور به آن مبدأ و انتخابگرها یا سیاستی که آن را مجاز میکند بررسی کنید. درخواستی که با مبدأ غیرمنتظره میرسد پرسشی از مسیریابی و سیاست است، نه پرسشی رمزنگاری.
اینجاست که گرفتن بسته بیش از یک پینگ دیگر کمک میکند: مبدأیی را نشان میدهد که سمت دور دیده است، و همان نشانیای است که پاسخش باید به آن برسد.
سپس بار کاری را بیازمایید
آزمون قاطع یک پینگ از میزبان معمولی پشت دروازه به میزبان معمولی پشت دروازه دور است. این نقش ارسال دروازه، مبدأ واقعی برنامه و مسیر بازگشت واقعی را به کار میگیرد، و همان جریانی است که برای کاربران اهمیت دارد.
نتایج را در یادداشتهایتان جدا نگه دارید: دسترسی محلی از دروازه، پذیرش سیاست برای مبدأ انتخابشده، و ترافیک ارسالشده. پینگ سنجاقشده موفق شاهد مفیدی است که تونل چیزی را حمل میکند؛ اثبات این نیست که هر جریان ارسالشده کار میکند. و مبدأ دروازهای که بهطور خودکار انتخاب شده و قابل دسترسی نیست، اثبات اینکه تونل سایت قطع است نیست.
فقط برای گرفتن یک پاسخ تشخیصی، یک مسیر فراگیر برای 169.254.0.0/16 اضافه نکنید. این کار یک آزمون گمراهکننده را با یک تصمیم مسیریابی دائمی معاوضه میکند، و نفر بعدی آن را بدون زمینه به ارث میبرد.