خلاصه طراحی VPN بنویسید که کسی واقعاً بتواند آن را مرور کند

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

نخست، آیا پرسش یک تصمیم است یا یک آرزو

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

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

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

دوم، جریان‌ها و ردها را نام ببرید

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

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

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

فهرست را به اندازه کافی کوتاه نگه دارید تا آزمون‌پذیر باشد. ده جریانی که می‌توانید بررسی کنید از چهل جریانی که نمی‌توانید بهتر است.

بررسی 3: واقعیت‌ها را از فرض‌ها جدا کنید

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

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

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

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

چهارم، قرارداد خطا را بنویسید

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

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

هدف بازیابی را به زبان ساده اضافه کنید، مانند اینکه یک سایت چه مدت می‌تواند در وضعیت تضعیف‌شده کار کند و چه کسی رخداد را اعلام می‌کند.

بررسی 5 و 6: درز را انتخاب کنید و تغییر را ثبت کنید

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

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

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

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