بازگشت عقب‌روی بازپخش OpenVPN در گزارش: خطی که چه چیزی را اثبات نمی‌کند

خط می‌گوید PID_ERR replay-window backtrack occurred، و همهٔ نتایج جستجو آن را بسته‌های دورریخته و تونلی خراب توضیح می‌دهند. در مسیر UDP مربوط به Community OpenVPN 2.6، آن پیام نوشته می‌شود در حالی که تابع دریافت هنوز تصمیم می‌گیرد با بسته چه کند. یک بیشینهٔ تازهٔ عقب‌روی را ثبت می‌کند، سپس همان تابع فاصله را با پنجره و وضعیت ثبت‌شده می‌سنجد، پیش از آنکه بپذیرد یا رد کند. خواندن برچسب گزارش به‌عنوان حکم همان اشتباهی است که این سیاهه برای پیشگیری از آن وجود دارد.

ایستگاه یک: مشخص کنید خط چیست

این یک تشخیص دربارهٔ فاصلهٔ توالی است، نه تصمیمی دربارهٔ یک اتصال. در پیاده‌سازی شناسهٔ بسته، در جایی که بیشینهٔ تازه‌مشاهده‌شدهٔ عقب‌روی یادداشت می‌شود، پدیدار می‌شود. آن نقطه پیش از شاخهٔ پذیرش یا رد قرار دارد، و به همین دلیل بسته‌ای که آن را برمی‌انگیزد هنوز می‌تواند تحویل شود.

تأیید کنید کدام میزبان آن را نوشته و با چه سطحی از جزئیات. سرور و کلاینت هر دو می‌توانند پیام‌های شناسهٔ بسته بفرستند، و پیام یک طرف چیزی دربارهٔ وضعیت دریافت طرف دیگر نمی‌گوید.

ایستگاه دو: نتیجهٔ آن بسته را بیابید

خطوط پس از تشخیص را بخوانید، نه فقط خود تشخیص را. همان تابع به بررسی‌های پنجره و تکرار ادامه می‌دهد، پس نتیجهٔ همان بستهٔ مشخص چند دستور بعد تعیین می‌شود و کاملاً ممکن است پذیرش باشد. گزیده‌ای از گزارش که به خط هولناک ختم می‌شود چیزی دربارهٔ نتیجه نمی‌گوید. پنجره‌ای پیرامون آن را جستجو کنید، نه خود خط را:

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

اگر گزارش در آن زمان هیچ ردی برای آن همتا نشان نمی‌دهد، دست از تلقی این خط به‌عنوان علت قطعی بردارید. به مسیر برنامه بروید، زیرا بیشتر گزارش‌های متصل اما بی‌ترافیک در واقع همان‌جا پایان می‌یابند.

ایستگاه سه: تصمیم بگیرید بازآرایی واقعی است یا نه

بازآرایی ویژگی مسیر است، و یک تشخیص تنها یک نمونه از آن است. در پنجره‌ای کوتاه پیام‌های تکراری برای همان همتا را بجویید و پیش از نتیجه‌گیری اینکه شبکه به‌شدت بازآرایی می‌کند، آن را با ثبت هر دو سر مقایسه کنید.

چند پیام در هنگام اتصال دوباره چیز غیرعادی نیست. جریان پیوسته در کنار مهلت‌های واقعی برنامه ارزش بررسی دارد، و این ترکیب دلیل است نه برچسب.

ایستگاه چهار: پارامترهای پنجره، و آنچه نیستند

replay-window اندازهٔ توالی و یک مقدار زمانی اختیاری می‌گیرد، پس گسترش آن دو تحمل متفاوت را همزمان تغییر می‌دهد. افزایش عدد بسته‌هایی را می‌پذیرد که دورتر از ترتیب‌اند؛ مقدار زمانی محدود می‌کند که یک بسته تا چه مدت هنوز در نظر گرفته شود. گسترش یک تغییر خط‌مشی با هزینهٔ امنیتی است، و نه رمز را تقویت می‌کند و نه تشخیص تکرار را غیرفعال می‌کند. دو تحمل با هم حرکت می‌کنند، چه بخواهید چه نخواهید.

یک بستهٔ احرازشدهٔ قدیمی هنوز می‌تواند تکرار ناخواسته باشد، و به همین دلیل گیرنده این بررسی‌ها را نگه می‌دارد. پذیرش بازآرایی بیشتر یعنی پذیرش بیشتر آن ریسک.

خاموش‌کردن هشدار با mute آنچه می‌بینید را تغییر می‌دهد، نه آنچه دیمن انجام می‌دهد. اگر هدف گزارشی آرام‌تر در رویدادی شناخته‌شده است، این یک انتخاب عملیاتی مشروع است؛ اگر هدف تعمیر تونل است، خاموش‌کردن شواهد را پنهان می‌کند.

mute 20
replay-window 64 15

تغییر انتقال بیرونی به TCP رفتار تحویل و بازیابی را تغییر می‌دهد و هزینه‌های مسدودسازی سر صف خود را می‌افزاید. این یک تصمیم طراحی است، نه نخستین واکنش به یک برچسب گزارش. نصب دوبارهٔ سرور بدتر است، زیرا تفاوت میان یک آماره و مرزی را که واقعاً شکست خورده محو می‌کند.

ایستگاه پنج: مسیری را بیازمایید که برای کاربر مهم است

با اتصال تونل، آزمون خود برنامه را اجرا کنید و مسیر انتخاب‌شده، وضعیت ارسال و مسیر بازگشت آن را بخوانید. تونلی که فقط در یک جهت بسته حمل می‌کند هیچ پیام عقب‌روی تولید نمی‌کند، و این بسیار رایج‌تر از بازآرایی شدید است.

بنویسید در هر ایستگاه چه اندازه‌گیری کردید. همین ثبت است که مانع می‌شود گزارش بعدی دوباره از خط هولناک آغاز شود و از آنجا به بیرون کار کند.

پیاده‌سازی شناسهٔ بسته ترتیب آماره و تصمیم را نشان می‌دهد، و راهنما گسترهٔ توالی و زمان پنجره را توصیف می‌کند. خواندن این دو با هم چیزی است که یک خط گزارش هولناک را به کمیتی شناخته‌شده تبدیل می‌کند. هیچ‌کدام دربارهٔ مسیر مشخص شما چیزی نمی‌گویند، و به همین دلیل اندازه‌گیری‌های بالا همچنان مهم‌اند.