درخواست پشتیبانی VPN خانگی به یک جریان نیاز دارد، نه یک انبوه پیکربندی

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

چرا درخواست پاسخ‌های بی‌فایده می‌گیرد

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

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

پیش از انتشار این سابقه را پر کنید

Goal: the one resource or operation that should work
Path: client -> access network -> VPN endpoint -> resource
Owners: who controls the client, the gateway and the resource
Software: product, version and protocol in use
Expected: what success would look like
Observed: exact non-secret error or response
Time and change: when it started and what changed
Control: one comparable operation that still works

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

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

مرحله خراب را نام ببرید، نه کل گزارش را

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

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

مشاهده و توضیح را جدا نگه دارید. «کلاینت پس از 30 ثانیه پایان مهلت دست‌دادن را گزارش می‌کند» یک مشاهده است؛ «فکر می‌کنم ارائه‌دهنده UDP را مسدود می‌کند» یک نظریه است. هر دو سودمندند، و مخلوط کردنشان یعنی کمک‌کننده نمی‌تواند بفهمد به کدام اعتماد کند. برچسبشان بزنید، و پاسخی که می‌گیرید به درست می‌پردازد.

آن را به مالکی بفرستید که می‌تواند اقدام کند

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

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

اسرار را بدون صاف کردن توپولوژی پنهان کنید

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

سپس رابطه‌هایی را که جریان را فهمیدنی می‌کنند نگه دارید. RFC 6973 گردآوری و همبستگی غیرضروری را از مسائل حریم خصوصی می‌داند، و همان اصل اینجا هم برقرار است: شواهدی را که گیرنده لازم دارد به اشتراک بگذارید، نه کل دستگاه را.

با یک پرسش پاسخ‌پذیر درباره ناهمخوانی مشاهده‌شده پایان دهید، مثلاً چرا کلاینت احراز هویت را کامل می‌کند و سپس هرگز مسیری نمی‌گیرد. پرسش مشخص پاسخ مشخص می‌گیرد، و سابقه‌ای که ساختید همان چیزی است که به کسی امکان می‌دهد بدون پرسیدن اسرار شما یکی بدهد.