शाखा आणि प्रयोगशाळा यांना जोडण्यासाठी राउटेड VPN की ब्रिज्ड LAN

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

जोडण्याचे दोन मार्ग, एक स्पष्ट तडजोड

राउटेड लिंक घरगुती प्रयोगशाळेला तिच्या स्वतःच्या अॅड्रेसिंगसह दूरचं नेटवर्क मानते। शाखा प्रयोगशाळेचा प्रीफिक्स मागते, टनेल ती पॅकेट्स वाहून नेते, आणि प्रयोगशाळेचा गेटवे तिच्या स्वतःच्या सबनेटमधून उत्तर देतो। शाखेच्या ARP तक्त्यात काहीही बदलत नाही, आणि प्रयोगशाळेच्या DHCP परिघातून काहीही शाखेपर्यंत पोहोचत नाही।

ब्रिज्ड लिंक एकच लेयर 2 डोमेन दोन्ही साइट्सवर पसरवते। शोध प्रोटोकॉल चालतात, उपकरणं आपोआप दिसू लागतात, आणि प्रत्येक ब्रॉडकास्ट, प्रत्येक ARP विनंती आणि प्रत्येक multicast पॅकेट आता टनेल ओलांडण्याचा उमेदवार आहे, म्हणजे मोठ्या प्रमाणातील ट्राफिक जे स्थानिक सेगमेंटसाठी बनवलेले प्रोटोकॉल वाहतात, वेगळ्या MTU आणि बदलत्या राउंड-ट्रिप वेळेच्या WAN साठी नाही।

राउटिंग तुम्हाला काय देते

पहिला फायदा नुकसानाचा परिघ आहे। लूप, नको असलेला DHCP सर्व्हर किंवा ब्रॉडकास्टचा पूर त्या साइटमध्येच राहतो ज्याने तो निर्माण केला, कारण राउटर ब्रॉडकास्ट पुढे पाठवत नाही। दुसरा अॅड्रेसिंगचा स्पष्टपणा आहे: शाखेचा प्रीफिक्स आणि प्रयोगशाळेचा प्रीफिक्स वेगळे आहेत, त्यामुळे पॅकेटचं गंतव्य कुठल्या साइटने उत्तर द्यायचं ते सांगतं, आणि फायरवॉल नियम «सगळीकडून सगळीकडे» ऐवजी «शाखेतून प्रयोगशाळेच्या सबनेटकडे» म्हणू शकतो।

तिसरा असा आहे की हे टनेल प्रत्यक्षात काय वाहतं याशी जुळतं। IPsec धोरण ही प्रीफिक्सची जोडी आहे, आणि प्रत्येक बाजूला पुढे पाठवण्याचा मार्ग गेटवेवर पुढे पाठवणं सुरू करून सामान्य IP राउटिंग आहे:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

तुम्ही जे सोडता ते ब्रॉडकास्टद्वारे शोध आहे। हे खरं नुकसान आहे आणि सगळं ब्रिज करून टाळण्याऐवजी जाणीवपूर्वक बदललं पाहिजे।

ब्रिजिंगची किंमत

ब्रिजिंगला लेयर 2 फ्रेम्स टनेलमधून वाहून न्यावी लागतात, म्हणजे साध्या धोरणाधारित टनेलऐवजी IPsec वर GRE किंवा VXLAN सारखं एन्कॅप्स्युलेशन। हे अस्तित्वात आल्यावर दोन्ही साइट्स एकच अपयश डोमेन वाटून घेतात। Spanning tree टनेलला लिंक मानतो, ब्रॉडकास्ट ट्राफिक टनेलची बँडविड्थ खातं, आणि कमी विलंबाचा सेगमेंट गृहीत धरणारं कोणतंही उपकरण अशा पद्धतीने चुकीचं वागतं ज्याचं कोणत्याही टोकाकडून कारण शोधणं कठीण आहे।

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

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

ब्रॉडकास्टशिवाय नावं

लोक ब्रिज करतात कारण सहसा शोध हवा असतो: एखादा प्रिंटर, मीडिया उपकरण किंवा प्रयोगशाळेचा होस्ट जो कधीही यादीत दिसत नाही। राउटेड उत्तर म्हणजे नाव सेवा। प्रयोगशाळेचे होस्ट अशा झोनमध्ये प्रकाशित करा जिथे शाखेचा रिझॉल्व्हर पोहोचू शकेल, नंतर वापरकर्त्यांना नेटवर्क स्कॅन करण्याऐवजी नावाने जोडू द्या। हे सुरुवातीला जास्त काम आहे आणि प्रत्येक भावी बदलात बरंच कमी।

multicast शोध हे कठीण प्रकरण आहे आणि त्याला अचूकता हवी। mDNS सारखे प्रोटोकॉल लिंक-लोकल multicast वापरतात जे राउटर डीफॉल्टने पुढे पाठवत नाहीत, त्यामुळे शोध यादीतून गायब असलेला प्रयोगशाळेचा होस्ट त्याच्या नोंदवलेल्या पत्त्यावर तरीही पोहोचण्यायोग्य असू शकतो। एखाद्या विशिष्ट सेवेला खरंच multicast हवं असेल, तर संपूर्ण LAN सामान्य दुरुस्ती म्हणून ब्रिज करण्याऐवजी तीच एक प्रोटोकॉल योजना करा, रिफ्लेक्टर किंवा लक्ष्यित पुढे पाठवण्याच्या नियमासह।

रिफ्लेक्टरही मोफत विजय नाही। तो तोच बडबडा ट्राफिक आत आणतो ज्यापासून तुम्हाला बचायचं होतं, एका वेळी एक सेवा, आणि त्याला असा मालक हवा जो लक्ष देईल जेव्हा उपकरण पूर्वीपेक्षा जास्त जाहिरात करू लागेल। तो प्रत्येक सेवेसाठी निवडा, आणि का ते लिहा। कोणत्या सेवेला त्याची गरज होती आणि ती काय जाहिरात करते ते नोंदवा, कारण firmware अद्ययावत ती यादी कोणालाही न सांगता बदलू शकतं।

राउटेड रचना तपासण्यायोग्य करा

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

प्रयोगशाळेच्या सामान्य गेटवेला शाखेच्या प्रीफिक्सपर्यंत परतीचा मार्ग हवा, जोपर्यंत रचना जाणूनबुजून स्रोताचं भाषांतर करत नाही, आणि सर्व्हरच्या स्वतःच्या फायरवॉलने परवानगी असलेली दूरची श्रेणी स्वीकारली पाहिजे। यापैकी काहीही यशस्वी टनेलने कॉन्फिगर होत नाही। strongSwan च्या पुढे पाठवण्याच्या टिप्पण्या तो पॅकेट मार्ग वर्णन करतात जो प्रत्येक बाजूला चालला पाहिजे।

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