एक 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 के टूटे होने की सामान्य रिपोर्ट से अधिक मूल्यवान है, और अगला व्यक्ति सबसे पहले यही पूछेगा।