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 के पता-टकराव पहचान नियम बताते हैं कि सही प्रोब क्या साबित करता है, जो टकराव को असली कहने से पहले जानना ज़रूरी है।