اكتب موجز تصميم 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الموجز الذي يمر بكل الفحوص الستة ينتج سؤالاً له جواب: التصميم يلبي المسارات المذكورة وعقد الفشل، أو يمنعه قيد مسمّى. عندما يتغير القيد لاحقاً، يُظهر السجل أي قرار يجب إعادة النظر فيه وأيها يمكن أن يبقى. ذلك ما يجعل التمرين قابلاً لإعادة الاستخدام بدل أن يكون جدالاً لمرة واحدة.