एउटा WireGuard पियर पुग्न नसक्ने अवस्थामा अर्को काम गर्दै छ: जाँचसूची

एउटा WireGuard पियरले ट्राफिक पास गर्छ र दोस्रोले ह्यान्डसेक पूरा गर्छ तर सुरुङको पछाडिको कुनै कुरामा कहिल्यै पुग्दैन। काम गर्ने पियरले तपाईंलाई इन्टरफेस, UDP पोर्ट र सर्भरको कुञ्जी सम्भवतः ठीक छ भनी बताउँछ। यसले दोस्रो पियरको AllowedIPs, त्यसको भित्री स्रोत ठेगाना वा तिनीहरूबीचको फर्वार्डिङ नियमबारे केही बताउँदैन। सूची क्रममा पूरा गर्नुहोस् र शर्त असफल हुने पहिलो चरणमा रोक्नुहोस्।

चरण 1: प्याकेटले लिनुपर्ने बाटो लेख्नुहोस्

एउटै हबमा रहेका दुई क्लाइन्ट आफैं एकअर्कासम्म पुग्दैनन्। हब-र-स्पोक डिजाइनमा सर्भरले प्याकेट wg0 मा प्राप्त गर्छ र त्यसलाई फेरि wg0 बाट अर्को पियरतर्फ फर्वार्ड गर्नुपर्छ, जसका लागि IP फर्वार्डिङ र फर्वार्ड नियम चाहिन्छ। सिधा पियर-टु-पियर डिजाइनमा प्रत्येक पक्षलाई अर्कोको इन्डपोइन्ट र अर्कोको सुरुङ ठेगाना AllowedIPs भित्र चाहिन्छ। कुनै पनि कन्फिगरेसन पढ्नुअघि तपाईं कुन डिजाइन डिबग गर्दै हुनुहुन्छ त्यो निर्णय गर्नुहोस्।

अपेक्षित बाटोले कहाँ हेर्ने भनेर पनि बताउँछ। यदि प्याकेटले हब पार गर्नुपर्छ भने असफल हप या त पठाउनेको AllowedIPs, या हबको फर्वार्डिङ, या प्राप्त गर्नेको AllowedIPs हो। यदि सिधै जानुपर्छ भने हब अप्रासंगिक छ र दुवै पियरका इन्डपोइन्ट फिल्ड महत्त्वपूर्ण छन्।

चरण 2: AllowedIPs दुवै पट्टिबाट तुलना गर्नुहोस्, एउटा मात्रबाट होइन

WireGuard ले AllowedIPs लाई राउटिङ तालिका र पहुँच सूची दुवै रूपमा प्रयोग गर्छ। पठाउँदा सुरुङ छान्न गन्तव्य ठेगाना पियरको AllowedIPs मा खोजिन्छ; प्राप्त गर्दा भित्री स्रोत ठेगाना पठाउने पियरको AllowedIPs भित्र पर्नुपर्छ, नत्र प्याकेट फालिन्छ। कुनै पनि पट्टिमा दायरा छुट्दा उही लक्षण देखिन्छ: ढुवानी चल्छ, पेलोड हराउँछ।

फाइल होइन, जीवित अवस्था पढ्नुहोस्, किनकि पुनः लोड गर्नु चुपचाप असफल भएको हुन सक्छ: sudo wg show wg0 allowed-ips। सर्भरमा असफल पियरको प्रविष्टिमा त्यसको सुरुङ ठेगाना हुनुपर्छ, जस्तै 10.90.0.3/32। क्लाइन्टमा सर्भर पियरको प्रविष्टिमा तपाईंले परीक्षण गरिरहेको गन्तव्य हुनुपर्छ, त्यो हबको सुरुङ ठेगाना होस् वा टाढाको सबनेट। एकअर्कामा ओभरल्याप हुने दायराले खोज अस्पष्ट बनाउँछ र तपाईंले नचाहेको पियर छान्न सक्छ, त्यसैले तिनलाई अलग राख्नुहोस्।

चरण 3: भित्री स्रोत ठेगाना जाँच्नुहोस्

जो क्लाइन्टले 10.90.0.3 लाई wg0 मार्फत राउट गर्छ तर प्याकेट आफ्नै Wi-Fi ठेगानाबाट पठाउँछ, त्यसलाई प्राप्त गर्नेले अस्वीकार गर्नेछ, किनकि स्रोत पियरको AllowedIPs सँग मिल्दैन। कर्नेलले वास्तवमा के छान्छ ip route get 10.90.0.3 from 10.90.0.2 बाट र सुरुङ इन्टरफेसमा तोकिएको ठेगाना ip -brief addr show wg0 बाट पुष्टि गर्नुहोस्।

प्राप्त गर्ने Linux होस्टमा रिभर्स-पाथ फिल्टरिङ दोस्रो ढोका हो। फिर्ती मार्गको मालिक इन्टरफेसमा कडा rp_filter ले आएको इन्टरफेससँग फिर्ती मार्ग नमिल्ने सुरुङ ट्राफिक फाल्न सक्छ। बन्द गर्नुअघि प्रभावकारी मान जाँच्नुहोस्; धेरै टोपोलोजीमा सही सुधार मार्ग हो, खुकुलो फिल्टर होइन।

चरण 4: हबको फर्वार्डिङ र फिर्ती मार्ग समीक्षा गर्नुहोस्

यदि हबले पियरबीच फर्वार्ड गर्नुपर्छ भने कर्नेललाई net.ipv4.ip_forward=1 चाहिन्छ, र फायरवालले फर्वार्ड गरिएको प्रवाह स्वीकार्नुपर्छ: wg0 मा भित्र, wg0 बाट बाहिर, पठाउनेको सुरुङ ठेगानाबाट प्राप्त गर्नेको ठेगानासम्म। सामान्य असफलता भनेको UDP 51820 स्वीकार्ने इनपुट नियम तर फर्वार्ड नियम नहुनु] हो, त्यसैले ह्यान्डसेक सफल हुन्छ र पेलोड मर्छ। प्रभावकारी नियमहरू sudo nft list ruleset वा तपाईंको फायरवाल म्यानेजरको समकक्षद्वारा सूचीबद्ध गर्नुहोस्।

त्यसपछि जवाफ जाँच्नुहोस्। गन्तव्य होस्टसँग पठाउनेतर्फ फिर्ती मार्ग हुनुपर्छ, या हब मार्फत या आफ्नै गेटवे मार्फत। यदि हबले सुरुङ सबनेटमा NAT पनि गर्छ भने अनुवाद फर्वार्ड गरिएको प्रवाहमा लागू हुन्छ र अवस्था सकिनुअघि जवाफ हबसम्म पुग्छ भनी पुष्टि गर्नुहोस्। कुञ्जीको समस्या जस्तो देखिने एकतर्फी असफलता प्रायः यही फिर्ती मार्ग हो।

अन्तमा, ह्यान्डसेकलाई डेटाबाट अलग गर्नुहोस्। ह्यान्डसेक पूरा गर्ने तर ठूला स्थानान्तरणमा अड्किने पियरसँग प्रायः त्यही मार्गमा MTU वा MSS समस्या हुन्छ, AllowedIPs समस्या होइन। पहिले सानो पिङले, त्यसपछि पूर्ण आकारको पिङले परीक्षण गर्नुहोस् र दुवै पियर तुलना गर्नुहोस्।

चरण 5: एउटा कुरा बदल्नुहोस् र काम गर्ने पियरलाई अक्षुण्ण राख्नुहोस्

असफल मार्गमा एउटै परिवर्तन गर्नुहोस् र दुवै पियर फेरि परीक्षण गर्नुहोस्। प्रत्येक पियरको AllowedIPs लाई 0.0.0.0/0 ले बदल्नु पहिले नै काम गरिरहेको पियर तोड्ने सबैभन्दा छिटो उपाय हो, किनकि यसले त्यो इन्टरफेसमा सबै ट्राफिकको राउटिङ निर्णय बदल्छ। त्यही एउटा प्रविष्टि सम्पादन गर्नुहोस्, पुनः लोड गर्नुहोस् र जीवित अवस्था फेरि पढ्नुहोस्।

कुन मार्ग सफल भयो, कुन असफल भयो र प्रत्येकको ठ्याक्कै कमान्ड आउटपुट लेख्नुहोस्। त्यो तुलना VPN बिग्रिएको भन्ने सामान्य प्रतिवेदनभन्दा बहुमूल्य छ, र अर्को व्यक्तिले सबैभन्दा पहिले त्यही सोध्नेछ।