साइट VPN से पहले सबनेट की योजना बनाएँ: फिर से नंबर दें या अनुवाद करें

दो दफ़्तर दोनों 192.168.1.0/24 का उपयोग करते हैं क्योंकि किसी ने दूसरे तरीके से योजना नहीं बनाई, और टनल से उम्मीद है कि वह इसे सुलझा देगा। वह नहीं कर सकता: एक राउटर एक ही निजी पते को दो अलग जगहों का अर्थ नहीं बना सकता। इसे रोकने वाला काम पहला टनल पैरामीटर टाइप होने से पहले होता है।

हर रेंज की सूची बनाएँ, उन सहित जिन्हें आप भूल गए

LAN, सर्वर सेगमेंट, रिमोट-एक्सेस क्लाइंट पूल, क्लाउड VPC रेंज और वे सभी कंटेनर या ओवरले नेटवर्क इकट्ठा करें जहाँ तक होस्ट को पहुँचना है। क्लाइंट पूल वही हैं जिन्हें लोग भूल जाते हैं, और वे किसी दफ़्तर की रेंज से हैरान करने वाली बारंबारता से ओवरलैप करते हैं क्योंकि दोनों एक ही डिफ़ॉल्ट से चुने गए थे। प्रबंधन नेटवर्क और किसी भी आउट-ऑफ़-बैंड सेगमेंट को शामिल करें।

मालिक, गेटवे, उद्देश्य और यह दर्ज करें कि प्रीफ़िक्स दूसरी साइट से पहुँचने योग्य होना चाहिए या नहीं। जिस प्रीफ़िक्स को कभी टनल पार नहीं करनी होती, उसे अद्वितीय होना ज़रूरी नहीं, और यह जानना दोबारा नंबर देने का काम घटाता है।

IPv6 अलग से करें, क्योंकि उसकी योजना और उसके ओवरलैप स्वतंत्र हैं।

परिचित पतों की नहीं, प्रीफ़िक्स की तुलना करें

अलग होस्ट पतों वाले दो नेटवर्क फिर भी ओवरलैप कर सकते हैं, क्योंकि ओवरलैप मास्क का गुण है, उन संख्याओं का नहीं जो लोग याद रखते हैं। 10.20.0.0/16 में 10.20.30.0/24 है, चाहे कोई इसे ज़ोर से कहे या न कहे। पूर्ण प्रीफ़िक्स जोड़ियों की तुलना करें, और उनके भीतर के छोटे नेटवर्क के सामने एग्रीगेट जाँचें। इसीलिए यह जाँच स्प्रेडशीट में होनी चाहिए, किसी के सिर में नहीं।

वही जाँच VPN के अपने क्लाइंट पूल और आप जो भी अनूदित रेंज लाने की योजना बना रहे हैं, दोनों पर लागू होती है, क्योंकि टकराने वाली अनूदित रेंज मूल ओवरलैप से बदतर है।

मास्क के साथ प्रीफ़िक्स की तालिका पर्याप्त है; मास्क के बिना आरेख नहीं।

तय करें कि वास्तव में क्या पार होना चाहिए

एक साइट में तीस सबनेट हो सकते हैं जबकि एक सेवा नेटवर्क को रिमोट एक्सेस चाहिए। उसी आवश्यकता से शुरू करें और केवल वही घोषित करें जो उसे चाहिए, क्योंकि छोटी घोषणाएँ और मेल खाते एक्सेस नियम जाँचने में आसान और गलती से चौड़े करने में कठिन होते हैं। हर उपयोग में आने वाली निजी रेंज की घोषणा करना ऐसी आदत है जो टनल को पुल में बदल देती है। घोषणा जितनी संकरी, भविष्य की गलती का प्रभाव-दायरा उतना छोटा।

निजी DNS को ऐसे पते लौटाने होंगे जहाँ इच्छित क्लाइंट पहुँच सकें, इसलिए बिना घोषित या ओवरलैप वाली रेंज की ओर इशारा करने वाला नाम लुकअप सफल होने पर भी टूटा ही रहता है।

एक्सेस सूची टनल कॉन्फ़िग से पहले लिखें, उसके विफल होने के बाद नहीं।

फिर से नंबर दें या अनुवाद करें, और लागत जानें

एक नेटवर्क को फिर से नंबर देना आम तौर पर सबसे स्पष्ट दीर्घकालिक उपाय है, और यह आरक्षण, उपकरण, DNS, फ़ायरवॉल नियम और हर उस चीज़ को छूता है जिसका पता कॉन्फ़िग में बैठा है। अनुवाद करना तब विकल्प है जब फिर से नंबर देना अव्यावहारिक हो, और इसमें स्रोत पहचान के साथ उन प्रोटोकॉल का वर्ग भी जुड़ता है जो पते पेलोड में एम्बेड करते हैं। एक चुनें और पूरा करें, क्योंकि आधा-नंबर किया नेटवर्क दोनों विकल्पों से बदतर है।

आप जो भी चुनें, मूल और प्रस्तुत दोनों पते दर्ज करें, क्योंकि हर बाद की समस्या-निवारण बातचीत को दोनों चाहिए।

वापसी मार्ग के बिना कोई उपाय उपाय नहीं है।

स्वीकृति परीक्षण के रूप में रूट मैट्रिक्स का उपयोग करें

मैट्रिक्स के साथ समाप्त करें: स्थानीय प्रीफ़िक्स, दूरस्थ प्रीफ़िक्स, अनुमत सेवा और वापसी गेटवे। टनल उठने पर वही तालिका स्वीकृति परीक्षण है, और वही दस्तावेज़ है जिसे अगला इंजीनियर पढ़ेगा। गेटवे से नहीं, चुने गए सबनेट के वास्तविक होस्ट से परीक्षण करें।

टनल पतों के बीच ping साबित करता है कि टनल है, और उसके पीछे की पता योजना के बारे में कुछ नहीं।

मैट्रिक्स को टनल कॉन्फ़िग के साथ रखें, और अगली साइट जोड़ना स्मृति की बजाय डेटा से शुरू होगा। योजना होने पर strongSwan फ़ॉरवर्डिंग गाइड गेटवे पक्ष को कवर करता है।