VPN सबनेट कति ठूलो हुनुपर्छ भन्ने प्रश्नको उत्तर, तपाईं कुन ठेगानाहरू गन्दै हुनुहुन्छ भनेर नाम नदिएसम्म हुँदैन। एउटा डिजाइनमा ती ठेगानाहरू क्रमांकित टनेल लिङ्कका दुई छेउ हुन्, अर्कोमा ती नीति-आधारित टनेलपछाडिको कार्यालय LAN हो, र तेस्रोमा ती व्यवस्थापित गेटवेको आरक्षित पूर्वाधार हो। तीन वस्तु, तीन बजेट, र धेरै आकारका गल्तीहरू एउटा स्तम्भलाई अर्को स्तम्भको संख्याले भर्नबाट आउँछन्।

चार भूमिका, चार फरक प्रश्न

बाहिरी यातायात त्यो ठेगाना हो जहाँ सहकर्मी जोडिन्छ, त्यसैले यसको आकार तपाईंको सार्वजनिक ठेगाना वा प्रदायकको ठेगानालाई पछ्याउँछ, यसको पछाडिका उपकरणहरूको संख्यालाई कहिल्यै होइन। आन्तरिक टनेल लिङ्कहरू भर्चुअल इन्टरफेसलाई क्रमांक दिने डिजाइनमा मात्र हुन्छन्, र त्यहाँ संख्या टोपोलोजीका छिमेकीहरूलाई पछ्याउँछ। सुरक्षित LAN उपसर्गहरू वास्तविक नेटवर्क र तिनका वृद्धि योजनालाई पछ्याउँछन्। प्रदायकले आरक्षित गरेको पूर्वाधार व्यवस्थापित सेवाले अभिलेख गर्ने कुरालाई पछ्याउँछ।

तीमध्ये तेस्रोलाई मात्र कार्यालयमा कति ल्यापटप छन् भन्नेसँग केही सम्बन्ध छ। त्यही एउटा भ्रमले धेरै बहसहरू व्याख्या गर्छ।

क्याल्कुलेटर खोल्नुअघि चार भूमिकाहरूलाई अलग-अलग स्तम्भका रूपमा लेख्नुहोस्। प्रत्येकले आफ्नै बाँडफाँट, मालिक र वृद्धिको अनुमान पाउँछ, र कुनैले अर्काको आकार पाउँदैन। जब डिजाइनमा कुनै क्रमांकित आन्तरिक लिङ्क हुँदैन, त्यो स्तम्भ सानो नभई खाली हुन्छ, र खाली स्तम्भ अर्को समीक्षकका लागि अभिलेख गर्नयोग्य तथ्य हो।

ब्लक गन्ने: /30 को वास्तविक लागत

बिन्दु-देखि-बिन्दु लिङ्कलाई दुई ठेगाना चाहिन्छ र प्लेटफर्ममा निर्भर आकारको ब्लक खर्च गर्छ। /30 मा चार ठेगाना हुन्छन्, तीमध्ये दुई सामान्यतया प्रयोगयोग्य हुन्छन्, त्यसैले बाह्र लिङ्कले योजनामा अठ्चालीस ठेगाना खर्च गर्छन् भने चौबीस छेउ दिन्छन्। /31 मा दुई ठेगाना हुन्छन् र दुवै प्रयोगयोग्य हुन्छन्, जसले गणना आधा गर्छ, तर दुवै छेउले स्वीकार गर्ने ठाउँमा मात्र।

RFC 3021 ले दुई-ठेगाना मोडेल परिभाषित गर्छ, र समर्थन छेउ र सेवाको गुण हो, असल नियतको होइन। प्रदायकको API ले आन्तरिक टनेल विकल्पमा आफ्नै मास्क-शर्त लाद्न सक्छ, र सामान्य RFC ले अभिलेखित सीमालाई रद्द गर्दैन। बजेट संक्षेप गर्नुअघि तपाईंको प्लेटफर्मले के भन्छ जाँच्नुहोस्, किनकि अठ्चालीस र चौबीस ठेगानाबीचको फरकले योजना आरक्षित दायरामा अटाउँछ कि अटाउँदैन भन्ने निर्धारण गर्छ। लामो दिनको अन्त्यमा भरोसा गर्नुको सट्टा गणना गर्नुहोस्।

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

टोपोलोजी स्थिर भएपछि मात्र गुणन गर्नुहोस्। बाह्र अलग लिङ्क र बाह्र सहभागी भएको एउटा बहुबिन्दु ओभरले एउटै साइट-संख्याबाट धेरै फरक जोड दिन्छ।

व्यवस्थापित गेटवेको सबनेट क्लाइन्ट पूल होइन

व्यवस्थापित सेवाले प्रायः आफ्नै गेटवे पूर्वाधारका लागि सबनेट आरक्षित राख्छ, र त्यो सबनेट क्लाइन्टलाई दिनुको सट्टा सेवाले खर्च गर्छ। यसको अभिलेखित आकार हुन्छ, कहिले अभिलेखित नाम पनि, र कति प्रयोगकर्ता जोडिन्छन् भन्नेसँग कुनै सम्बन्ध हुँदैन। यसलाई टाढाका मेसिनका लागि ठेगाना पूल मान्नाले पहिलो व्यस्त बिहानै आफैं सकिने डिजाइन बन्छ।

प्रदायकको शर्तलाई स्थिर लागतका रूपमा पढ्नुहोस्, जसरी र्याक इकाइलाई व्यवहार गर्नुहुन्थ्यो। यो सुरक्षित उपसर्गको बजेटको भाग होइन।

त्यही पढाइ नामहरूमा पनि लागू हुन्छ। जसको अभिलेखित उद्देश्य गेटवे पूर्वाधार हो, त्यस्तो सबनेट त्यो सेवामा परम्पराअनुसार पूर्वाधार हो, र आफ्नै योजनामा मिलाउन यसको नाम बदल्नु डायग्राम सुधार्नुको सट्टा तैनाथी तोड्छ। प्रदायकका नाम र आकार राख्नुहोस्, र आफ्नो क्रमांकन योजना आफूले नियन्त्रण गर्ने भागहरूमा खर्च गर्नुहोस्।

दोस्रो साइटसम्म टिक्न योजना अभिलेख गर्नुहोस्

एउटा इन्जिनियरको दिमागमा बस्ने योजना कार्यालय उपसर्ग र घरायसी राउटरको पूर्वनिर्धारित दायराबीचको पहिलो अतिव्यापनमै असफल हुन्छ। बाँडफाँटहरू तिनका मालिकसहित प्रकाशित गर्नुहोस्, र प्रत्येक लिङ्कको कुन छेउले कुन ठेगाना तोक्छ भन्नुहोस्। मार्ग वा चयनकर्ताहरू अझै घोषणा गर्नुपर्छ, किनकि आन्तरिक लिङ्कलाई क्रमांक दिनु आफैंले LAN घोषणा गर्दैन।

प्रत्येक ब्लकपछाडिको वृद्धि अनुमान अभिलेख गर्नुहोस्, किनकि पछिका कुनै पनि पाठकले केवल ठेगानाबाट त्यो भाग पुनर्निर्माण गर्न सक्दैन।

त्यसपछि योजनालाई कठिन अवस्थाहरूमा परीक्षण गर्नुहोस्: तपाईंले पहिलेदेखि प्रयोग गर्ने उपसर्गसँग आउने साइट, टाढाको छेउ अरू कसैले व्यवस्थापन गर्ने लिङ्क, र प्रदायकको शर्त तपाईंले अभिलेख गरेको पहिलोभन्दा फरक हुने क्षेत्र। यीमध्ये कुनैले पुनर्डिजाइन जबरजस्ती गर्छ भने तपाईंसँग नीति होइन, डायग्राम थियो। ती सबैलाई टिक्ने योजना टनेल कन्फिगरेसनको छेउमा भण्डारमा राख्न पुग्ने छोटो हुन्छ, र अर्को व्यक्तिले ठ्याक्कै त्यहीँ खोज्नेछ।

सम्बन्धित लेखहरू