VPN ठेगाना र LAN DHCP भाडा: टनेलको IP कसले दिन्छ?

क्लाइन्ट जडान गर्नुहोस् र Wi-Fi आइकनको सट्टा एडाप्टर हेर्नुहोस्। 10.80.0.14 जस्तो ठेगाना टनेलमा हुन सक्छ, तर कार्यालय LAN मा कुनै पनि DHCP सर्भरले त्यो भाडा कहिल्यै दर्ता गरेको छैन। कुन प्रक्रियाले नम्बर छान्यो भन्नेले समस्या पहिचान कहाँबाट सुरु हुने निर्धारण गर्छ।

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

क्लाइन्ट पक्षबाट टनेलको ठेगाना पढ्नुहोस्

पहिलो लाइनको सट्टा पूरै ब्लक पढ्दा Windows ले भिन्नता देखाउँछ। ipconfig /all एडाप्टर विवरण, भौतिक ठेगाना र DHCP लाइन छाप्छ। PPP वा IKEv2 डायल-अप एडाप्टरले सामान्यतया DHCP निष्क्रिय रहेको जनाउँछ, किनभने जडानले LAN सर्भरबाट भाडामा लिनुको सट्टा डायल गर्दा नै आफ्नो ठेगाना वार्ता गरेको थियो। DHCP सक्रिय भएको टनेल एडाप्टर असामान्य हो र छुट्टै अन्वेषणको योग्य छ।

Linux ले त्यही जानकारी दुई उपकरणमा बाँड्छ। ip -4 addr show dev tun0 ले ठेगाना र प्रिफिक्सको लम्बाइ दिन्छ। nmcli -f IP4 connection show work ले मान जडान प्रोफाइलबाट आयो, लिङ्कमा भएको DHCP आदानप्रदानबाट आयो वा धकेलिएको कन्फिगरेसनबाट आयो भन्ने खुलासा गर्छ। WireGuard सबैभन्दा स्पष्ट केस हो, किनभने इन्टरफेस देखा पर्दा wg-quick ले कन्फिग फाइलको Address लाइन लागू गर्छ र जडान गर्दा कुनै पियरले केही पनि बाँडफाँट गर्दैन।

प्रिफिक्सले पनि केही भन्छ। /32, वा 255.255.255.255 को मास्क, भन्नाले गेटवेले एउटै होस्ट ठेगानामा रुटिङ गर्ने अपेक्षा गर्छ, जबकि फराकिलो मास्कले टनेलको पछाडि कतै अन-लिङ्क सबनेटको संकेत गर्छ।

IKEv2 कन्फिगरेसन पेलोडले के बोक्छ

यो कामका लागि IKEv2 सँग समर्पित संयन्त्र छ। RFC 7296, खण्ड 3.15.1 मा वर्णन गरिएको कन्फिगरेसन पेलोडले INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS र तिनका IPv6 समकक्ष जस्ता विशेषताहरू बोक्छ। क्लाइन्टले प्राथमिकता नभएमा शून्य लम्बाइको मान भएको विशेषता पठाउँछ, र जवाफ दिनेले प्रयोग गर्न चाहेको मान फर्काउँछ। त्यो आदानप्रदान पहिले नै इन्क्रिप्ट भएको IKE_AUTH भित्र चल्छ, त्यसैले कुनै DHCP प्रसारण टनेल पार गर्दैन।

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

नेटमास्क विशेषता व्यवहारमा वैकल्पिक छ। धेरै परिनियोजनले केवल ठेगाना फर्काउँछन् र क्लाइन्टलाई होस्ट रुट स्थापना गर्न दिन्छन्, त्यसैले एउटै पूल एउटा क्लाइन्टमा /32 र अर्कोमा /24 जस्तो देखिन सक्छ।

जहाँ LAN DHCP दायरा र VPN पूल ठोक्किन्छन्

दुवै बाँडफाँटकर्ताले एउटै दायरालाई संकेत गर्दा समस्या सुरु हुन्छ। 10.20.30.0/24 का लागि DHCP सर्भरले 10.20.30.128/25 का लागि कन्फिगर गरिएको VPN पूलबारे केही जान्दैन, त्यसैले गेटवेले त्यही ठेगाना टाढाको क्लाइन्टलाई दिइरहेका बेला उसले 10.20.30.140 प्रिन्टरलाई भाडामा दिन रोक्ने केही छैन। ठोक्किने घटना दिनौंसम्म चुपचाप रहन्छ र पछि बेलाबेलामा आउने प्रतिको रूपमा देखा पर्छ।

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

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

ठेगाना कुन प्रक्रियाको स्वामित्वमा छ भनी जाँच्नुहोस्

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

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

जवाफ स्पष्ट भएपछि चार कुरा लेख्नुहोस्: कुन घटकले क्लाइन्ट ठेगाना बाँडफाँट गर्छ, त्यसका लागि कुन दायरा आरक्षित छ, फर्किने ट्राफिक त्यो दायरासम्म कसरी पुग्छ र कुन स्रोतले त्यसलाई स्वीकार गर्छ। ती चार प्रविष्टिले भर्चुअल एडाप्टरको एक लाइनलाई सञ्चालन तथ्यमा बदल्छ।

त्यहीँ हुँदा DNS विशेषताका लागि पनि जाँच दोहोर्याउनुहोस्। ठेगाना दिने तर रिजोल्भर नदिने पूलले क्लाइन्टलाई उसको स्थानीय DNS मा छोड्छ, जुन LAN ले पहिले नै प्रयोग गरिरहेको ठेगाना दिने पूलभन्दा फरक विफलता हो।