کدام پرش NAT نگاشت VPN بی‌کار را می‌اندازد و چگونه آن را تشخیص دهیم
جریان VPN بی‌کار می‌تواند در هر پرش دارای وضعیت بمیرد. یک آزمون را تکرار کنید، آنچه هر مرز دید را مقایسه کنید و به‌جای مقصر حدسی، نتیجه محدود را گزارش کنید.
پس از دوره‌ای آرام، تونل دوباره وصل می‌شود، هیچ گزارشی مقصر را نام نمی‌برد، و اقدام واضح انتخاب دستگاهی است که مستندترین توضیح درباره مهلت زمانی را دارد. این حدسی است که لباس تشخیص پوشیده است. وضعیت می‌تواند مدتی در یک روتر خانگی، در مترجم اپراتور و در لبه ابر دوام بیاورد، و هر یک از آن‌ها می‌تواند جریانی را که خاموش می‌شود بیندازد. کاری که به‌جایش می‌توانید بکنید این است که مسیر را نگاشت کنید، مشخص کنید کدام دستگاه‌ها را واقعاً می‌توانید مشاهده کنید، و یک آزمون بی‌کاری اجرا کنید که بتوانید تکرارش کنید.
آزمون تکرارپذیر یک حکایت را به اندازه‌گیری تبدیل می‌کند. همه چیز در ادامه یک کلاینت، یک سرور و یک پروتکل را فرض می‌کند و فرض می‌کند که در برابر تغییر دو متغیر هم‌زمان مقاومت می‌کنید. نکته این است که رخداد بعدی از این یکی ارزان‌تر شود.
هر بار همان آزمون بی‌کاری را اجرا کنید
بنویسید جریان آخرین بار چه زمانی سالم بود، پس از آن چه مدت بی‌کار ماند، و آیا یک بسته تازه آن را برگرداند. این سه واقعیت همان اندازه‌گیری است؛ بدون آن‌ها فقط داستانی درباره لپ‌تاپی دارید که از کار افتاد. در هر تکرار همان کلاینت، همان سرور و همان پروتکل را به کار ببرید و لحظه‌ای را که نخستین بسته پس از سکوت فرستاده شد ثبت کنید.
سپس مقایسه کنید که هر مرزی که در اختیار دارید واقعاً چه دید. تمایزی که تحقیق را تعیین می‌کند این است که آیا سرور پس از توقف هیچ چیز ندید، یا درخواست را دید و در مسیری پاسخ داد که دیگر پاسخ‌ها را حمل نمی‌کرد.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
مقایسه مسیرها بدون تغییر پنج چیز
شبکه دسترسی دومِ تأییدشده مقایسه‌ای مشروع است، چون زنجیره NAT تفاوت دارد. در ارائه‌دهنده، شرایط رادیویی و شاید خانواده نشانی هم تفاوت دارد، پس نتیجه یک مرز است نه یک اسناد. محدودیت‌ها را همراه با نتیجه ثبت کنید، نه اینکه هنگام گزارش بی‌صدا رهایشان کنید. مسیر را هم همان‌جا بنویسید: دستگاه، نقش، و اینکه آیا اصلاً می‌توان وضعیتش را خواند.
آنچه مقایسه مسیرها برایتان می‌خرد یک پرسش محدود است: جریان روی یکی زنده می‌ماند و روی دیگری پس از سکوتی مشابه می‌میرد، پس متغیر جایی در بخش‌های متفاوت است. این نتیجه‌ای واقعی است حتی وقتی هیچ دستگاهی نام برده نمی‌شود، و به مهندس بعدی می‌گوید یک بعدازظهر را کجا بگذراند و کجا نه.
خواندن وضعیت محلی پیش از گمانه‌زنی درباره اپراتورها می‌ارزد. روی یک دروازه Linux، conntrack -L جریان‌های ردیابی‌شده را با عمر باقی‌مانده‌شان فهرست می‌کند، که حدس درباره یک زمان‌سنج را به عددی تبدیل می‌کند که می‌توانید ببینید منقضی می‌شود. آن را پیش و پس از دوره بی‌کاری بخوانید، نه فقط پس از آن.
یک سیگنال نگه‌داشتن چه چیزی را نگه می‌دارد و چه چیزی را نه
سیگنال نگه‌داشتنِ پشتیبانی‌شده یک نگاشت را باز نگه می‌دارد، و باز نگه داشتن نگاشت هیچ چیزی درباره سرویس پشت آن اثبات نمی‌کند. ممکن است تونل نگاشت‌شده بماند در حالی که برنامه‌ای که حمل می‌کند پاسخ‌دادن را متوقف کرده، و از دید یک چراغ وضعیت این دو وضعیت یکسان به نظر می‌رسند. با سیگنال نگه‌داشتن مانند بیمه‌ای در برابر انقضای بی‌کاری رفتار کنید، نه مانند یک بررسی سلامت.
فاصله را بر پایه کوتاه‌ترین مهلتی تنظیم کنید که واقعاً اندازه گرفته‌اید، نه عددی که از یک انجمن کپی شده است. سیگنال نگه‌داشتنی که زیر هر زمان‌سنج محتملی تنظیم شده باشد ترافیکی است که هیچ‌کس لازم نداشت، و همچنین علامتی را از میان می‌برد که به شما می‌گفت کدام مرز اول منقضی می‌شود. فاصله را از عدد اندازه‌گیری‌شده انتخاب کنید و بقیه چیزها را به حال خود بگذارید.
یک تغییر، سپس دوباره اندازه بگیرید
در برابر وسوسه بالا بردن هر مهلت و تخلیه هر دروازه در طول یک آزمون زنده مقاومت کنید. این کار شواهدی را که برایش آمده‌اید پاک می‌کند و جریان‌های دیگران را قطع می‌کند، که معامله بدی برای فرضیه‌ای است که آزمایشش نکرده‌اید. یک تنظیم پشتیبانی‌شده را روی یک دستگاه تغییر دهید، سپس دوره بی‌کاری و بازیابی برنامه را تکرار کنید.
ثبت کنید کدام مشاهده مرزی جابه‌جا شد، و حتی وقتی چیزی بهتر نشد آن را ثبت کنید. تنظیمی که چیزی را درست نکرد اطلاعات است، و توجه کردن به آن یک بار ارزان‌تر از چرخاندنش روی کل مجموعه است.
نوشتن یافته‌ای که می‌توانید از آن دفاع کنید
وقتی مترجمی در بالادست قابل بررسی نیست، فقط آنچه شواهد پشتیبانی می‌کند را بگویید: تبادل جایی در همین بخش مسیر پس از این مقدار سکوت می‌میرد، و پرش مسئول بدون اسناد می‌ماند. گزاره محدود از بازبینی جان سالم به در می‌برد و نفر بعدی را به بخش درست راهنمایی می‌کند. نام بردن یک روتر پنهان به‌عنوان علت هیچ‌یک از این دو کار را نمی‌کند. یافته محدود را همراه با فاصله به کسی بدهید که بخش غیرقابل‌مشاهده را در اختیار دارد.
RFC 4787 توضیح می‌دهد چرا استنباط زمان‌سنج‌های نگاشت UDP از یک نقطه پایانی دشوار است، و همین دشواری دلیل آن است که یافته محدود صادقانه است. زمان‌سنج‌ها واقعی‌اند، و عدم‌قطعیت پیرامونشان هم.