साइट VPN आधी सबनेटचे नियोजन करा: पुन्हा क्रमांक द्या किंवा भाषांतर करा

दोन कार्यालये दोन्ही 192.168.1.0/24 वापरतात कारण कोणीही वेगळे नियोजन केले नाही, आणि बोगदा ते सोडवेल अशी अपेक्षा आहे। तो करू शकत नाही: एकच खाजगी पत्ता दोन वेगळ्या ठिकाणांचा अर्थ दाखवण्यासाठी राउटरला जमत नाही। हे टाळणारे काम पहिला बोगदा पॅरामीटर टाइप होण्यापूर्वी होते।

प्रत्येक श्रेणीची यादी करा, विसरलेल्यांसह

LAN, सर्व्हर विभाग, दूरस्थ प्रवेश क्लायंट पूल, क्लाउड VPC श्रेणी आणि होस्टला पोहोचायच्या असलेल्या सर्व कंटेनर किंवा ओव्हरले नेटवर्क गोळा करा। लोक विसरतात ते क्लायंट पूल, आणि दोन्ही एकाच डीफॉल्टमधून निवडले गेल्यामुळे ते कार्यालयाच्या श्रेणीशी आश्चर्यकारकपणे वारंवार ओव्हरलॅप होतात। व्यवस्थापन नेटवर्क आणि कोणताही आउट-ऑफ-बँड विभाग समाविष्ट करा।

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

IPv6 वेगळे करा, कारण त्याची योजना आणि त्याचे ओव्हरलॅप स्वतंत्र आहेत।

ओळखीच्या पत्त्यांची नाही, प्रीफिक्सची तुलना करा

वेगळ्या होस्ट पत्त्यांच्या दोन नेटवर्कचा ओव्हरलॅप होऊ शकतो, कारण ओव्हरलॅप हा मास्कचा गुणधर्म आहे, लोकांना आठवणाऱ्या संख्यांचा नाही। 10.20.0.0/16 मध्ये 10.20.30.0/24 आहे, कोणी मोठ्याने सांगो वा न सांगो। संपूर्ण प्रीफिक्स जोड्यांची तुलना करा, आणि त्यांच्यातील लहान नेटवर्कशी एग्रीगेट तपासा। म्हणूनच ही तपासणी कोणाच्या डोक्यात नाही, स्प्रेडशीटमध्ये असली पाहिजे।

तीच तपासणी VPNच्या स्वतःच्या क्लायंट पूलवर आणि तुम्ही सुरू करू इच्छित असलेल्या कोणत्याही भाषांतरित श्रेणीवर लागू होते, कारण टक्कर देणारी भाषांतरित श्रेणी मूळ ओव्हरलॅपपेक्षा वाईट आहे।

मास्कसह प्रीफिक्सचे तक्ते पुरेसे आहे; मास्कशिवाय आकृती नाही।

प्रत्यक्षात काय ओलांडले पाहिजे ते ठरवा

एका साइटमध्ये तीस सबनेट असू शकतात तर एका सेवा नेटवर्कला दूरस्थ प्रवेश हवा असतो। त्या गरजेपासून सुरुवात करा आणि तिला जे हवे तेच जाहीर करा, कारण लहान जाहिराती आणि जुळणारे प्रवेश नियम तपासणे सोपे आणि चुकून रुंद करणे कठीण असते। वापरात असलेली प्रत्येक खाजगी श्रेणी जाहीर करणे ही बोगद्याचे पूल करणारी सवय आहे। जाहिरात जितकी अरुंद, भविष्यातील चुकीचा परिणाम तितका लहान।

खाजगी DNS ने इच्छित क्लायंट पोहोचू शकतील असे पत्ते परत द्यायला हवेत, म्हणून न जाहीर केलेल्या किंवा ओव्हरलॅप असलेल्या श्रेणीकडे निर्देश करणारे नाव शोध यशस्वी झाला तरी तुटलेलेच राहते।

प्रवेश यादी बोगदा कॉन्फिगच्या आधी लिहा, तो अयशस्वी झाल्यानंतर नाही।

पुन्हा क्रमांक द्या किंवा भाषांतर करा, आणि खर्च जाणून घ्या

एक नेटवर्कचे पुन्हा क्रमांकन हा सहसा सर्वात स्पष्ट दीर्घकालीन उपाय असतो, आणि तो आरक्षणे, उपकरणे, DNS, फायरवॉल नियम आणि कॉन्फिगमध्ये पत्ता बसवलेल्या सर्व गोष्टींना स्पर्श करतो। पुन्हा क्रमांकन अव्यवहार्य असेल तेव्हा प्रवेश श्रेणीचे भाषांतर हा पर्याय असतो, आणि त्याची किंमत स्रोत ओळख आणि पत्ते पेलोडमध्ये बसवणाऱ्या प्रोटोकॉलचा वर्ग आहे। एक निवडा आणि पूर्ण करा, कारण अर्धवट पुन्हा क्रमांकित नेटवर्क दोन्ही पर्यायांपेक्षा वाईट आहे।

तुम्ही जे निवडा, मूळ आणि सादर केलेला दोन्ही पत्ता नोंदवा, कारण पुढील प्रत्येक समस्या-निवारण संभाषणाला दोन्ही हवेत।

परतीचा मार्ग नसलेला उपाय उपाय नाही।

स्वीकृती चाचणी म्हणून रूट मॅट्रिक्स वापरा

मॅट्रिक्सने समाप्त करा: स्थानिक प्रीफिक्स, दूरस्थ प्रीफिक्स, परवानगी असलेली सेवा आणि परतीचा गेटवे। बोगदा उभा राहिल्यावर तेच तक्ते स्वीकृती चाचणी आहे, आणि पुढील अभियंता वाचणारा तोच दस्तऐवज आहे। गेटवेकडून नाही, निवडलेल्या सबनेटवरील खऱ्या होस्टकडून चाचणी करा।

बोगदा पत्त्यांमधील ping बोगदा अस्तित्वात असल्याचे सिद्ध करते, आणि त्यामागील पत्ता योजनेबद्दल काहीही नाही।

मॅट्रिक्स बोगदा कॉन्फिगसोबत ठेवा, आणि पुढील साइट जोडणी स्मरणातून नाही तर डेटापासून सुरू होईल। योजना असल्यावर strongSwan फॉरवर्डिंग मार्गदर्शक गेटवे बाजू व्यापते।