साइट-देखि-साइट VPN का लागि ठेगाना ठाउँको आकार कसरी निर्धारण गर्ने
ट्रान्सपोर्ट इन्डपोइन्ट, आन्तरिक लिङ्क, सुरक्षित LAN र गेटवे सबनेट चार अलग बजेट हुन्। प्रत्येकलाई टोपोलोजीबाट मापन गर्नुहोस्, यन्त्रको संख्याबाट होइन।
VPN सबनेट कति ठूलो हुनुपर्छ भनेर सोध्नुहोस् र इमानदार उत्तर यो हो कि प्रश्नभित्र चार फरक सबनेट हुन सक्छन्। साइट VPN मा ट्रान्सपोर्ट इन्डपोइन्ट, क्रमाङ्कित टनेल लिङ्क, सुरक्षित LAN का प्रिफिक्स र व्यवस्थापित गेटवेमा प्रदायकले आरक्षित गरेको पूर्वाधार सबनेट समावेश हुन सक्छ। कुनै दिइएको डिजाइनमा तीमध्ये एक वा दुई मात्र हुन्छन्। तिनलाई अफिसका यन्त्रको संख्याबाट मापन गर्नु त्यो बाटो हो जसले योजना कसैलाई पनि सन्तुष्ट नगर्ने /24 मा पुग्छ।
केही पनि बाँडफाँट गर्नुअघि चार भूमिकाको नाम राख्नुहोस्
ट्रान्सपोर्ट इन्डपोइन्ट ती ठेगाना हुन् जो दुई गेटवेले इन्टरनेट वा निजी सर्किटमार्फत एकअर्कासम्म पुग्न प्रयोग गर्छन्, र तिनको संख्या गेटवे र रिडन्डन्सी मोडेलबाट आउँछ, LAN बाट होइन। आन्तरिक टनेल लिङ्क त्यहीँ मात्र हुन्छन् जहाँ डिजाइनले पोइन्ट-टु-पोइन्ट इन्टरफेसलाई क्रमाङ्कन गर्छ, जुन नीति-आधारित IPsec कन्फिगरेसनले सामान्यतया गर्दैन। सुरक्षित प्रिफिक्स भनेका वास्तविक अफिस वा VPC नेटवर्क हुन् जो मार्गीय हुनुपर्छ, र प्रदायकले आरक्षित गरेको सबनेट व्यवस्थापित सेवाको हो।
केही थप्नुअघि पहिलेदेखि रहेको कुराको सूची बनाउनुहोस्, किनकि यहाँको महँगो गल्ती भनेको पहिले नै अन्तै मार्गीय भइरहेको प्रिफिक्स पुनः प्रयोग गर्नु हो। कुनै पाइलट परियोजनाबाट बाँकी पुरानो टनेल योजना बिगार्न पर्याप्त छ। सूची मितिसहित लेख्नुहोस्, किनकि हटाइएको लिङ्कको सम्झना लिङ्कभन्दा लामो बाँच्छ।
ip -br addr show ip route show | head -40
ती दुई कमान्डले जोडिएका नेटवर्क र तिनका पछाडिको सबैथोकसम्म पुग्ने मार्गको स्थानीय दृश्य दिन्छन्। हरेक साइटमा सूची दोहोर्याउनुहोस्, किनकि एउटा साइटको आउटपुटमा बनेको योजना अर्को साइटको आउटपुटसँग ठोकिनेछ। एउटै ब्लक बाँडफाँट गर्नुअघि आउटपुट जम्मा गर्नुहोस्।
लिङ्क र टोपोलोजी गन्नुहोस्, यन्त्र होइन
आठ पोइन्ट-टु-पोइन्ट छिमेकी भएको डिजाइनले आठ ब्लक खर्च गर्छ, एउटा होइन। /30 मा हरेक ब्लकले दुई होस्ट जोड्न चार ठेगाना खर्च गर्छ, त्यसैले योजनाले सोह्र प्रयोगयोग्य इन्डपोइन्टका लागि बत्तीस ठेगाना बोक्छ, र बजेटले यही सङ्ख्या धान्नुपर्छ। /31 लिङ्क समर्थन गर्ने प्लेटफर्मले आधा खर्च गर्छ, तर दुवै छेउ र सेवा यो मोडेलमा सहमत भएमा मात्र। बजेट तल होइन माथि गोल गर्नुहोस्, किनकि पछि ब्लक सानो बनाउनु भनेको चालु लिङ्क पुनः क्रमाङ्कन गर्नु हो।
प्रदायकका सीमाले सामान्य अभ्यासलाई जित्छ। कुनै अभिलेखित आन्तरिक टनेल दायराले तपाईंका राउटरमा /31 चलेको ठाउँमै पनि /30 माग्न सक्छ, र व्यवस्थापित गेटवेले आफ्नै सबनेटका लागि निश्चित मास्क माग्न सक्छ। अर्को प्लेटफर्मबाट उधारो लिएको नियम लागू गर्नुअघि सेवाको सर्त पढ्नुहोस्।
बहुबिन्दु ओभरले गणित फेरि बदल्छ: प्रत्येक गेटवेका लागि एउटा ठेगाना, र तिनबीचको पहुँच ओभरलेले सम्हाल्छ। साइटहरूलाई ब्लक आकारले गुणन गर्नुअघि कार्यान्वयनले वास्तवमा कुन टोपोलोजी प्रयोग गर्छ निर्णय गर्नुहोस्।
वृद्धिले योजनामा आफ्नै छुट्टै लाइन पाउनुपर्छ। सुसंगत पूर्वाधार दायरा आरक्षित गर्नु उचित छ, र त्यसभित्र कुन साना बाँडफाँट छन् भन्ने अभिलेख गर्नु पनि, ताकि अर्को इन्जिनियरले यो आरक्षणलाई एउटै प्रसारण डोमेन ठान्न नपरोस्।
गेटवे सबनेटलाई LAN पोखरीबाहिर राख्नुहोस्
व्यवस्थापित गेटवेको पूर्वाधार ग्राहक पोखरी होइन। आरक्षित गेटवे सबनेटका ठेगानाले सेवाकै घटकहरू राख्छन्, र टाढाका कर्मचारीले कहिल्यै तिनबाट लिँदैनन्। त्यो सबनेटलाई प्रयोगकर्ताको संख्याबाट मापन गर्नु एउटा वर्गगत गल्ती हो जसले ठूलो दायरा बर्बाद गर्छ वा गेटवेलाई भोकै राख्छ।
यही कुरा क्लाउड VPN जडानका टनेल दायरामा पनि लागू हुन्छ, जहाँ प्रदायकले प्रत्येक टनेलका लागि आफ्नै प्रयोगका लागि सानो आन्तरिक दायरा बाँडफाँट गर्छ। त्यो दायरा तपाईंका शाखा सर्भर बस्ने ठाउँ होइन, र त्यो तपाईंको होइन कि बाँडिदिनु।
aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table
बाह्य ठेगाना सूचीबद्ध गर्नुले प्रदायकले के बाँडफाँट गर्यो र कुन अतिरिक्त टनेल अहिले सक्रिय छ भन्ने पुष्टि गर्छ। जडान अस्तित्वमा आउनुअघि लेखिएको डिजाइन कागज पढ्नुभन्दा यो छिटो हुन्छ।
हरेक प्रिफिक्सका लागि भूमिका, मालिक र वृद्धि अभिलेख गर्नुहोस्
सञ्चालनसँगको सम्पर्कमा टिक्ने योजनाले हरेक प्रिफिक्सका लागि भन्छ कि यसले कुन भूमिका खेल्छ, टाढाको छेउ कसले बाँडफाँट गर्छ र कति ठाउँ बाँकी छ। मालिक फिल्डबिना दुई टोलीले एउटै त्रैमासमा एउटै /24 बाँडफाँट गर्छन्, र ठोक्किने कुरा टनेल माथि उठेपछि मात्र देखिन्छ।
यी दायरा घर र शाखाका ती प्रिफिक्सबाट टाढा राख्नुहोस् जो अरू टनेलबाट आउँछन्, किनकि ठाउँको ओभरल्याप नै सामान्य कारण हो साइटबीचको जडान सफलतापूर्वक वार्ता गरेर पनि कुनै ट्राफिक नपठाउनुको।
आन्तरिक लिङ्क ठेगाना बाँडफाँट गर्नुले तिनका पछाडिका LAN नेटवर्क घोषणा गर्दैन। मार्ग वा ट्राफिक छनोटकर्ता, फर्किने बाटो र पहुँच नियम अलग कार्यवस्तु हुन्, र योजनाले यही भन्नुपर्छ, क्रमाङ्कित इन्टरफेसले तपाईंका लागि मार्गीय गरिदिन्छ भन्ने सङ्केत गर्नुको सट्टा।