एक ही सबनेट वाली दो साइटें एक LAN क्यों नहीं हैं

दो दफ़्तर दोनों 192.168.77.0/24 का उपयोग करते हैं, और कोई सुझाव देता है कि एक टनल बनाई जाए ताकि वे एक ही नेटवर्क हों। यह वाक्य सरल लगता है और तीन अलग डिज़ाइन छिपाता है: दो स्वतंत्र LAN जो टकराती हैं, एक जान-बूझकर WAN पर खींचा गया ईथरनेट सेगमेंट, और एक proxy-ARP व्यवस्था जो दूर के पतों की ओर से जवाब देती है। आपके पास इनमें से कौन है यह तय करता है कि होस्ट पैकेट का क्या करता है, और जवाब VPN गेटवे शामिल होने से पहले दिखता है।

होस्ट राउटर से पहले तय करता है

192.168.77.10/24 पता वाला होस्ट गंतव्य की तुलना अपने प्रीफ़िक्स से करता है। उस प्रीफ़िक्स के भीतर सब कुछ सीधे लिंक पर है, इसलिए होस्ट गंतव्य का लिंक-लेयर पता सीधे हल करता है। बाहर का सब कुछ डिफ़ॉल्ट गेटवे पर जाता है।

यह निर्णय होस्ट के स्टैक में होता है, टनल में नहीं। गेटवे पर जोड़ा गया रूट उस पैकेट को नहीं बचा सकता जिसे होस्ट कभी वहाँ नहीं भेजता।

इसलिए जब 192.168.77.20 केवल दूसरी साइट पर मौजूद है, स्थानीय होस्ट उसके लिए ARP करता है और कोई जवाब नहीं पाता। VPN हैंडशेक पूरी तरह स्वस्थ हो सकता है जबकि यह विफल होता है। यह विफलता राउटिंग समस्या की तरह नहीं, मृत होस्ट की तरह दिखती है। इस संकेत को पहचानना टनल डिबगिंग का एक घंटा बचाता है।

ARP स्थानीय लिंक का सवाल है

ARP पूछता है कि इस लिंक पर पता किसका है, और जवाब ऐसी चीज़ से आना चाहिए जो प्रसारण सुन सके। IPsec टनल के दूसरे सिरे पर बैठा राउटर उसे नहीं सुनता, जब तक डिज़ाइन दोनों साइटों को एक प्रसारण डोमेन न बना दे।

एक ही पते वाले दो डिवाइस स्थिति को बदतर बनाते हैं: सफल समाधान भी नहीं बता सकता कि किसने जवाब दिया।

दोहराया गया पता राउटिंग की गड़बड़ी नहीं है और कोई रूट उसे ठीक नहीं करता। या तो साइटों को अलग प्रीफ़िक्स में फिर से नंबर दिया जाता है, या वे जान-बूझकर एक ही लिंक-लेयर डोमेन बन जाती हैं।

खींचा गया सेगमेंट फ़्रेम ले जाता है, रूट नहीं

ब्रिज से जुड़ी ईथरनेट ले जाने वाली टनल दोनों साइटों को एक ही लिंक-लेयर डोमेन का हिस्सा बनाती है। ARP प्रसारण दूसरी ओर पहुँचते हैं, और हर ब्रिज सीखता है कि कौन से MAC पते कहाँ हैं। Linux ब्रिज दस्तावेज़ उस MAC-आधारित अग्रेषण सीमा का वर्णन करते हैं।

यहाँ दूर का गेटवे दो समान सबनेट के बीच राउटिंग बिलकुल नहीं करता। फ़्रेम ऐसे अंडरले से गुज़रते हैं जो खुद IP राउट करता है, जबकि ब्रिज ईथरनेट बातचीत को बढ़ाते हैं।

कीमत बड़ा प्रभाव-दायरा है। अज्ञात गंतव्यों के लिए फ़्लडिंग, लूप, DHCP आवंटन और अनोखा पता—सब के लिए एक ऐसी योजना चाहिए जो दोनों साइटों को समेटे। WAN गिरने पर होस्ट वह ट्रैफ़िक खो देते हैं जिसे वे स्थानीय मानते हैं। ब्रिज पर फ़िल्टरिंग और VLAN नियम सीमित कर सकते हैं कि क्या पार होता है, पर ढुलाई अब भी वादा नहीं करती कि हर स्थानीय नियंत्रण फ़्रेम पहुँचेगा।

Proxy ARP तीसरा डिज़ाइन है

राउटर दूर के पते के लिए ARP का जवाब दे सकता है और फिर उसकी ओर राउट कर सकता है। इससे दूर का होस्ट भेजने वाले को सीधे लिंक पर दिखता है बिना प्रसारण डोमेन खींचे।

यह ब्रिजिंग से संकरा औज़ार है: यह अग्रेषण, वापसी रूट और हर पते के स्पष्ट मालिक पर निर्भर है।

यह मनमाने गैर-IP प्रोटोकॉल को राउट करने योग्य भी नहीं बनाता, और ईथरनेट प्रसारण डोमेन नहीं दोहराता। इसका उपयोग तब करें जब आवश्यकता ठीक यही प्रतिस्थापन हो, टाले गए पुनर्संख्यन के शॉर्टकट के रूप में नहीं।

आवश्यकता से चुनें, फिर जाँचें

दफ़्तरों के बीच सामान्य अनुप्रयोग पहुँच के लिए अलग प्रीफ़िक्स और स्पष्ट रूट साफ़ सीमा देते हैं। ब्रिज तब करें जब आवश्यकता वास्तव में लिंक-लेयर निकटता हो। फिर से नंबर तब दें जब साझा प्रीफ़िक्स की एकमात्र वजह यह हो कि किसी ने अभी तक यह नहीं किया।

पुष्टि करें कि वास्तव में कौन सा डिज़ाइन आपके पास है होस्ट से पूछकर कि वह गंतव्य के साथ क्या करता है:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

विफल पड़ोसी प्रविष्टि के साथ सीधे-लिंक वाला परिणाम अनुपस्थित लिंक-लेयर पथ की ओर इशारा करता है। via परिणाम गेटवे का नाम लेता है और सवाल को राउटिंग की ओर ले जाता है। ब्रिज पर, अग्रेषण डेटाबेस देखें कि MAC टनल के पार सीखा गया था या नहीं। हर आउटपुट डिज़ाइन के सवाल को फिर से शुरू करने के बजाय सँकरा करता है।