डबल-एनएटी नेटवर्क के लिए नेटवर्क रीस्ट्रक्चर विधि


10

खराब नेटवर्क डिज़ाइन निर्णयों की एक श्रृंखला के कारण (ज्यादातर) कुछ साल पहले यहाँ और वहाँ कुछ रुपये बचाने के लिए, मेरे पास एक नेटवर्क है जो निश्चित रूप से उप-आशावादी रूप से वास्तुकला में है। मैं इस कम-से-सुखद स्थिति को बेहतर बनाने के लिए सुझावों की तलाश कर रहा हूं।

हम लिनक्स आधारित आईटी विभाग और एक सीमित बजट के साथ गैर-लाभकारी हैं। (ध्यान दें: हमारे पास जितने भी विंडोज उपकरण हैं उनमें से कोई भी ऐसा कुछ भी नहीं करता है जो इंटरनेट से बात करता हो और न ही हमारे पास कर्मचारियों पर कोई विंडोज प्रवेश है।)

प्रमुख बिंदु:

  • हमारे पास एक मुख्य कार्यालय और लगभग 12 दूरस्थ साइट हैं जो शारीरिक रूप से अलग-थलग स्विच के साथ अपने सबनेट को अनिवार्य रूप से दोगुना करते हैं। (कोई VLANing और वर्तमान स्विच के साथ ऐसा करने की सीमित क्षमता)
  • इन स्थानों पर एक "DMZ" सबनेट है जो प्रत्येक साइट पर 10.0.0 / 24 सबनेट को एक निर्दिष्ट रूप से असाइन किया गया है। ये सबनेट किसी अन्य स्थान पर DMZ से बात नहीं कर सकते क्योंकि हम सर्वर और आसन्न "फ़ायरवॉल" के अलावा कहीं भी उन्हें रूट नहीं करते हैं।
  • इनमें से कुछ स्थानों में कई आईएसपी कनेक्शन (टी 1, केबल और / या डीएसएल) हैं जो हम लिनक्स में आईपी टूल का उपयोग करके मैन्युअल रूप से करते हैं। ये फ़ायरवॉल सभी (10.0.0 / 24) नेटवर्क पर चलते हैं और ज्यादातर "प्रो-समर" ग्रेड फायरवॉल (लिंक्स, नेटगियर, आदि) या आईएसपी-प्रदान किए गए डीएसएल मोडेम हैं।
  • इन फायरवॉल को कनेक्ट करना (सरल अप्रबंधित स्विच के माध्यम से) एक या एक से अधिक सर्वर हैं जो कि सार्वजनिक रूप से सुलभ होने चाहिए।
  • मुख्य कार्यालय के 10.0.0 / 24 सबनेट से जुड़े ईमेल, टेली-कम्यूटर वीपीएन, रिमोट ऑफिस वीपीएन सर्वर, प्राथमिक राउटर से आंतरिक 192.168 / 24 सबनेट के लिए सर्वर हैं। इन्हें ट्रैफ़िक प्रकार और कनेक्शन स्रोत के आधार पर विशिष्ट ISP कनेक्शन से एक्सेस करना होगा।
  • हमारे सभी मार्ग मैन्युअल रूप से या ओपनवीपीएन मार्ग के बयानों के साथ किए जाते हैं
  • इंटर-ऑफिस ट्रैफ़िक मुख्य 'राउटर' सर्वर में ओपनवीपीएन सेवा से होकर गुज़रता है, जिसमें स्वयं नैटिंग शामिल है।
  • दूरस्थ साइटों में प्रत्येक साइट पर केवल एक सर्वर स्थापित होता है और बजट की कमी के कारण कई सर्वरों को वहन नहीं कर सकता है। ये सर्वर सभी LTSP सर्वर कई 5-20 टर्मिनल हैं।
  • 192.168.2 / 24 और 192.168.3 / 24 सबनेट ज्यादातर हैं लेकिन पूरी तरह से सिस्को 2960 स्विच पर नहीं हैं जो वीएलएएन कर सकते हैं। शेष DLink DGS-1248 स्विच हैं जो मुझे यकीन नहीं है कि मैं VLANs के साथ उपयोग करने के लिए पर्याप्त भरोसा करता हूं। वीएलएएन के बारे में कुछ शेष आंतरिक चिंता भी है क्योंकि केवल वरिष्ठ नेटवर्किंग कर्मचारी व्यक्ति यह समझता है कि यह कैसे काम करता है।

सभी नियमित इंटरनेट ट्रैफ़िक CentOS 5 राउटर सर्वर से होकर गुज़रते हैं जो 192.168 / 24 सबनेट को NAT में बदलकर 10.0.0.0/24 सबनेट पर मैन्युअल रूप से कॉन्फ़िगर किए गए रूलिंग नियमों के अनुसार करते हैं जो हम आउटबाउंड ट्रैफ़िक को उचित इंटरनेट कनेक्शन के आधार पर इंगित करने के लिए उपयोग करते हैं '-host' रूटिंग स्टेटमेंट्स।

मैं इसे सरल बनाना चाहता हूं और इन सार्वजनिक-सामना वाली सेवाओं सहित ESXi वर्चुअलाइजेशन के लिए सभी चीजों को तैयार करना चाहता हूं। क्या कोई न् या कम लागत वाला समाधान है जो डबल-एनएटी से छुटकारा दिलाएगा और इस गंदगी को थोड़ा संचित करेगा ताकि मेरा भविष्य प्रतिस्थापन मुझे शिकार न करे?

मुख्य कार्यालय के लिए मूल आरेख: यहाँ छवि विवरण दर्ज करें

ये मेरे लक्ष्य हैं:

  • उस मध्य 10.0.0 / 24 नेटवर्क पर इंटरफेस के साथ सार्वजनिक-सामना करने वाले सर्वर को ESXi सर्वर पर 192.168.2 / 24 सबनेट में स्थानांतरित किया जाना है।
  • डबल NAT से छुटकारा पाएं और एक ही सबनेट पर हमारा पूरा नेटवर्क प्राप्त करें। मेरी समझ यह है कि यह कुछ ऐसा है जिसे हमें IPv6 के तहत वैसे भी करने की आवश्यकता होगी, लेकिन मुझे लगता है कि यह गड़बड़ रास्ते में खड़ी है।

एफ / डब्ल्यू 1 - एफ / डब्ल्यू 3 सभी एक ही सबनेट साझा करते हैं, क्या वे करते हैं? या उनका मुखौटा इससे छोटा है /24? या क्या उनके पास अपने LTSP क्लाइंट के लिए पूरी तरह से अलग नेटवर्क है, और सर्वर दोनों नेटवर्क से जुड़ा है?
मार्क हेंडरसन

हां, सबनेट भौतिक रूप से अलग और लेबल के रूप में संबोधित किए जाते हैं। वास्तव में, यह और भी अधिक सरल है कि 192.168.3 / 24 को वास्तव में 2/24 और 3/24 इंटरफ़ेस वाले सर्वर के माध्यम से रूट किया जाता है, इससे पहले कि यह LTAT कार्यस्थानों से THAT सर्वर के पीछे चला जाता है।
मैगलन

जवाबों:


7

1.) इससे पहले कि मूल रूप से कुछ और अपने आईपी पते की योजना को सीधा कर लें। यह रेनमर करने के लिए दर्दनाक है लेकिन यह एक काम करने योग्य बुनियादी ढांचे पर पहुंचने के लिए आवश्यक कदम है। कार्यस्थानों, सर्वरों, दूरस्थ साइटों (अद्वितीय आईपी के साथ, स्वाभाविक रूप से), प्रबंधन नेटवर्क, लूपबैक आदि के लिए आराम से बड़े, आसानी से सारांशित सुपरनेट सेट करें। RFC1918 का बहुत सा स्थान है और कीमत सही है।

2.) ऊपर दिए गए आरेख के आधार पर अपने नेटवर्क में L2 को कैसे रखना है, यह समझ पाना कठिन है। वीएलएएन आवश्यक नहीं हो सकता है यदि आपको अपने विभिन्न गेटवे के साथ-साथ पर्याप्त संख्या में स्विच में इंटरफेस की पर्याप्त संख्या मिली है। एक बार जब आप # 1 की भावना प्राप्त कर लेते हैं, तो यह L2 प्रश्न को अलग से पुनः प्राप्त करने के लिए समझ में आता है। कहा कि, वीएलएएन प्रौद्योगिकियों का एक विशेष रूप से जटिल या उपन्यास सेट नहीं है और इसे जटिल नहीं होना चाहिए। बुनियादी प्रशिक्षण की एक निश्चित राशि क्रम में है, लेकिन कम से कम बंदरगाहों के कई समूहों में मानक स्विच को अलग करने की क्षमता (यानी ट्रंकिंग के बिना) बहुत सारा पैसा बचा सकती है।

3.) DMZ मेजबानों को संभवतः अपने स्वयं के L2 / L3 नेटवर्क पर रखा जाना चाहिए, कार्यस्थानों में विलय नहीं किया जाना चाहिए। आदर्श रूप से आपके पास एक L3 डिवाइस (रूटर्स का एक और सेट; L3 स्विच?) से जुड़ा आपका बॉर्डर राउटर होगा, जो बदले में, आपके बाह्य रूप से सामना करने वाले सर्वर इंटरफेस (SMTP होस्ट, आदि) से एक नेटवर्क को जोड़ेगा। ये होस्ट संभावित रूप से एक सामान्य नेटवर्क सबनेट से एक अलग नेटवर्क (या कम आशावादी) से जुड़ेंगे। यदि आपने अपने सबनेट को उचित रूप से निर्धारित किया है तो इनबाउंड ट्रैफ़िक को निर्देशित करने के लिए आवश्यक स्थिर मार्ग बहुत सरल होना चाहिए।

3 ए।) वीपीएन नेटवर्क को अन्य इनबाउंड सेवाओं से अलग रखने की कोशिश करें। इससे सुरक्षा निगरानी, ​​समस्या निवारण, लेखांकन आदि के रूप में चीजें आसान हो जाएंगी।

4.) अपने इंटरनेट कनेक्शन को मजबूत करने और / या कई वाहकों के माध्यम से एक एकल सबनेट को रूट करने के लिए (पढ़ें: बीजीपी) आपको अपनी सीमा से पहले और बाहर जाने वाले ट्रैफ़िक को पुनर्निर्देशित करने में सक्षम होने के लिए मध्यवर्ती सीमा की आवश्यकता होगी (जैसा कि मुझे संदेह है कि आप इस समय कर रहे हैं)। यह वीएलएएन की तुलना में एक बड़ा सिरदर्द की तरह लगता है, लेकिन मुझे लगता है कि यह सब रिश्तेदार है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.