एकाच सबनेट असलेल्या दोन साइट्स एक 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 बोगद्यातून शिकला गेला का हे पाहण्यासाठी अग्रेषण डेटाबेस तपासा। प्रत्येक आउटपुट रचनेचा प्रश्न पुन्हा सुरू न करता आकुंचित करतो।