سابقه VPN چه چیزی را درباره مرور می‌تواند اثبات کند و چه چیزی را نه
سوابق نشست، حل‌کننده، جریان و برنامه رویدادهای متفاوتی را اثبات می‌کنند. پیش از نامیدن آن به تاریخچه مرور، پرسش حسابرسی و پیوند هویت را انتخاب کنید.
پیش از انتخاب جمع‌آورنده سابقه، مشخص کنید حسابرسی کدام رویداد را باید اثبات کند. این پرسش که کدام نشست VPN با یک نشانی مقصد تماس گرفته است، با پرسش این که کدام شخص صفحه خاصی را باز کرده است تفاوت دارد. هر دو به سوابق متفاوت، پیوندهای متفاوت و سطوح اطمینان متفاوت نیاز دارند. سابقه اتصال OpenVPN به پرسش نخست پاسخ می‌دهد و نمی‌تواند به دومی پاسخ دهد.
پیش از انتخاب جمع‌آورنده، رویداد را نام بگذارید
سابقه نشست هویت پذیرفته‌شده، زمان آغاز و پایان و نشانی‌ای را نشان می‌دهد که سرور بر پایه سیاست خود تخصیص داده است. سابقه حل‌کننده نشان می‌دهد نامی در آن حل‌کننده پرسیده شده است. سابقه جریان نشانی‌ها، درگاه‌ها، پروتکل و زمان را نشان می‌دهد و سابقه برنامه تراکنشی را که آن برنامه واقعاً پردازش کرده است. هیچ‌یک از این چهار جای دیگری را نمی‌گیرد.
هر یک از آن‌ها یک رویداد را اثبات می‌کند و بقیه را باز می‌گذارد. نوشتن پرسش در ابتدا مانع می‌شود داستانی بسازید که داده‌ها از آن پشتیبانی نمی‌کنند.
journalctl -u [email protected] --since today | grep -i 'peer info\|assigned' cat /etc/openvpn/server/openvpn-status.log | head -20 conntrack -L -p tcp --dport 443 2>/dev/null | head -20
فرمان نخست رویدادهای نشست را از ژورنال سرویس نشان می‌دهد. دومی فهرست کنونی کارخواهان را با نشانی‌های تخصیص‌یافته چاپ می‌کند که همان نگاشتی است که پیوند حسابرسی به آن وابسته است. سومی وضعیت زنده جریان را نشان می‌دهد که تنها تا زمانی که اتصال وجود دارد سودمند است.
یک جست‌وجو بازدید نیست
مرورگر نام‌ها را گمانه‌زنانه حل می‌کند، پاسخ‌ها را در حافظه نهان نگه می‌دارد و بدون پرسش دوباره از حل‌کننده تحت نظارت، دوباره از آن‌ها استفاده می‌کند. بنابراین نامی در سابقه حل‌کننده جست‌وجو را اثبات می‌کند، نه بازدید را. DNS روی HTTPS این شکاف را گسترده‌تر می‌کند، زیرا مرورگری که برای آن پیکربندی شده پرسش‌هایش را جایی می‌فرستد که ثبت‌کننده معمولی شما هرگز آن را نمی‌بیند.
نشانی‌های مقصد به‌تنهایی بهتر نیستند. یک نشانی می‌تواند میزبان سایت‌های بی‌ارتباط بسیاری باشد، DNS معکوس گمان است نه بازسازی، و نام میزبان که در هنگام دست‌دادن TLS دیده می‌شود مسیر درخواست درون نشست رمزنگاری‌شده نیست.
برای تراکنش‌های دقیق به سوابق رویداد خود برنامه نیاز دارید یا به طراحی کارگزاری که به‌صراحت برای ثبت پشتیبانی می‌شود. تونل CONNECT مقصد و حجم را به کارگزار می‌دهد، نه مسیرهای صفحه درون آن را. دسترسی مدیریتی به شبکه مجوز جایگزینی خاموش مدل اعتماد برنامه نیست.
پیش از نام بردن یک شخص، هویت و زمان را پیوند دهید
سابقه جریان با نشانی منبع داخلی هیچ معنایی ندارد تا زمانی که آن نشانی در همان زمان به یک نشست پیوند داده شود. نشانی‌ها دوباره به کار می‌روند و همان نشانی ممکن است یک ساعت پیش به نشست دیگری تعلق داشته باشد. تخصیص ایستا یک راه برای نگه داشتن این پیوند است، نه تنها راه.
مرزهای ترجمه پیوند را بیشتر تضعیف می‌کنند. اگر چند دستگاه پیش از نقطه مشاهده شما از پیش یک نشانی منبع را شریک بوده‌اند، بهترین چیزی که می‌توانید شناسایی کنید نشست دروازه مشترک است و نه یک دستگاه. گواهی یا حسابی که چند نفر از آن استفاده می‌کنند همان اثر را دارد.
مناطق زمانی، منابع ساعت، نقاط مشاهده و هر گام ترجمه را ثبت کنید. سوابق ناقص می‌تواند یعنی یک ورودی جریان منقضی شده، حسگری دور زده شده یا سابقه برنامه‌ای خاموش بوده است. نبودن دلیل بر رخ نداده چیزی نیست.
سپس کمینه میدان‌ها، خوانندگان مجاز و دوره نگهداری برای هدف اعلام‌شده را تعریف کنید. همبستگی و انتساب نادرست مسائل طراحی‌اند نه اندیشه پسین، و فراداده‌ای که افراد را شناسایی می‌کند همان حمایتی را سزاوار است که نگاشت هویتی که به آن وابسته است.
حسابرسی را با فعالیتی که کنترل می‌کنید بیازمایید
ترافیک مجاز تولید کنید که نشست و برنامه آن را از پیش می‌دانید، سپس بررسی کنید هر سابقه واقعاً چه چیزی را ثبت کرده است. جست‌وجویی بدون بارگذاری صفحه انجام دهید، صفحه‌ای را از حافظه نهان بارگذاری کنید و اتصالی از طریق کارگزار باز کنید و ببینید کدام رویدادها پدیدار می‌شوند.
رویدادی را گزارش کنید که شواهد از آن پشتیبانی می‌کنند و بگویید چه چیزی را پوشش نمی‌دهد. سابقه فروتنی با گستره اعلام‌شده از بازبینی جان سالم به در می‌برد؛ تاریخچه مرور بلندپروازانه‌ای که از گمان‌ها ساخته شده باشد، نه.