VPN ला जोडल्यानंतर स्थानिक IP पत्त्याचा संघर्ष सोडवा
डुप्लिकेट तुमच्या LAN वर असू शकते, ओव्हरलॅप होणाऱ्या दूरच्या श्रेणीतून येऊ शकते, किंवा टनेल पूलमधून दोनदा दिले गेले असू शकते. पुन्हा क्रमांक देण्यापूर्वी चाचणी करा.
यातील प्रत्येक अहवाल सारखाच वाटतो आणि वेगळा अर्थ देतो: लॅपटॉप पत्त्याच्या संघर्षाची तक्रार करतो, पण फक्त कधीतरी, आणि बहुतेक वेळा 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 पत्ता-संघर्ष ओळखीचे नियम योग्य प्रोब काय सिद्ध करतो ते स्पष्ट करतात, संघर्षाला खरा म्हणण्यापूर्वी हे जाणून घेणे योग्य आहे.