कोहीले साँच्चै समीक्षा गर्न सक्ने 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

छ जाँच पार गर्ने ब्रिफले जवाफसहितको प्रश्न बनाउँछ: डिजाइनले भनिएका प्रवाह र असफलता सम्झौता पूरा गर्छ, वा नाम दिइएको बाधाले रोक्छ। बाधा पछि बदलिँदा, अभिलेखले कुन निर्णय फेरि हेर्नुपर्ने र कुन रहन सक्ने देखाउँछ। यसले अभ्यासलाई एकपटकको बहस होइन, पुनः प्रयोगयोग्य बनाउँछ।