आवर्ती राउटिंग: जेव्हा बोगदा स्वतःचेच पॅकेट पकडतो
बोगदा स्वतःला बनवणारे पॅकेट पकडू शकतो। डीफॉल्ट मार्ग बदलण्यापूर्वी आणि नंतर सर्व्हरपर्यंतच्या मार्गाची तुलना करा, नंतर त्या मार्गाच्या मालकाची दुरुस्ती करा।
बोगदा वर येतो, लॉग पूर्ण झालेला हँडशेक दाखवतो, आणि एका सेकंदानंतर तेच सत्र मरते आणि लूपमध्ये पुन्हा जोडते। या पद्धतीचे ठराविक कारण आहे: सर्व्हरपर्यंतचा मार्ग आता बोगद्याच्या आत दाखवतो, त्यामुळे बोगदा वाहून नेणारी पॅकेट बोगद्यातून पाठवली जातात। प्रमाणीकरणात काहीही बदलले नाही, म्हणून क्रेडेन्शियल्स पुन्हा टाकल्याने काही फरक पडत नाही। मार्ग बदलण्यापूर्वी आणि नंतरच्या बाहेरील मार्गाची तुलना करा, पुनरावृत्ती दिसू लागेल।
आधी बाहेरील मार्ग तपासा
खेळात दोन पॅकेट आहेत, एक नाही। आतील पॅकेट अनुप्रयोगाचे आहे आणि त्याला एन्क्रिप्ट केलेले असावे, तर बाहेरील पॅकेट सर्व्हरला संबोधित आहे आणि त्याला बोगद्यावर अवलंबून नसलेल्या मार्गाने तिथे पोहोचावे लागते।
ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints
बोगदा वर आल्यानंतर कर्नेलला सर्व्हरच्या पत्त्यापर्यंतचा मार्ग विचारा, आणि डीफॉल्ट मार्ग बदलल्यानंतर पुन्हा विचारा। पुढचा हॉप बोगद्याच्या उपकरणावर उतरत असेल तर तीच पुनरावृत्ती आहे, आणि ती कोणत्याही पॅकेट कॅप्चरशिवाय दिसते। इंटरफेस बाइंडिंग, मार्क किंवा नेटवर्क नेमस्पेस सामान्य शोध अपूर्ण करू शकतात, म्हणून क्लायंट स्वतः वापरतो तोच संदर्भ वापरा। उत्तर बरोबर वाटत असूनही सत्र अजूनही लूपमध्ये असेल, तर फक्त मुख्य तक्ता नाही, राउटिंग धोरणाचे नियम वाचा।
सत्र काही क्षण का टिकते
नवीन मार्ग बसवण्यापूर्वीच हँडशेक पूर्ण होतो, म्हणून पहिले काही सेकंद निरोगी दिसतात। क्लायंट डीफॉल्ट मार्ग जोडताच पुढचे बाहेरील पॅकेट त्याच्या मागे त्या इंटरफेसमध्ये जाते ज्यातून त्या पॅकेटला जावे लागते। सर्व्हरला काहीच दिसत नाही, क्लायंट पुन्हा पाठवतो, आणि प्रयत्न एकतर वेळ संपून थांबतो किंवा सत्र मारून पुन्हा सुरू होतो।
हा क्रम बोगदा लॅपटॉपवर का चालतो पण राउटरवर का अयशस्वी होतो, आणि अयशस्वीता जोडणीच्या वेळी नाही तर रहदारी सुरू झाल्यावर का सुरू होते हे स्पष्ट करतो। हे लूप देखील स्पष्ट करते: प्रत्येक पुन्हा सुरुवात सत्र पुन्हा प्रस्थापित करते, त्याआधीच मार्ग ते अशक्य करतो।
एंडपॉइंटच्या अपवादाचा मालक कोण आहे ते शोधा
समर्थित क्लायंट स्वतःचा अपवाद स्वतः तयार करतात: मूळ गेटवेमधून सर्व्हरपर्यंत होस्ट मार्ग, किंवा बाहेरील सॉकेट बोगद्याबाहेर ठेवणारा मार्क। प्रश्न हा आहे की दुसऱ्या कशाने तो काढला किंवा त्यावर मात केली।
मार्ग-आधारित IPsec मध्ये कोणती पॅकेट बोगद्यात प्रवेश करतात हे ठरवणारे धोरण-निवडक तपासा आणि पीअरचा पत्ता त्यातून वगळला आहे याची खात्री करा। WireGuard मध्ये इंटरफेसचा फायरवॉल मार्क आणि त्याचे धोरण नियम वाहतूक पॅकेट बोगद्याबाहेर ठेवतात, त्यामुळे हाताने जोडलेला डीफॉल्ट मार्ग ती रचना मोडू शकतो। दुसरे VPN प्रोफाइल किंवा डीफॉल्ट मार्ग पुन्हा लिहिणारी व्यवस्थापन स्क्रिप्ट हा सामान्य दोषी असतो। एकामागून एक जोडलेले व्यापक बायपास नियम हाच नेहमीचा परिणाम असतो, आणि ते राउटिंग बगचे कोणीही सांभाळू न शकणाऱ्या तक्त्यात रूपांतर करतात।
नेटवर्क बदलल्यानंतर पुन्हा तपासा
Wi-Fi गेटवेमधून जाणारा होस्ट मार्ग मशीन दुसऱ्या नेटवर्कवर जाईपर्यंत बरोबर असतो। मग तेच लक्षण कोणत्याही संरचना बदलाशिवाय परत येते।
एंडपॉइंटचा पत्ता, जोडण्यापूर्वीचा आणि नंतरचा मार्ग, आणि प्रत्येकाने वापरलेला इंटरफेस नोंदवा। ही तीन तथ्ये सामान्यतः क्लायंटची चूक आणि अतिक्रमण यात फरक करतात, आणि ती गोळा करणारी व्यक्ती गेल्यावरही टिकतात।
नव्या नेटवर्कवर पुन्हा जोडा आणि वाचनाची पुनरावृत्ती करा। अपवाद पुन्हा नसेल, तर दुरुस्ती तो असलेल्या प्रोफाइलमध्ये आहे, व्यत्ययाच्या वेळी टाइप केलेल्या एक-वेळच्या आदेशात नाही।