WireGuard डेटा पाठवते पण काहीही परत मिळत नाही: कोणती बाजू?
वाढणारा ट्रान्समिट काउंटर ही दिशा आहे, निदान नाही। काहीही बदलण्यापूर्वी विनंती कधीही टनेलमधून बाहेर गेली नाही की उत्तर कधीही परत आले नाही हे ठरवा।
रिसीव्ह काउंटर शून्यावर राहत असताना ट्रान्समिट काउंटर वाढत राहणे हे दिशा दर्शवते, निदान नाही। पीअरने कधीही हँडशेक पूर्ण केला नाही, गंतव्याने चुकीचा पीअर निवडला, दूरच्या बाजूला परतीचा मार्ग नाही आणि फिल्टरने घराकडे परतताना उत्तर टाकून दिले अशा वेळी तेच वाचन दिसते। यापैकी प्रत्येक वेगळ्या ठिकाणी दुरुस्त होतो।
काम लहान करणारी तुलना म्हणजे टनेलमधून कधीही न गेलेली विनंती आणि कधीही परत न आलेले उत्तर यांच्यातील। योग्य इंटरफेसवर एक कॅप्चर या दोन्हींमध्ये निर्णय घेते।
काउंटर प्रमाण सांगतात, बिघाडाची दिशा नाही
WireGuard चे काउंटर इंटरफेसने पीअरला काय दिले आणि त्याच्याकडून काय घेतले हे नोंदवतात। कोणते गंतव्य, कोणता पीअर किंवा देवाणघेवाणीचा कोणता अर्धा भाग अपयशी ठरला हे ते सांगत नाहीत। पार्श्वभूमीचा रहदारी एकूण आकड्यांना अधिक माहितीहीन बनवतो, कारण काही बाइट्स कनेक्शन टिकवणारे संदेश किंवा असंबंधित प्रवाह असू शकतात। इंटरफेस सक्रिय आहे या सूचनेसारखे ते वाचा आणि नंतर त्यांना पुरावा मानणे थांबवा।
पहिली उपयुक्त गोष्ट म्हणजे हँडशेक चालू आहे का। त्याशिवाय या पीअरसाठी काहीही एन्क्रिप्ट झाले नाही आणि रिसीव्ह काउंटरला हलण्याचे कारण नाही।
पीअरची निवड की उत्तराचा मार्ग: दोन स्पष्टीकरणे
पहिले स्पष्टीकरण म्हणजे मार्ग दुसरीकडे निर्देश करत होता किंवा पीअरचे परवानगी असलेले प्रीफिक्स गंतव्य व्यापत नव्हते म्हणून पॅकेट हेतू असलेल्या पीअरपर्यंत कधीही पोहोचले नाही। दुसरे म्हणजे पॅकेट पोहोचले पण उत्तर परत येऊ शकले नाही, ही दूरच्या टोकावरील राउटिंगची समस्या आहे। प्रत्येक बिंदूवर तुम्ही काय निरीक्षण कराल यावरून तक्ता या दोन्हींची विभागणी करतो।
| Observation | Points to |
|---|---|
| No handshake while transmit climbs | Peer selection or endpoint |
| Handshake current, request visible on the server | Reply path or far-side route |
| Request never visible on the server | Allowed prefixes or local route |
| Both packets visible, nothing reaches the client | Return filter or translation |
तक्ता वरून वाचा। हँडशेक नसेल तर ते तुम्हाला की, एंडपॉइंट आणि बाहेरील मार्गाकडे पाठवते, कारण तपासण्यासाठी अजून दुसरे काहीही नाही। विनंती सर्व्हरवर दिसत असलेला चालू हँडशेक समस्या परतीच्या दिशेकडे हलवतो, जिथे गंतव्याचा स्वतःचा राउट तक्ता निर्णय घेतो। सर्व्हरवर कधीही न दिसणारी विनंती ही निवडीची समस्या आहे, आणि दोन्ही पीअरवरील परवानगी असलेले प्रीफिक्स सर्वात आधी तुलना करण्याची गोष्ट आहेत।
या चार ओळींपैकी दोन क्लायंटवर आणि दोन सर्व्हरवर दुरुस्त होतात। तुम्ही कोणत्या जोडीत आहात हे जाणणे हाच कामाचा मोठा भाग आहे।
उत्तरे कुठे गायब होतात
उत्तर गंतव्य सोडते, सर्व्हरच्या टनेल इंटरफेसपर्यंत पोहोचते आणि ज्या पीअरचे परवानगी असलेले पत्ते क्लायंटच्या अंतर्गत पत्त्याशी जुळतात त्याच्यासाठी एन्क्रिप्ट होते। ही जुळणी अपयशी ठरल्यास उत्तर शांतपणे टाकून दिले जाते, जे क्लायंटच्या बाजूने अगदी नेटवर्क बिघाडासारखे दिसते। उत्तर एन्क्रिप्ट असून क्लायंटचा स्वतःचा फिल्टर ते नाकारत असेल, तर लक्षण पुन्हा तेच असते। दोन्ही बाबतींत काउंटर नव्हे, कॅप्चर आवश्यक आहे।
या चुकीचे सर्वात मजबूत स्वरूप म्हणजे क्लायंटसाठी पॅकेट पुढे पाठवणारा पण क्लायंटच्या अंतर्गत श्रेणीपर्यंत परतीचा मार्ग नसलेला सर्व्हर। तो विनंती स्वीकारतो, उत्तर आपल्या डीफॉल्ट गेटवेकडे पाठवतो, आणि टनेल ते कधीही पाहत नाही। सर्व्हरवर जोडलेला रुंद भाषांतर नियम मार्ग दुरुस्त करण्याऐवजी तो बिघाड लपवतो।
एक गंतव्य सुरुवातीपासून शेवटपर्यंत तपासा
पीअरच्या श्रेणीत एकच गंतव्य निवडा, आणि हँडशेक स्पष्टपणे चालू असताना ते तपासा। खालील आदेश पीअरची स्थिती, निवडलेला मार्ग आणि देवाणघेवाणीच्या दोन्ही बाजू वाचतात। एन्क्रिप्ट झालेले पॅकेट प्रत्यक्षात ज्या इंटरफेसचा वापर करतात तिथे कॅप्चर चालवा।
wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5टनेल इंटरफेसवर विनंती दाखवणारे पण काहीही परत न येणारे कॅप्चर हे सर्व्हर बाजूचे उत्तर आहे, आणि गंतव्याचा राउट तक्ता हे पुढे पाहण्याचे ठिकाण आहे। अजिबात काहीही दिसत नसेल तर पॅकेटने दुसरा मार्ग घेतला आहे, म्हणून स्थानिक मार्ग संशयास्पद आहे। दोन्ही कॅप्चरमध्ये दिसणारी पण अप्लिकेशनमध्ये प्रगती नसलेली देवाणघेवाण प्रश्न पॅकेटच्या आकाराकडे किंवा इंटरफेसची आकडेवारी कधीही न दाखवणाऱ्या फिल्टरकडे हलवते। चाचणीत एक गंतव्य आणि एक क्लायंट ठेवा, कारण दुसरे चल पुराव्याचे पुन्हा अंदाजात रूपांतर करते।
परवानगी असलेला पत्ता चालू असताना नावे अपयशी ठरल्यास उत्तर टनेलमध्ये नसून DNS मध्ये आहे। फक्त मोठी स्थानांतरणे अडकत असतील तर पॅकेटचा आकार वेगळा तपासा।