WireGuard पियर गलत WAN बाट बाहिरिन्छ: पाँच जाँच क्रममा
धेरै अपलिंक भएको गेटवेमा ह्यान्डशेक र फर्वार्ड गरिएको प्रवाह फरक बाटो लिन सक्छन्। नियम, मार्क, अनुवाद र जवाफ त्यही क्रममा गर्नुहोस्।
दुई अपलिंक, एउटा गेटवे, र ट्राफिक बारम्बार ब्याकअप लाइनमा देखिने WireGuard पियर। ह्यान्डशेक सधैं स्वस्थ रहन्छ। त्यसैले लक्षणलाई राउटिङ खराबीको सट्टा WireGuard खराबी भनी गलत पढ्न सजिलो छ।
तलका जाँचहरू क्रममा गर्नुहोस्। प्रत्येकको रोकिने सर्त छ, र अगाडि उफ्रँदा सामान्यतया आत्मविश्वासी गलत जवाफ आउँछ।
ह्यान्डशेकलाई फर्वार्ड गरिएको प्रवाहबाट अलग गर्नुहोस्
इन्क्रिप्टेड पियर आदानप्रदानको सर्भरको सार्वजनिक ठेगानासम्म एन्डप्वाइन्ट रुट छ। फर्वार्ड गरिएको क्लाइन्ट ट्राफिकको गन्तव्य फरक छ र यसलाई मार्क वा नीति नियमहरूद्वारा छान्न सकिन्छ। यी एउटै इन्टरफेस साझा गर्ने दुई राउटिङ निर्णय हुन्। एउटालाई अर्कोको प्रमाणका रूपमा लिनु पहिलो गल्ती हो।
ह्यान्डशेकबाट तर्क गरिरहेको आफैंलाई थाहा पाउने बित्तिकै रोकिनुहोस्। यो एन्डप्वाइन्ट बाटोको मात्र प्रमाण हो।
नीति नियम पढ्नुहोस्, डिफल्ट तालिका होइन
डिफल्ट तालिकाले कुनै नीति नियम नमिल्दा के हुन्छ देखाउँछ। स्रोत, मार्क वा गन्तव्यअनुसार राउट गर्ने गेटवेमा निर्णायक नियम अन्तै बस्छ। साधारण तालिका पूर्ण रूपमा उचित देखिन सक्छ, तर वास्तविक छनोट त्यसको माथि हुन्छ।
ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2
नीति नियमहरू र तिनले देखाउने तालिकाहरू पढ्नुहोस्। त्यसपछि तपाईंको परीक्षण प्रवाहसँग कुन नियम मिल्छ पुष्टि गर्नुहोस्। अब इच्छित अपलिंक नबोक्ने इन्टरफेसलाई सन्दर्भ गर्ने नियम एउटा फेला हो, विवरण होइन। अन्त्यको रुट लुकअपले तालिका पढेर अनुमान गर्नुभन्दा धेरै छिटो जवाफ देखाउँछ।
मार्क र अनुवाद सँगै जाँच्नुहोस्
नीति राउटिङ शृंखलामा पहिले सेट गरिएको प्याकेट मार्कमा निर्भर हुन्छ। यदि मार्किङ नियमले तपाईंको ट्राफिक छुटाउँछ भने, प्रवाह मुख्य तालिकामा खस्छ र त्यहाँ जे डिफल्ट छ त्यसैबाट बाहिरिन्छ। फर्वार्ड गरिएका प्याकेटहरू स्थानीय रूपमा उत्पन्न ट्राफिकका लागि लेखिएका शृंखलाहरू प्रायः छोड्छन्।
nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1
अनुवाद प्रवाह बोक्ने अपलिंकसँग मिल्नुपर्छ। प्याकेट ब्याकअप लाइनबाट बाहिरिँदा प्राथमिक ठेगानामा अनुवाद गर्ने नियमले प्रवाहले कहिल्यै नचलाएको इन्टरफेसलाई सम्बोधन गरिएका जवाफहरू उत्पन्न गर्छ। अनुवाद नियमको आफ्नै इन्टरफेस सर्त जाँच्नुहोस्। बिनासर्त नियम दोस्रो अपलिंक प्रयोग नगरेसम्म काम गर्छ, त्यसपछि रोकिएको जस्तो देखिने तरिकाले असफल हुन्छ।
कुन इन्टरफेसले जवाफ बोक्छ हेर्नुहोस्
एउटा अनुरोध चलिरहेको बेला दुवै अपलिंकमा क्याप्चर गर्नुहोस्। कुन इन्टरफेसले अनुरोध र कुनले जवाफ बोक्छ नोट गर्नुहोस्। असममित बाटोहरू अनुमान गर्नुभन्दा देख्न धेरै सजिलो छ।
यदि जवाफ गलत अपलिंकबाट आउँछ भने, समस्या WireGuard बाट कनेक्सन ट्र्याकिङ वा अनुवादतिर सरेको छ। पियर कन्फिगरेसनमा कुनै पनि परिवर्तनले यसलाई सुधार्ने छैन।
फर्कने बाटो राखेर एउटा कुरा बदल्नुहोस्
गेटवेमा नीति नियम सम्पादन गर्नुअघि कन्सोल वा ब्यान्ड बाहिरको पहुँच राख्नुहोस्। एउटा परिवर्तन गर्नुहोस्, त्यही अधिकृत गन्तव्य परीक्षण गर्नुहोस्, त्यसपछि पुनः जोडिएर ह्यान्डशेक अझै इच्छित एन्डप्वाइन्ट बाटो प्रयोग गरिरहेको पुष्टि गर्नुहोस्। दोस्रो ठेगाना परिवारमा संख्यात्मक परीक्षण थप्नुहोस्, किनकि केवल v4 नीतिले त्यही गल्ती खुला राख्छ।
प्रत्येक प्रवाहले कुन अपलिंक प्रयोग गर्यो नोट गर्नुहोस्। त्यो अभिलेखले अर्को प्रतिवेदनलाई पूरा दिउँसोको सट्टा दुई मिनेटको जाँच बनाउँछ। नेमस्पेस र राउटिङबारे WireGuard का टिप्पणीहरू एन्डप्वाइन्ट बाटोलाई टनेल गरिएको ट्राफिकबाट जानाजान अलग गर्ने तरिका वर्णन गर्छन्, जुन सामान्यतया डिफल्ट-रुट उपाय कपी गर्नुभन्दा सफा हुन्छ।