तपाईंको VPN पूल LAN को DHCP दायरा होइन: यो किन बिग्रन्छ

लोभ्याउने छोटो बाटो भनेको VPN क्लाइन्टहरूलाई कार्यालयको DHCP सर्भरले प्रयोग गर्ने त्यही दायराबाट ठेगाना दिनु हो, सबै कुरा जसरी पनि एउटै नेटवर्क हो भन्ने सोचमा। तर होइन। राउटेड टनेलले दुई छेउबीच unicast प्याकेट बोक्छ, जबकि LAN पूल भौतिक खण्डमा ब्रोडकास्ट अनुरोधको जवाफ दिन अवस्थित हुन्छ। ती नम्बरहरू फेरि प्रयोग गर्दा दुई वितरक एउटै ठेगाना क्षेत्रको जिम्मेवार बन्छन् र फिर्ती मार्ग अपरिभाषित रहन्छ।

दुई वितरक, एउटै ठेगाना क्षेत्र

LAN को DHCP सर्भरलाई थाहा छ उसले कुन ठेगाना कुन MAC ठेगानालाई भाडामा दियो, र ARP ले तिनको रक्षा गर्छ। VPN सर्भरसँग आफ्नै पूल छ र ती भाडाहरूबारे केही थाहा छैन। दुवै गलत छैनन्; तिनीहरूको कहिल्यै चिनापरिचय गराइएन।

VPN सर्भरले LAN पूलबाट दिने ठेगाना पहिले नै कुनै प्रिन्टरको हुन सक्छ। अब दुई उपकरणले एउटै प्रिफिक्समा एउटै ठेगाना दाबी गर्छन्, र स्विचको फर्वार्डिङ तालिकाले कसले जवाफ दिने निर्धारण गर्छ।

मानिसहरूले सबैभन्दा पहिले भेट्ने खराबी यही हो: सफलतापूर्वक जोडिने र त्यसपछि गलत मेसिनमा पुग्ने क्लाइन्ट, वा सही मेसिनमा बीचबीचमा पुग्ने क्लाइन्ट।

राउटरले VPN ठेगाना किन बाँड्दैन

DHCP खोज ब्रोडकास्ट हो, र ब्रोडकास्ट राउटेड सीमामा रोकिन्छ। यदि डिजाइनले टनेल ब्रिज गर्दैन वा मिल्दो अधिकार भएको DHCP रिले चलाउँदैन, क्लाइन्टको अनुरोध कहिल्यै LAN सर्भरमा पुग्दैन।

त्यसैले VPN सर्भरले आफैं ठेगाना तोक्छ: सर्भर कन्फिगरेसनमा एउटा पूल, WireGuard सेटअपमा प्रत्येक पीयरका लागि एउटा ठेगाना, वा IKEv2 परिनियोजनमा प्रमाणीकरण तहले धकेल्ने ठेगाना। यी संयन्त्रहरू LAN को भाडा डेटाबेसबाट स्वतन्त्र छन्, र त्यसैले तिनलाई आफ्नै दायरा चाहिन्छ।

त्यही तर्कले बताउँछ कि DHCP स्कोप बदल्दा कहिल्यै ठेगाना नपाउने VPN क्लाइन्ट किन सुध्रिँदैन। क्लाइन्टले LAN सर्भरलाई सोधिरहेको छैन, र स्कोप सम्पादनले जतिसुकै पनि उसलाई सोध्न बाध्य पार्दैन।

ओभरल्याप सुस्त नेटवर्कको रूपमा होइन, द्वन्द्वको रूपमा देखिन्छ

समर्थित डिजाइन बिना एउटै प्रिफिक्स साझा गर्ने दुई नेटवर्क दोहोरो स्वामित्वभन्दा फरक समस्या हुन्, र तिनलाई प्रायः गल्याइन्छ। यदि VPN पूल अलग प्रिफिक्स हो भने, कुनै मार्गले ट्राफिक गलत तर्फ पठाउँदा मात्र ओभरल्याप महत्त्वपूर्ण हुन्छ। यदि पूल LAN प्रिफिक्सभित्र छ भने, द्वन्द्व तत्काल र स्थानीय हुन्छ।

व्यवहारमा तपाईंले गलत उपकरणबाट ARP जवाफ, बीचमा रिसेट हुने जडान, र आफ्नै ठेगाना अरू कसैले दाबी गर्ने क्लाइन्ट देख्नुहुन्छ। यीमध्ये कुनै पनि राउटिङ समस्याजस्तो देखिँदैन, त्यसैले सुधार गलत तहमा लगाइन्छ। दोहोरो भाडा पुष्टि गर्न सजिलो र त्यससँग बाँच्न झन्झटिलो छ। यो रिबुटपछि पनि टिक्छ, किनकि दुवै वितरक एउटै ठेगानामा अड्डी राख्छन्।

फिर्ती मार्ग अलग समस्या हो

सफा र अलग पूल भए पनि, LAN होस्टहरूलाई क्लाइन्टलाई कसरी जवाफ दिने भन्ने थाहा हुनुपर्छ। तिनको पूर्वनिर्धारित गेटवे राउटर हो, र राउटरलाई पूलका लागि VPN सर्भरतर्फ देखाउने मार्ग चाहिन्छ, जबसम्म डिजाइनले त्यसको सट्टा क्लाइन्ट ट्राफिक अनुवाद गर्दैन।

केही बदल्नुअघि मार्ग दुवै दिशामा पढ्नुहोस्। गेटवेमा सोध्नुहोस् कि कर्नेलले क्लाइन्ट ठेगानाका लागि कुन इन्टरफेस प्रयोग गर्छ; क्लाइन्टमा सोध्नुहोस् कि यसले LAN ठेगानाका लागि कुन मार्ग प्रयोग गर्छ।

यी आदेशहरूले गेटवेमा फर्वार्डिङ निर्णय र नक्कल खुलासा गर्ने छिमेकी प्रविष्टिहरू देखाउँछन्:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

यदि पहिलो आदेशले टनेल इन्टरफेससँग जवाफ दिन्छ भने फिर्ती मार्ग अवस्थित छ। यदि यसले LAN इन्टरफेससँग जवाफ दिन्छ भने राउटरले क्लाइन्ट तारमा छ भन्ने ठान्छ र उसका लागि ARP गर्न प्रयास गर्नेछ।

ब्रिज गरिएका डिजाइनहरू छन्, तर तिनीहरू छान्नुपर्छ

टनेललाई LAN सँग ब्रिज गर्नु वास्तविक डिजाइन हो, जुन क्लाइन्टहरूले ब्रोडकास्ट पाउनुपर्दा वा एउटै खण्ड मान्ने प्रोटोकलहरूले तिनलाई पत्ता लगाउनुपर्दा प्रयोग गरिन्छ। यसका लागि सर्भरसँग त्यो ब्रिजिङ व्यवहार र त्यससँगै आउने ठेगाना व्यवस्थापन हुनुपर्छ।

जे चल्दैन त्यो नम्बर कपी गरेर नतिजाको नक्कल गर्नु हो। ब्रिज बिनाको साझा पूलले तपाईंलाई खोज बिना द्वन्द्व दिन्छ, जो दुवै व्यवस्थामध्ये सबैभन्दा नराम्रो हो।

एप्लिकेसनलाई साँच्चै खण्ड चाहिएन भने अलग पूलसँग तेस्रो तह छान्नुहोस्, र पूलको अभिलेख राख्नुहोस् ताकि अर्को प्रशासकले सफाइका लागि DHCP दायरा फेरि प्रयोग नगरोस्।