ESXi गेस्ट VPN: राउटिङ वा ब्रिजिङ — पोर्ट समूहअघि निर्णय गर्नुहोस्
राउटेड TUN लाई फर्कने रुट चाहिन्छ; ब्रिज्ड TAP लाई तह 2 पहुँच र फराकिलो पोर्ट-समूह नीति चाहिन्छ। promiscuous मोड फराकिलो बनाउनुअघि भूमिका तय गर्नुहोस्।
प्याकेट राउट गर्नुहोस् वा Ethernet डोमेन विस्तार गर्नुहोस्: पोर्ट समूहको परिवर्तन त्यो छनोटपछि आउँछ। निजी ठेगाना भएको अनुप्रयोगबाट नतिजा एउटै देखिन सक्छ, तर हाइपरभाइजरका आवश्यकता पूरै फरक हुन्छन्। त्यसैले पहिले पोर्ट समूह फराकिलो बनाइन्छ र डिजाइनको प्रश्न दोस्रोमा जवाफ पाउँछ, सामान्यतया ब्रोडकास्ट आँधीपछि। यी जाँचहरू क्रममा गर्नुहोस् र आवश्यकता अझै अस्पष्ट छँदै रोक्नुहोस्, किनकि कुनै पनि पोर्ट-समूह सेटिङले कहिल्यै नछानिएको डिजाइन सुधार्दैन।
निर्णय सेवाको मालिकको हो; हाइपरभाइजर कन्फिगरेसनले त्यसलाई लागू गर्नुपर्छ, दुर्घटनावश निर्धारण गर्नु हुँदैन।
टाढाको छेउलाई वास्तवमा के चाहिन्छ जाँच्नुहोस्
टाढाका ग्राहकले पुग्नुपर्ने सेवाहरू र उनीहरूले प्रयोग गर्ने प्रोटोकलहरू सूचीबद्ध गर्नुहोस्। सूची ज्ञात प्रिफिक्समा केही TCP सेवा भए राउटिङले पुग्छ। यदि कुनै कुरालाई साँच्चै तह 2 को निकटता चाहिन्छ — ब्रोडकास्टमा निर्भर खोज, गैर-IP प्रोटोकल, गेटवे नस्वीकार्ने उपकरण — राउटिङले त्यसको नक्कल गर्न सक्दैन र यो चाँडै भन्नुपर्छ। त्यो सूचीका गैर-IP प्रविष्टिबारे इमानदार रहनुहोस्, किनकि त्यहीँ राउटेड डिजाइन एक हप्तापछि चुपचाप असफल हुन्छ।
त्यसपछि ग्राहक पूल जाँच्नुहोस्। राउटेड डिजाइनलाई ठेगाना दायरा र टाढाको छेउमा स्पष्ट फर्कने रुट चाहिन्छ; ब्रिज्ड डिजाइनलाई विस्तारित Ethernet डोमेनसँग ठेगाना बाँडफाँट र अलगाव हुनुपर्छ। तपाईंले जे रोज्नुभए पनि, यो VM बाहिरको कसैले त्यसमा सहमत हुनुपर्छ।
प्रत्येक डिजाइनले भर्चुअल नेटवर्कसँग के माग्छ
दुई डिजाइन भर्चुअल नेटवर्कले के सहनुपर्नेमा फरक छन्, र त्यो हेर्ने सबैभन्दा छोटो बाटो तालिका हो:
| डिजाइन | गेस्ट पक्षको भूमिका | भर्चुअल नेटवर्कले के समेट्नुपर्छ | गलत रोज्दा असफलताको ढाँचा |
|---|---|---|---|
| राउटेड TUN | अलग प्रिफिक्सबीचको राउटर | राउटेड ग्राहक पूल र टाढाको छेउमा फर्कने बाटा | ग्राहक गेटवेसम्म पुग्छन् तर त्यसपछाडिको सेवासम्म कहिल्यै पुग्दैनन् |
| ब्रिज्ड TAP | सहभागी हुने ग्राहकका लागि तह 2 ब्रिज | थप Ethernet पहिचान, ब्रोडकास्ट ट्राफिक र VLAN नियम | vSwitch फ्रेम खसाल्छ, वा डिजाइनलाई कसैले स्वीकृत नगरेको promiscuous मोड चाहिन्छ |
राउटिङले ब्रोडकास्ट डोमेन जहाँ छ त्यहीँ राख्छ र गेटवे काट्ने सेवा सीमित गर्न प्राकृतिक ठाउँ दिन्छ। ब्रिजिङले सीमा सार्छ: ग्राहक विस्तारित Ethernet डोमेनका सहभागी बन्छन्, र ठेगाना बाँडफाँट, अलगाव तथा कुनै पनि तह 2 नीति अब उनीहरूलाई लागू हुन्छ। छानिएको पंक्ति परिवर्तन-अभिलेखमा लेख्नुहोस्। “राउटेड TUN, ग्राहक पूल 10.90.0.0/24, कोरमा फर्कने रुट” जस्तो वाक्यले अर्को इन्जिनियरलाई पोर्ट-समूह सेटिङबाट डिजाइन फेरि बहस गर्नबाट रोक्छ।
कसले कसको फ्रेम देख्न पाउने
पोर्ट समूह छुनुअघि प्लेटफर्म मालिकलाई एउटा प्रश्न सोध्नुहोस्: के डिजाइनले यो VM ले अरू सहभागीलाई सम्बोधित फ्रेम प्राप्त गर्नुपर्ने माग गर्छ? जवाफ होइन भए यो खण्डको केही लागू हुँदैन, किनकि राउटेड TUN लाई त्यो दृश्यता कहिल्यै चाहिँदैन। जवाफ हो भए, promiscuous मोडबारे Broadcom को मार्गदर्शन मुख्य पढाइ हो: VM ले vSwitch बाट कति बढी देख्न सक्छ भनी यसले बताउँछ र त्यो नीति एउटा पोर्ट समूहमा सीमित राख्न सिफारिस गर्छ।
यसलाई अनुमतिपत्र होइन, आवश्यकताको जाँच ठान्नुहोस्। ब्रिजिङको आवश्यकता लिखित भएपछि एउटा समर्पित जडानका लागि सेटिङ खोल्नुहोस्, र अरू सबै ठाउँमा बन्द राख्नुहोस्। अर्को ब्रिज उदाहरणबाट प्रतिलिपि गरिएको फराकिलो VLAN ट्रंक हटाउन कसैलाई सम्झना नहुने भाग हो, र एक-VLAN डिजाइन एक-VLAN नै रहनुपर्छ।
कुन पोर्ट समूह परिवर्तन भयो र किन, डिजाइनको पंक्ति लेखेकै ठाउँमा अभिलेख गर्नुहोस्। त्यही जोडीले अर्को अडिट सम्भव बनाउँछ।
गेस्टका वस्तु स्पष्ट राख्नुहोस्
Linux भित्र, ब्रिज सदस्यता र ठेगानाको स्वामित्व छुट्टाछुट्टै वस्तु हुन्, र तिनलाई मिसाउँदा भ्रमित आधा-काम गर्ने अवस्था बन्छ। ठेगाना ब्रिज इन्टरफेस वा राउटेड टनेललाई दिनुहोस्, एउटै बाटोका दुवै छेउलाई होइन, र सदस्य पोर्टलाई IP कन्फिगरेसनबाट मुक्त राख्नुहोस्।
एउटा सबनेट स्वतन्त्र रूपमा राउटेड TUN मा र असम्बन्धित Ethernet इन्टरफेसमा राख्नबाट बच्नुहोस्। त्यस्तो कन्फिगरेसनले एउटै प्रिफिक्समा दुई बाटा उत्पन्न गर्छ, असममित जवाफ र flapping बारे दुवै बाटामध्ये कुनैको उल्लेख नगर्ने समर्थन थ्रेड। यदि गेस्टले कन्टेनर वा स्थानीय हाइपरभाइजर पनि होस्ट गर्छ भने, तिनीहरू पहिल्यै त्यही uplink मा ब्रिज गरिरहेका छैनन् भनी जाँच्नुहोस्। एउटा NIC मा दुई ब्रिज डिजाइन हो, परिवर्तन-विन्डोमा पत्ता लगाउन चाहने दुर्घटना होइन।
ping ले होइन, प्याकेट-बाटोले पुष्टि गर्नुहोस्
पहुँच मात्र होइन, वास्तविक बाटो प्रमाणित गर्नुहोस्। ग्राहकबाट कुन स्रोत ठेगाना टाढाको सेवामा पुग्छ भनी पुष्टि गर्नुहोस्, त्यसपछि जवाफ त्यही बाटोले फर्कन्छ भनी पुष्टि गर्नुहोस्। गेस्टमा निश्चित प्रवाहका लागि फर्वार्डिङ काउन्टर हेर्नुहोस्, र पोर्ट समूहमा छानिएको डिजाइनको आवश्यकताभन्दा बढी दृश्यता सक्रिय गरिएको छैन भनी पुष्टि गर्नुहोस्।
अन्तमा असफलताको दिशा परीक्षण गर्नुहोस्। टनेल रोक्नुहोस् वा ग्राहक अलग गर्नुहोस् र ट्राफिक चुपचाप नचलाइएको भन्ठानिएको राउटेड बाटोमा नखस्ने कुरा जाँच्नुहोस्, किनकि त्यही खसाइले ब्रिज्ड डिजाइन चुपचाप अनिच्छित राउटर बन्छ।