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 से नहीं, पैकेट-मार्ग से पुष्टि करें
सिर्फ़ पहुँच नहीं, वास्तविक मार्ग सत्यापित करें। क्लाइंट से पुष्टि करें कि कौन-सा स्रोत पता दूर की सेवा तक पहुँचता है, फिर कि जवाब उसी रास्ते लौटता है। गेस्ट पर विशिष्ट प्रवाह के लिए फ़ॉरवर्डिंग काउंटर देखें, और पोर्ट ग्रुप पर पुष्टि करें कि चुनी गई डिज़ाइन की ज़रूरत से अधिक कोई दृश्यता सक्षम नहीं की गई।
अंत में विफलता की दिशा जाँचें। टनल रोकें या क्लाइंट अलग करें और देखें कि ट्रैफ़िक चुपचाप ऐसे राउटेड मार्ग पर नहीं गिरता जिसे आपने अप्रयुक्त माना था, क्योंकि वही गिरावट ब्रिज्ड डिज़ाइन को चुपचाप अनचाहा राउटर बना देती है।