शाखा र प्रयोगशालाबीचको लिंकका लागि रुटेड 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 कन्सोल चाहिँदैन, र नीति वास्तविक छ भनी जान्ने एउटै उपाय भनेको अस्वीकार गर्नुपर्ने कुरा नै प्रयास गर्नु हो। प्रिफिक्स, रिजोल्भरमा निर्भरता र परीक्षण नतिजा टिपोट गर्नुहोस्, र कुनै पनि साइटको भावी परिवर्तन स्मृतिबाट पुनः बनाउनुको सट्टा मिनेटमा हेर्न सकिन्छ।