VPN सूची: अभिप्रेत पहुँच, उत्पन्न कन्फिगरेसन, जीवित सत्रहरू
टनेलको नाम एउटा अवलोकन हो, सेवाको रेकर्ड होइन। केही फिर्ता लिनु अघि भाडावाल, तैनाथ कन्फिगरेसन र लेखा-प्रमाण जोड्नुहोस्।
हरेक टनेलको नाम सूचीको पंक्ति जस्तो देखिन्छ, जबसम्म तपाईं यो कसको हो भनेर सोध्नुहुन्न। नामले तपाईंलाई अहिले केही जोडिएको छ भनी बताउँछ; यसले सेवा कसको हो, उनीहरूलाई के पुग्ने अनुमति छ, वा टनेल बनाएको कन्फिगरेसन तपाईंले स्वीकृत गरेको हो कि होइन भन्न सक्दैन। फ्लीटको स्तरमा ती तीन प्रश्न नै सूची हुन्, र टनेल केवल नवीनतम अवलोकन हो।
एक सेवा, तीन रेकर्ड
अभिप्रेत सेवा भनेको भाडावालले हक पाउने कुरा हो: पहिचान, प्रिफिक्स, स्रोत र जीवनचक्रको अवस्था। तैनाथ कन्फिगरेसन भनेको त्यसलाई साकार पार्ने उत्पन्न नीति हो। अवलोकित सत्र भनेको केही जोडिएको भन्ने रनटाइम प्रमाण हो। यिनलाई एउटै तालिका मान्दा तीन फरक किसिमको सत्यता एकैचोटि तीन तरिकाले गलत एक पंक्तिमा थिचिन्छ।
| Record | Answers | Goes stale when |
|---|---|---|
| Intended service | Who may reach what | A contract changes and nobody edits the record |
| Deployed configuration | What the gateway was told | A device is edited by hand |
| Observed session | What is running now | Telemetry stops or a session ends |
व्यावहारिक परीक्षण भनेको हरेक रेकर्डले एक्लै जवाफ दिन सक्ने प्रश्न हो। यो प्रिफिक्स कसको हो भनी सोध्नुहोस् र अभिप्रेत सेवाको रेकर्ड जवाफ दिन्छ। गेटवेसँग कुन नीति छ भनी सोध्नुहोस् र तैनाथ रेकर्ड जवाफ दिन्छ। यो हप्ता कसैले प्रयोग गर्यो कि भनी सोध्नुहोस् र सत्र रेकर्ड जवाफ दिन्छ। आफ्नै प्रश्नको जवाफ दिन नसक्ने स्तम्भ पहिले सुधार्नुपर्ने हो।
भाडावाल रेकर्ड गर्नुहोस्, इन्टरफेस होइन
हरेक सेवालाई पुनः जडानपछि टिक्ने पहिचान दिनुहोस्। अस्थायी टनेल इन्टरफेस वा सत्र नम्बर ग्राहकसँग कुनै सम्बन्ध नभएका कारणले बदलिन्छ, र तीमध्ये एउटामा आधारित सूची लिंक हल्लिँदा हरेक पटक नयाँ पंक्ति पाउँछ। बरु यसलाई भाडावाल र सेवामा आधारित गर्नुहोस्, त्यसपछि त्यो कुञ्जीमा अवलोकन जोड्नुहोस्।
रेकर्डलाई जिम्मेवार भाडावाल र सञ्चालक चाहिन्छ, स्वीकृत सहकर्मी वा प्रयोगकर्ता पहिचान, प्रमाणपत्रको प्रतिलिपि होइन त्यसको सन्दर्भ, संरक्षित प्रिफिक्स, राउटिङ सन्दर्भ, अनुमत स्रोत र अभिप्रेत जीवनचक्र अवस्था। प्रमाणपत्रको सामग्री समर्थित गोप्य भण्डारमा हुनुपर्छ; निजी कुञ्जी बोक्ने सूची वातावरणको दोस्रो, कम सुरक्षित प्रतिलिपि बनेको छ।
उत्पन्न कन्फिगरेसनको मालिक र संस्करण हुन्छ
स्वचालनले यसलाई सजिलो बनाउँछ र राम्ररी लुकाउँछ। सफलतापूर्वक चल्ने जेनेरेटरले टेम्प्लेट रेन्डर भयो भनी प्रमाणित गर्छ, हरेक यन्त्र आउटपुटसँग मिल्छ भनी होइन। कसैले घटनाको क्रममा गेटवे हातले बदल्नेछ, र त्यो परिवर्तन नै कैद गर्न लायक सबैभन्दा मूल्यवान कुरा हो, किनकि पछिको कुनै पनि रनले त्यसको पुनरुत्पादन गर्ने छैन।
तैनाथ नीति कुन संशोधनले बनायो रेकर्ड गर्नुहोस्, र सिधा सम्पादनहरू मिलाउनुपर्ने भिन्नताका रूपमा राख्नुहोस् तिनलाई चुपचाप माथिबाट लेख्ने सट्टा। मिलान नै यहाँ उत्पादन हो: जेनेरेटरको सफलता र यन्त्रको वास्तविक अवस्था तुलना गर्नुपर्ने दुई तथ्य हुन्, बराबर मान्नु हुँदैन।
सत्रहरू प्रमाण हुन्, अनुमति होइन
जहाँ तैनाथीले RADIUS लेखा प्रयोग गर्छ, त्यहाँ RFC 2866 ले काम गर्न ठोस फिल्ड दिन्छ। Acct-Status-Type ले सुरुवातलाई रोकावटबाट छुट्याउँछ, र एउटै सत्रका रेकर्डहरूले एउटा Acct-Session-Id साझा गर्छन्। ती फिल्डहरूले ड्यासबोर्डको सारांशमा भर नपर्दै सत्र कहिले सुरु र कहिले अन्त्य भयो पुनर्निर्माण गर्न दिन्छ।
लेखा पहिचान रनटाइम प्रमाण हो। कुन भाडावालले सबनेटको स्वामित्व राख्छ भनी यसले निर्धारण गर्दैन, र कुनै कुरामा पहुँच दिँदैन। यसलाई गेटवे र सेवा पहिचानसँग सहसम्बन्धित गर्नुहोस्, त्यसपछि संकलन समय अवलोकनको छेउमा राख्नुहोस्। हराएको प्रतिवेदन प्रयोगको अनुपस्थिति होइन, टेलिमेट्रीको विफलता हुन सक्छ, र पुरानो रेकर्ड पहुँच अझै सक्रिय छ भन्ने प्रमाण होइन।
निवृत्तिले पनि त्यही जोड प्रयोग गर्छ
सेवा हटाउनु भनेको अभिप्रेत पहुँच, प्रमाणपत्र र जीवित सत्रहरू त्यही क्रममा, प्रत्येकका मालिकमार्फत हटाउनु हो। त्यसपछि अप्रचलित कन्फिगरेसन यन्त्रहरूबाट गयो र यसका अनुमत मार्गहरू अब समाधान हुँदैनन् भनी जाँच्नुहोस्। गत त्रैमासमा गएको ग्राहक टनेलको नाम मेटियो तर मार्ग मेटिएन भनेर प्रिफिक्स सूचीमा रहनु हुँदैन।
यीमध्ये कुनैले पनि प्रति कार्य एक यन्त्र वा विशेष स्वचालन उत्पादन माग्दैन। सञ्चालन आवश्यकता अझ साँघुरो र कठिन छ: ग्राहक, उसको अभिप्रेत पहुँच, तैनाथ नीति र हालको रनटाइम प्रमाण कसैको टनेल नामको सम्झनामा भर नपर्दै जोड्न सकिने हुनुपर्छ। पहिले तीन रेकर्ड बनाउनुहोस्, त्यसपछि ती जोगाउने साधन छान्नुहोस्।