ویرایش یک گزارش VPN بدون از دست دادن سرنخهای مهم
هر چیز قابل استفاده را حذف کنید، برای هر مقدار واقعی یک برچسب نگه دارید و ترتیب و نسخهها را حفظ کنید. گزارش ویرایششده باید همچنان به یک غریبه اجازه دهد خرابی را دنبال کند.
گزارشی را در یک رشته پشتیبانی میچسبانید، پاسخی اشاره میکند که کلید خصوصی شما را دارد، و چسباندن دائمی است. خرابی آرامتر بعداً آشکار میشود، وقتی هر نشانی به X تبدیل شده و فایل دیگر ثابت نمیکند که کلاینت و سرور میزبانهای متفاوتی بودند. یک گذر ویرایش آنچه دسترسی میدهد یا شخصی را نام میبرد حذف میکند و آنچه خرابی را توضیح میدهد نگه میدارد. این تبدیلی با قاعده است، نه حذفی با کادر جستجو.
ویرایش یک تبدیل است، نه حذف
گزارش هم ساختار دارد و هم مقدار: این نشانی در این زمان با آن یکی صحبت کرد، و دستدادن در این گام متوقف شد. مقدارها همان چیزی هستند که فایل را برای انتشار خطرناک میکنند. ساختار همان چیزی است که آن را اصلاً شایسته انتشار میکند.
حذف کل خطوط هر دو را یکجا برمیدارد، و به همین دلیل گزارش کوتاهشده غالباً به هیچ چیز پاسخ نمیدهد. فشرده کردن هر مقدار در یک توکن به شکلی دیگر شکست میخورد، چون دو همتا متمایز به یک کنشگر واحد تبدیل میشوند. هر دو گذر میتوانند مرتب به نظر برسند و با این حال مدرک را نابود کنند. آزمون این است که آیا خوانندهای که هرگز شبکه شما را ندیده میتواند توالی را دنبال کند و به همان نتیجهای برسد که شما رسیدید.
اول گزیده، بعد پاکسازی
بخش پیرامون خرابی را قبل از ویرایش هر چیز ببرید. گزیده کوچکتر آسانتر بررسی میشود و کمتر احتمال دارد چیزی را حمل کند که فراموش کرده بودید در فایل است. نسخه اصلی دستنخورده را تا بسته شدن موضوع در انبار محافظتشده نگه دارید. ویرایش توأم با از دست رفتن است، و فایل خام تنها راه پاسخ به پرسش بعدی است.
گزیده را بهعنوان متن ساده بخوانید پیش از آنکه به یک فرمان برونریزی اعتماد کنید که بخشهای خصوصی را برداشته است، چون برونریزها بهجای پاکسازی، فیلدها را خلاصه و جابهجا میکنند. حالتهای debug و verbose محتملترین جای یک بلوک کلید یا اعتبارنامه درونخطی هستند. فایل را در ویرایشگری باز کنید که خطوط کامل را نشان میدهد، نه در نمایشگری که میپیچد و انتها را پنهان میکند.
چه چیزی باید برود، و به چه ترتیبی
با موادی شروع کنید که دسترسی میدهد، چون یک از قلم افتادن در اینجا تمرین را پایان میدهد: بلوکهای کلید خصوصی، گذرواژهها، کلیدهای از پیش مشترک، توکنهای API، کدهای بازیابی. اینها فقط شناساییکننده نیستند؛ هر کسی که رشته را بخواند میتواند از آنها استفاده کند. گذری که همه چیز دیگر را حذف کند و یکی از اینها را بگذارد شکست خورده است.
سپس لایه هویت: نامهای کاربری، موضوع و شماره سریال گواهیها، شناسههای حساب، و هر مسیری که نام یک شخص را دارد. هیچیک بهتنهایی قابل استفاده نیست، اما با هم شخصی را نام میبرد، و این همان بخشی است که یک رشته عمومی به آن نیاز ندارد.
سپس لایه توپولوژی، و اینجاست که داوری وارد میشود. نشانیهای عمومی، بازههای داخلی و نام میزبانها همه وقتی افشای آنها هیچ هدف تشخیصی را برآورده نمیکند قابل جایگزینی هستند، و برچسبهای پایدار بهتر از جای خالیاند. ترتیب مهم است چون لایههای پیشین مطلقاند و لایه آخر یک تصمیم است. کار با این ترتیب همچنین مانع میشود ساعتی را صرف نام میزبانها کنید در حالی که یک بلوک کلید در خط چهلم است.
| Original kind | Replace with | Keep |
|---|---|---|
| Client address | CLIENT_A | Which side initiated |
| Server address | SERVER_B | Port and protocol |
| Username | USER_1 | The failure that mentions it |
| Hostname | HOST_1 | Resolution order |
روابط را نابود نکنید
به هر مقدار واقعی یک نگهدارنده بدهید و هر بار که آن مقدار ظاهر میشود دوباره از آن استفاده کنید. اگر دو نشانی متفاوت بودند، باید پس از گذر هم متفاوت بمانند، وگرنه خواننده نتیجه میگیرد که کلاینت به خودش متصل شده است. سازگاری تمام سازوکار است: خواننده نگاشت را با دیدن برچسبی که تکرار میشود میآموزد. یک توکن دوبارهاستفادهشده برای دو کنشگر سریعترین راه برای ناخوانا کردن گزارش است.
ترتیب و زمان بخشی از همان ساختارند. توالی را دستنخورده نگه دارید، و اگر مُهرهای زمانی را جابهجا میکنید، همه را به یک اندازه جابهجا کنید و آن را در یک خط بگویید. آمیختن زمانهای تغییریافته و واقعی بدتر از حذف آنهاست، چون آنگاه شکافها مانند مدرکی برای چیزی به نظر میرسند که هرگز رخ نداده است.
درگاهها، پروتکل و جهت همانگونه که هستند میمانند. نگهدارنده در نشانی به نگهدارنده در درگاه نیاز ندارد.
پرسشی را که گزارش باید پاسخ دهد نگه دارید
فیلدهایی را که یک کمککننده لازم دارد پیش از شروع ویرایش بنویسید: متن دقیق و غیرمحرمانه خطا، نسخههای کلاینت و سرور، انتقال، و اینکه کدام طرف تلاش را آغاز کرد. همینها به یک غریبه امکان میدهد خرابی را بازشناسد. نگه داشتن فهرست در کنارتان گذر را به یک بررسی تبدیل میکند نه یک امید.
وقتی فایل را میفرستید، یک خط اضافه کنید که میگوید چه چیزی جایگزین شده، تا کسی ساعتی را صرف عیبیابی یک نام میزبان نگهدارنده نکند. مستندات OpenVPN درباره گزارشهای تشخیصی فیلدهایی را که گزارشهایش حمل میکنند فهرست میکند، و همان فهرستی است که در حال تغییر آن هستید. پیش از فرستادن یک دامپ حافظه یا ضبط بسته بپرسید، و از کانال پشتیبانی که میتوانید بررسی کنید استفاده کنید. آن آثار بسیار بیشتر از گزارش متنی را در خود دارند، و بخشی از آن مال شما برای انتشار نیست.
گزیده نهایی را یک بار از خط اول تا آخر بخوانید، با احتساب آغاز و پایان. تصاویر صفحه بیش از متن سزاوار بیاعتمادیاند، چون پنجرهها، نام حسابها و آیتمهای منوی دیگری را حمل میکنند.