گزارش‌های محلی سیستم درباره یک اتصال VPN چه چیزی را نشان می‌دهند
سیستم‌عامل آغاز سرویس‌ها، تغییر آداپتورها و خطاهای مسیر را ثبت می‌کند که هیچ برنامه‌ای آن‌ها را نمی‌نویسد. یک بازه باریک را بخوانید و آن را به هم مرتبط کنید.
هر رایانه رومیزی دفترچه خودش را از آنچه یک VPN انجام داده نگه می‌دارد، و خروجی برنامه معمولاً ناقص‌ترین آن‌هاست. مدیران سرویس ثبت می‌کنند که یک واحد کِی آغاز شده، هسته ثبت می‌کند که یک واسط کِی پدیدار شده، و پشته شبکه ثبت می‌کند که مسیرها کِی اعمال نشده‌اند. هیچ‌یک از این سازوکارها نمی‌داند کارخواه چه قصدی داشت، و کارخواه هم نمی‌داند هسته با درخواستش چه کرد.
خواندن یک چنین دفترچه‌ای به‌تنهایی به نتیجه‌گیری نادرست دعوت می‌کند. دو تا را از همان دقیقه بخوانید، آن‌گاه توالی آشکار می‌شود.
سه سازوکار با سه واژگان
در Linux، ژورنال systemd پیام‌های چرخه عمر واحد را از wg-quick@wg0 یا افزونه VPN در NetworkManager می‌گیرد، و بافر حلقه‌ای هسته پیام‌های واسط و مسیریابی را حمل می‌کند. در Windows، گزارش رویداد داستان را میان ارائه‌دهندگان سامانه، WLAN و دسترسی راه دور تقسیم می‌کند، هرکدام با شناسه‌های خودش. در macOS، گزارش یکپارچه پیام‌های محدود به زیرسامانه را حمل می‌کند که Console گرافیکی فقط بخشی از آن را نشان می‌دهد.
واژگان‌ها ترجمه نمی‌شوند. شناسه رویداد یک سکو روی سکوی دیگر هیچ معنایی ندارد، و تصویر یک پنجره Windows درباره یک واحد Linux چیزی را اثبات نمی‌کند.
آنچه هر سه در آن شریک‌اند یک برچسب زمانی، یک منبع و یک سطح اهمیت است، و همین سه‌گانه همبستگی میان گزارش کارخواه و دفترچه سیستم‌عامل را ممکن می‌کند. دسترس‌پذیری هم متفاوت است: یک کانتینر بدون ژورنال، یک تصویر Windows کوتاه‌شده، یا سطح گزارش کاهش‌یافته هنگام ساخت می‌تواند یک لایه کامل را پنهان کند.
| Facility | What it records | What it cannot show |
|---|---|---|
| systemd journal | Unit start and stop, helper output, exit status | Whether packets actually reached the peer |
| Kernel and netlink | Interface creation, address assignment, route changes | Why the client asked for that configuration |
| Windows event log | Provider-specific connection and adapter events | Anything the provider chose not to log |
یک خط متصل چه چیزی را اثبات می‌کند و چه چیزی را نه
رویداد آغاز سرویس ثبت می‌کند که از واحد محلی خواسته شده آغاز شود و اینکه بی‌درنگ خارج نشده است. دست‌دادن کامل، کلید همتای معتبر یا مسیر کارآمد را ثبت نمی‌کند. تلقی کردن آن خط به‌عنوان اثبات تونل، رایج‌ترین بدخوانی این گزارش‌هاست. خط، نیت و وضعیت فرایند را اثبات می‌کند، و مطلقاً هیچ چیز درباره دسترس‌پذیری.
وضعیت ارسال، مشاهده‌ای جداگانه است و از جدول مسیریابی می‌آید نه از هیچ گزارشی.
رویداد آداپتور می‌تواند یک شکست خاموش را توضیح دهد: واسط بالا آمد، نشانی تخصیص یافت، و مسیرها هرگز نصب نشدند چون یک قاعده سیاست آن‌ها را رد کرد. در این توالی هر خط دیدنی سالم به نظر می‌رسد در حالی که هیچ چیز مسیریابی نمی‌شود، و تنها راه دیدنش مقایسه برچسب‌های زمانی گزارش با جدول مسیریابی در همان لحظه است. ترتیب رویدادهای خود کارخواه را کنار هر دو نگه دارید، چون کارخواه تنها منبعی است که می‌داند چه خواسته است. آن دو واقعیتی که با هم لازم دارید تقریباً هرگز روی یک خط نمی‌آیند.
اتصال دوباره بعدی بخش جالب این تصویر را بازنویسی می‌کند، پس بازه را در نخستین شکست ثبت کنید نه پس از سه تلاش.
یک بازه باریک را به هم مرتبط کنید
زمان تلاش را با منطقه زمانی‌اش ثبت کنید، سپس همان چند دقیقه پیرامونش را بیرون بکشید. نخستین خطا در بازه تقریباً همیشه مقدم بر خط قطع اتصالی است که بلیت‌های پشتیبانی نقل می‌کنند.
journalctl -u wg-quick@wg0 --since "today 09:00" --until "today 09:20" ip route show table all | grep wg0 log show --last 20m --predicate 'subsystem == "com.apple.network"'
هر فرمان به بخش متفاوتی از پرسش پاسخ می‌دهد: اولی چرخه عمر را می‌دهد، دومی وضعیت ارسال، سومی زیرسامانه شبکه macOS. در Windows گزارش سامانه را با نام ارائه‌دهنده پالایش کنید نه با پیمایش کل کانال، و فقط رویدادهای منطبق را برون‌بری کنید.
بریده را آن‌قدر کوچک نگه دارید که خواننده بتواند دنبالش کند. بازه‌ای بیست‌دقیقه‌ای با چهار رویداد مرتبط یک نتیجه را پشتیبانی می‌کند؛ برون‌بری یک روز کامل با هزاران خط هیچ چیز را پشتیبانی نمی‌کند.
این دفترچه‌ها کجا متوقف می‌شوند
دفترچه‌های محلی دستگاه را توصیف می‌کنند، نه مسیر را. نمی‌توانند نشان دهند ارائه‌دهنده چه ذخیره کرده، آیا نشستی به حسابی تطبیق داده شده، یا مقصدی چه دیده است. اظهار ارائه‌دهنده به اینکه گزارش نگه نمی‌دارد هیچ چیزی درباره سیستم‌عامل روی لپ‌تاپ شما نمی‌گوید، و یک رویداد محلی درباره دفترچه‌های تاریخی ارائه‌دهنده چیزی را اثبات نمی‌کند.
آن‌ها داده شخصی بیشتری از انتظار هم حمل می‌کنند: نام‌های کاربری، نام میزبان‌ها، مسیرهای سوارسازی و شناسه‌های دستگاه در پیام‌های عادی سامانه ظاهر می‌شوند حتی وقتی هیچ محتوای مرورگری وجود ندارد. پیش از پیوست کردن چیزی به یک بلیت آن‌ها را پاک کنید، و اصل را زیر کنترل‌های دسترسی معمول نگه دارید.
روی یک دستگاه مدیریت‌شده، بریده مربوط را از IT بخواهید به‌جای تلاش برای پاک کردن گزارش‌گیری سازمانی. هدف تشخیصی یک پرسش باریک است که دو منبع پاسخش را می‌دهند، نه تاریخ کامل دستگاه.