WireGuard एकाच वेळी ताजा हँडशेक आणि पत्ता नसणे अशा दोन्ही अवस्थांत राहू शकतो, आणि ती अवस्था विरोधाभासी नसून सुसंगत आहे. हँडशेक पीअरची घटना आहे, पत्ता इंटरफेसचा आहे, आणि पॅकेट कोणत्या अपलिंकने बाहेर पडते हे राउट ठरवते. तीन स्तर, तीन मालक, आणि उरलेले दोन निरोगी दिसत असतानाही प्रत्येक बिघडू शकतो.

त्यांना एकच स्थिती म्हणून वाचणे हेच दोन मिनिटांचे निदान सेवा पुन्हा सुरू करण्यात जाणाऱ्या पूर्ण दुपारीत बदलते.

हँडशेक पीअरची घटना आहे, पत्ता देण्याची घटना नाही

WireGuard चा हँडशेक सिद्ध करतो की संरचित पीअरने वैध किल्लीसह उत्तर दिले आणि सत्र किल्ल्या चालू आहेत. तो इंटरफेसवरील स्थानिक पत्त्याबद्दल काहीच सांगत नाही, आणि कोणताही राउट तिकडे निर्देश करतो का याबद्दलही नाही. पत्ता सहाय्यक किंवा नेटवर्क व्यवस्थापक देतो, तर प्रोटोकॉल संरचना फक्त पीअर आणि किल्ल्यांची नावे घेते. या दोन्हींचा गोंधळ हाच निरोगी हँडशेकला कार्यरत बोगदा म्हणून वाचण्याचे कारण आहे.

म्हणूनच wg show अनुप्रयोगाकडून एकही पॅकेट घेऊ शकत नाही अशा इंटरफेसवर काही सेकंद जुन्या हँडशेकची नोंद करू शकतो.

इंटरफेस पुन्हा तयार करणारा व्यवस्थापक पीअर संरचनेला हात न लावता पत्ता टाकू शकतो, आणि पुढील हँडशेक लगेच यशस्वी होतो कारण किल्ल्या कधीच बदलल्या नाहीत. यशस्वी हँडशेकबद्दलची लॉग ओळ अचूक आहे आणि बिघाडाशी असंबंधित आहे.

ObservationWhich layer it belongs toWrong conclusion it invites
Handshake a few seconds oldPeer and keysThe tunnel is usable for application traffic
Address present on wg0Interface configurationTraffic actually egresses through it
Route points at wg0Forwarding tableThe outer packet uses the intended uplink

इंटरफेसच्या पत्त्याचा स्वतःचा मालक असतो

बोगदा उपकरणावरील पत्ता सहाय्यकाच्या Address ओळीतून, इंटरफेसवर चालणाऱ्या DHCP क्लायंटकडून, किंवा जोडणीच्या वेळी तो तयार करणाऱ्या व्यवस्थापन डेमनकडून येऊ शकतो. कोणतेही असो, तो घटक पत्त्याचा मालक आहे आणि स्वतःच्या तर्कानुसार तो पुनर्संचयित करेल किंवा करणार नाही. मालकाचे नाव न घेता पत्ता वाचल्यास तो का गायब झाला हे सांगता येणार नाही.

एका इंटरफेसवर दोन मालक हा नेहमीचा बिघाड आहे. एकाच उपकरणावर सहाय्यक आणि डेस्कटॉप नेटवर्क व्यवस्थापक सुरू केल्यास एकाने दुसऱ्याने नुकतेच संरचित केलेले काढून टाकण्याची शर्यत होते, आणि अंतबिंदू त्या सर्व वेळेत उत्तर देत राहतो.

एक मालक निवडा आणि दुसऱ्या साधनाला व्यवस्थापनाऐवजी निरीक्षण करू द्या. तो निर्णय लिहून ठेवण्यासारखा आहे, कारण लक्षण आठवड्यांनंतर दिसते आणि पत्ता अचानक गेल्यासारखे वाटते.

अपलिंक राउट निवडतो, इंटरफेस नाही

wg0 कडे निर्देश करणारा अंतर्गत राउट रहदारी बोगद्यात प्रवेश करते हे ठरवतो. वेगळा निर्णय कूटबद्ध बाह्य पॅकेट्स पीअरकडे पाठवतो, आणि अनेक अपलिंक असलेल्या होस्टवर तो निर्णय फॉरवर्डिंग तक्ता आणि धोरण नियमांतून येतो. Wi-Fi रोमिंग अंतर्गत पत्त्याला हात न लावता बाह्य मार्ग बदलू शकते.

म्हणून कार्यरत बोगदा आणि अगम्य पीअर या सुसंगत अवस्था आहेत, आणि योग्य पीअर व तुटलेला अंतर्गत राउटही तसेच. तीन निरीक्षणे एकत्र, एकाच क्षणी घ्यावी लागतात, अन्यथा तुलना निरर्थक ठरते.

तीन अवस्थांची एकाच पासमध्ये तुलना करा

फक्त-वाचनाच्या तीन आज्ञा तीन प्रश्नांची उत्तरे अशा क्रमाने देतात की ज्यामुळे बिघाड सर्वात लवकर वेगळा होतो. त्यांच्यामध्ये काहीही न बदलता त्या चालवा.

ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transfer

पहिली इंटरफेसकडे पत्ता आहे का हे दाखवते, आणि दुसरी एखादे विशिष्ट गंतव्य आता कोणते उपकरण वापरेल हे दाखवते. तिसरी शेवटच्या हँडशेकची वेळ आणि बाइट काउंटर नोंदवते, आणि तीनपैकी स्थानिक होस्टऐवजी पीअरचे वर्णन करणारी ती एकमेव आहे.

टाइमस्टॅम्पसोबत काउंटरही वाचा. हस्तांतरण सपाट असताना सतत नूतनीकरण होणारा हँडशेक म्हणजे पीअर उत्तर देतो पण काही उपयुक्त पुढे जात नाही, जे किल्ल्यांकडे नव्हे तर राउटिंग किंवा ACL कडे निर्देश करते. पत्ता असताना टाइमस्टॅम्प पुढे जाणे थांबवतो तेव्हा तो उलट वरच्या दिशेने निर्देश करतो. दोन्ही वाचन एकाच आउटपुट ओळीतून येतात, आणि हँडशेक आहे का हेच फक्त तपासल्यास दोन्हीपैकी काहीच दिसत नाही.

चुकीची असलेली विशिष्ट अवस्था दुरुस्त करा, नंतर बोगदा नव्हे तर अनुप्रयोग पुन्हा तपासा. ताजा हँडशेक पीअरबद्दलचा पुरावा आहे, आणि पीअरबद्दलचा पुरावा हा पुरावा नाही की तुमच्या ब्राउझरची पुढील विनंती पत्ता, राउट आणि कार्यरत अपलिंक शोधेल. wg-quick पुस्तिका त्यातील कोणते सहाय्यक सेट करतो आणि कोणते प्रोटोकॉलचे आहे हे स्पष्ट सांगते.

संबंधित लेख