एउटै सबनेट भएका दुई साइटहरू एउटै 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 सुरुङबाट सिकियो कि भनी हेर्न अग्रसारण डेटाबेस जाँच्नुहोस्। प्रत्येक आउटपुटले डिजाइनको प्रश्न पुनः सुरु नगरी साँघुरो बनाउँछ।