بستههای تکراری IKE: انتقال گمشده را پیدا کنید
درخواست تکراری IKE یک رویداد زمانسنج است، نه تشخیص. یک زنجیره شواهد از آغازگر تا پاسخ بسازید، با شناسههای نسخه درست.
گزارش همان درخواست IKE را دو بار نشان میدهد، کسی به uplink موبایل اشاره میکند و تیکت با یک حدس بسته میشود. همان حدس، افسانه است: بسته تکراری یک مشاهده درباره یک تبادل است، نه تشخیص یک پیوند. ارسال مجدد رفتار طبیعی با قواعد خودش است و هر زمان پاسخ کند باشد در مسیرهای سالم ظاهر میشود. پیش از متهم کردن یک رابط، پاسخ را دنبال کنید.
افسانه: درخواست تکراری اثبات افت در یک پیوند است
دو چیز متفاوت تکرار ایجاد میکنند و هیچکدام مقصر را نام نمیبرد. درخواستدهنده ممکن است چون پاسخی نگرفته درخواست را تکرار کند، یا نقطه ضبط ممکن است بهخاطر جای اتصالش به پشته همان بسته را دو بار نشان دهد. شاخهای که ورود و خروج را روی همان میزبان میبیند با خوشحالی یک بسته را دو تا ثبت میکند، و اپراتوری که آن گزارش را میخواند بدون شناسههای تبادل راهی برای تشخیص تفاوت ندارد. تا وقتی نتوانید بگویید کدامیک از آن دو را در دست دارید، تکرار را یک رویداد زمانسنج بدانید.
دو uplink ابهام را بدتر میکنند نه بهتر. یک خط گزارش یک رابط را نام میبرد، در حالی که پاسخ ممکن است از دیگری خارج شده باشد، پس رابط در پیام توصیف میکند بسته کجا دیده شده و نه شکل گفتگو. به همین دلیل نخستین پرسش این است که به کدام تبادل نگاه میکنید، نه اینکه کدام پیوند معیوب است.
ارسال مجدد در واقع چه چیزی به شما میگوید
در IKEv2، ارسال مجدد اینگونه کار میکند: درخواستدهنده وقتی پاسخی نرسیده درخواست را تکرار میکند، و پاسخدهنده میتواند پاسخ ذخیرهشدهاش را دوباره بفرستد بهجای اینکه پاسخ تازهای محاسبه کند. شناسههای پیام به همان تبادل تعلق دارند و همین است که درخواست تکراری با شناسه یکسان را بهعنوان کارکرد پروتکل و نه تلاش تازه میشناساند. تلاش اولیه اغلب برای تطبیق به چیزی بیش از یک نشانی مبدأ یا SPI آغازگر نیاز دارد، پس سابقه تبادل خود پلتفرم از فهرست بستهها بهتر است. IKEv1 قواعد متفاوتی با شناسههای متفاوت دارد و هشدار فروشنده درباره تکرار نخستین بسته در همه نسخهها یک معنا ندارد.
پس برچسب زمان ارسال مجدد به شما میگوید یک زمانسنج منقضی شده است. نمیگوید کدام گام کند بوده، و قطعاً نمیگوید که اپراتور مقصر است. اینها ادعاهای جداگانهاند و فقط دومی در یک تیکت به کار میآید.
پیامد عملی این است که پیش از نتیجهگیری، تبادل را ثبت کنید. نشانی دریافت محلی، مسیر پاسخی که سیاست انتخاب کرده، چندتایی همتا و شناسههای تبادل را در یک جا یادداشت کنید، چون هر یک از آنها هنگام خواندن سابقه در آینده به پرسش متفاوتی پاسخ میدهد.
چهار نقطه مشاهده بهعنوان یک زنجیره
تبادل را چهار حلقه از یک زنجیره ببینید، نه چهار جای جداگانه برای نگاه کردن. هر حلقه شاهد نگه میدارد یا ناشناخته میماند، و زنجیره تنها به اندازه ضعیفترین حلقه ثبتشدهاش آگاهیبخش است. جدول زیر فهرست است: هر موقعیت چه چیزی را میتواند اثبات کند و چه چیزی را دستنخورده میگذارد.
| موقعیت | شاهدی که میتواند بدهد | چه چیزی را باز میگذارد |
|---|---|---|
| آغازگر میفرستد | درخواستی این میزبان را ترک کرد | اینکه به همتا رسید یا نه |
| پاسخدهنده دریافت میکند | درخواست رسید | اینکه پاسخی تولید شد یا نه |
| پاسخدهنده میفرستد | پاسخی دروازه را ترک کرد | اینکه مسیر موردنظر را دنبال کرد یا نه |
| آغازگر دریافت میکند | تبادل کامل شد | اینکه سیاست نتیجه را پذیرفت یا نه |
زنجیره را فقط جایی پر کنید که دسترسی دارید و بقیه را بهجای استنتاج، ناشناخته علامت بزنید. قلابی که بستهها را روی یک ماشین ثبت میکند چیزی درباره آنچه ماشین دور دریافت کرده نمیگوید، و خط گزارشی که ثبت میکند درخواستی دیده شده، شاهدی بر این نیست که هرگز پاسخی خارج شده است. شکافهای صادقانه از سابقهای که کامل به نظر میرسد و از حدس ساخته شده سودمندترند.
نخستین انتقال گمشده را پیدا کنید
زنجیره را از آغازگر به بیرون بپیمایید و در نخستین حلقه بیشاهد بایستید. اگر دروازه هرگز درخواست را ثبت نکند، نقص در مسیر پیش از آن است. وقتی دروازه همان درخواست را بارها ثبت میکند در حالی که کارخواه هرگز پاسخی ثبت نمیکند، جهت بازگشت مشکوک است: نشانی مبدأ، ترجمه و پالایش در هر مرزی که کنترل میکنید. اگر پاسخ برسد و کارخواه همچنان پیش نرود، پرسش از حملونقل خارج شده و به سیاست یا وضعیت تبدیل شده است.
هنگام مقایسه، همتا و پروتکل را ثابت نگه دارید و به یاد داشته باشید که تأخیر، افت، سیاست و وضعیت هر یک خط زمانی متفاوتی میسازند. شبکه موبایل بهطور خودکار علت نیست، و خط ثابت هم بهطور خودکار برای هر نیاز بهاندازه کافی قابلاعتماد نیست. تا زمانی که تبادل زنده است هر دو جهت را ضبط کنید:
tcpdump -ni any -vv 'udp port 500 or udp port 4500'
وقتی دسترسی پیش از انتهای دور قطع میشود، سابقه اگر بگوید کجا قطع میشود هنوز کمک میکند. ضبط فقط روی آغازگر میتواند نشان دهد درخواستی خارج میشود و پاسخی نمیرسد، که نقص را به هر چیزی پس از آن قلاب محدود میکند بدون اینکه ادعا کند میداند کدام گام آن را انداخته است. حلقههای دور را ناشناخته علامت بزنید و بگذارید نفر بعدی که دسترسی دارد آنها را پر کند. نوشتن به این شکل سابقه را صادق و همچنان کوتاه نگه میدارد.
پیش از تغییر هر چیزی مقایسه کنید. تکرار همان درخواست به همان همتا با همان پروتکل متغیرها را قابلشمارش نگه میدارد، در حالی که بازنشانی، تازهسازی کلید یا ویرایش سیاست میان دو ضبط مقایسه را نابود میکند. اگر تغییر ناگزیر است، بیدرنگ پس از آن دوباره ضبط کنید تا پیش و پس همچنان همان تبادل را توصیف کنند.
یک گزارش سودمند چه میگوید
گزارشی که ارزش اقدام دارد یک درخواست را با پاسخش جفت میکند و نخستین گامی را نام میبرد که پشتش شاهدی نیست. آن جمله خواندهشدن بهدست مهندسی که یک هفته بعد آنجا نبوده را تحمل میکند و به نفر بعدی نقطه شروعی میدهد، نه یک مظنون.
هرگز بررسیهای هویت را سست نکنید و مجموعه پروتکل مجاز را فقط برای آزمودن یک نظریه ارسال مجدد گسترده نکنید. بستهها و رکوردهای رویداد اصلی را پیش از هر بازنشانی ذخیره کنید، چون بازنشانی دقیقاً همان موادی را نابود میکند که در آستانه جمعآوریشان بودید و زمانبندیای را پاک میکند که نشان میداد تبادل کجا متوقف شده است.
افسانه این است که یک تکرار ثابت میکند اپراتور مقصر است. واقعیت این است که یک تکرار ثابت میکند یک زمانسنج منقضی شده، و پاسخ در مسیر پاسخ زنده است.