VPN मा जोडिएपछि स्थानीय IP ठेगाना द्वन्द्व सच्याउने

यी सबै रिपोर्टहरू एउटै सुनिन्छन् तर फरक अर्थ बोक्छन्: ल्यापटपले ठेगाना द्वन्द्वको गुनासो गर्छ, तर कहिलेकाहीँ मात्र, र प्रायः VPN चालु हुँदा। तीन छुट्टै खराबीले त्यो सन्देश उत्पन्न गर्छन्: तपाईंको आफ्नै लिङ्कमा साँचो नक्कल, टाढाको नेटवर्कले तपाईंको LAN दायरा प्रयोग गर्ने र केही पनि नक्कल नभएको ओभरल्याप, र एउटा ठेगाना दुई पियरलाई दिएको टनेल। सच्याउने तरिका हरेक अवस्थामा फरक हुन्छ, र गलत तरिकाले लक्षण हटाउनुको सट्टा सार्छ। त्यसैले केही पनि परिवर्तन गर्नु अघि तपाईंसँग कुन अवस्था छ भनी निर्णय गर्नुहोस्।

एउटै त्रुटि सन्देश बाँड्ने तीन खराबी

नक्कल भन्नाले एउटै सेगमेन्टका दुई मेसिनले एउटै ठेगाना दाबी गर्नु हो। कर्नेलले यो थाहा पाउँछ किनभने यसको आफ्नै प्रोबको जवाफ अर्को MAC बाट आउँछ, र त्यसपछि के हुन्छ त्यो स्ट्याकमा निर्भर गर्छ: Linux ले लग गर्छ, Windows ले इन्टरफेस बन्द गरेर प्रणाली लगमा प्रविष्टि लेख्छ, र DHCP क्लाइन्टले प्रस्ताव अस्वीकार गर्न सक्छ।

ओभरल्यापले कुनै पनि ठेगाना नक्कल गर्दैन। तपाईंको LAN 192.168.1.0/24 हो, अफिस नेटवर्क पनि 192.168.1.0/24 हो, र अब अफिस जाने मार्गले तपाईंको प्रिन्टर र NAS पनि भएका ठेगानाहरू देखाउँछ। ARP अर्थमा केही पनि द्वन्द्वमा छैन; प्याकेट दुई नेटवर्कमध्ये एउटामा गलत यन्त्रतिर जान्छ।

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

परीक्षण 1: नक्कल तपाईंको आफ्नै सेगमेन्टमा छ?

तपाईंको मेसिनसँग वास्तवमा के छ त्यसको सूचीबाट सुरु गर्नुहोस्, तपाईंले कन्फिगर गरेको सम्झेको कुराबाट होइन। VPN एडाप्टरको ठेगाना टनेलका लागि निजी हुन्छ र वेबसाइटहरूले देख्ने ठेगाना त्यो होइन, त्यसैले साझा सार्वजनिक निकास द्वन्द्व होइन।

ip -br addr
ip neigh
ip route show table all | grep -E 'wg|tun|ppp'

Windows मा उही जानकारी ipconfig /all र Get-NetIPAddress बाट आउँछ, छिमेकी क्यास arp -a मा छ। यदि विवादित ठेगाना भौतिक एडाप्टरमा छ र VPN नचलेको अवस्थामा पनि गुनासो देखिन्छ भने, VPN यहाँ दर्शक मात्र हो र तपाईंले यसको समस्या खोज्न छोड्नुपर्छ।

अनुमान गर्नुको सट्टा नक्कल प्रमाणित गर्न, ठेगाना नहुने यन्त्रबाट प्रोब गर्नुहोस्। arping -D ले प्रोब शून्य स्रोत ठेगानासँग पठाउँछ, त्यसैले अप्रत्याशित MAC बाट आएको जवाफले अर्को होस्टले पहिले नै त्यो ठेगानाको जवाफ दिइरहेको प्रमाणित गर्छ।

sudo arping -D -I eth0 -c 3 192.168.1.50

त्यसपछि आफैं अर्को ठेगाना छान्नुको सट्टा नेटवर्क प्रशासकमार्फत मालिक खोज्नुहोस्। कसैको टिप्पणीमा मात्र रहेका स्थिर तोकाइ, स्थिर ठेगाना भएका प्रिन्टर र DHCP सर्भरमा गरिएका आरक्षण सामान्य दोषी हुन्, र बन्द गरिएको यन्त्रले पनि आफ्नो लिजको मालिक हुन्छ।

परीक्षण 2: दुई नेटवर्क ओभरल्याप हुन्छन्?

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

ip route get 192.168.1.10
ip -br addr show

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

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

अफिस नेटवर्क पुनः नम्बर गर्ने निर्णय विरलै तपाईंको हुन्छ। टक्करबाट बच्न आफ्नै LAN पुनः नम्बर गर्नु प्रिन्टर, क्यामेरा र स्थिर होस्ट संलग्न भएपछि धेरैले अपेक्षा गरेभन्दा ठूलो परिवर्तन हो।

परीक्षण 3: टनेलले एउटै ठेगाना दुई पटक दियो?

WireGuard सँग ठेगाना पूल छैन। प्रत्येक पियर आफ्नो सार्वजनिक कुञ्जी र AllowedIPs मा भएका प्रिफिक्सले चिनिन्छ, त्यसैले एउटै टनेल ठेगाना दुई पियर प्रविष्टिमा लेखिँदा वा एउटै कुञ्जी जोडी दुई मेसिनमा स्थापना गर्दा नक्कल देखिन्छ।

wg show all allowed-ips
wg show wg0 latest-handshakes
wg show wg0 transfer

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

OpenVPN सँग पूल छ, र सामान्य टक्कर स्थिर --ifconfig लाइन भएको साझा क्लाइन्ट प्रोफाइल दोस्रो मेसिनमा प्रतिलिपि गर्दा हुन्छ। त्यसपछि दुवै क्लाइन्टले एउटै टनेल ठेगाना माग्छन्, र सर्भरले पहिले प्रशोधन गरेको सत्र स्वीकार गर्छ। --duplicate-cn सँग पूल सकिँदा एउटै प्रमाणपत्रका धेरै सत्रले एउटै प्रविष्टिका लागि प्रतिस्पर्धा गर्दा त्यस्तै नतिजा आउँछ।

यसका लागि क्लाइन्ट लगको सट्टा सर्भर लग पढ्नुहोस्। कुन सत्रले कुन ठेगाना दाबी गर्यो सर्भरलाई थाहा हुन्छ, र त्यहाँ दोहोरिएका ठेगानाहरू क्लाइन्टसम्म कहिल्यै नपुग्ने चेतावनीका रूपमा देखिन्छन्।

स्रोतमै सच्याउनुहोस्, त्यसपछि दुवै यन्त्र जाँच्नुहोस्

क्रम महत्त्वपूर्ण छ। पहिले LAN को नक्कल सच्याउनुहोस्, किनभने ठेगाना राख्न नसक्ने क्लाइन्टले टनेल पनि राख्न सक्दैन। त्यसपछि VPN पक्षको प्रोभिजनिङ सच्याउनुहोस्, किनभने क्लाइन्टमा गरिएको पूल तोकाइको सम्पादन अर्को जडानमा रद्द हुन्छ। अन्तमा दोहोरिएका पहिचानसँग व्यवहार गर्नुहोस्: WireGuard मा छुट्टै कुञ्जी जोडी, OpenVPN मा छुट्टै प्रमाणपत्र वा कम्तीमा छुट्टै प्रोफाइल।

क्लाइन्टमा यान्त्रिक भाग छोटो हुन्छ। DHCP लिज छोडेर नवीकरण गर्नुहोस्, वा आरक्षणका लागि सर्भरमा ठेगाना परिवर्तन गर्न अनुरोध गर्नुहोस्। खाली देखिने अनियमित ठेगाना नलेख्नुहोस्।

sudo dhclient -r eth0 && sudo dhclient eth0
ipconfig /release && ipconfig /renew

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

बाटोमा के नगर्ने

लक्षणलाई चुप नबनाउनुहोस्। दोहोरिएका ठेगानाको पहिचानले नै तपाईंलाई पहिले नै प्रयोगमा रहेको ठेगाना लिनबाट रोक्छ, र यसलाई बन्द गर्दा देखिने द्वन्द्वलाई पत्ता लगाउन धेरै गाह्रो हुने रहरमा हुने प्याकेट हानिमा बदल्छ। अप्रत्याशित होस्टबाट आएको प्रमाणपत्र चेतावनी स्वीकार गर्ने कुरामा पनि यही लागू हुन्छ: त्यो ठेगानाको समस्या नै होइन, र त्यसमाथि क्लिक गर्दा अर्को खराबी लुक्छ।

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