WireGuard हैंडशेक काम करता है पर इंटरनेट नहीं: पैकेट का पीछा करें
हैंडशेक सिर्फ़ कुंजियाँ और पहुँच साबित करता है। AllowedIPs से आगे फ़ॉरवर्डिंग, NAT और वापसी रूट से होते हुए एक पैकेट का पीछा करें और देखें कि वह कहाँ रुकता है।
टनल चालू है, wg show हाल का हैंडशेक दिखाता है, आप सर्वर के टनल पते को पिंग कर सकते हैं, और उसके आगे कुछ भी जवाब नहीं देता। पहली प्रवृत्ति कुंजियाँ फिर से बनाने या कॉन्फ़िग फिर से साझा करने की होती है। यह ठीक उसी हिस्से को बदलता है जो पहले ही काम करता साबित हो चुका है।
पूरा हुआ हैंडशेक कहता है कि दोनों पक्ष कुंजियों पर सहमत हैं, UDP एंडपॉइंट तक पहुँचता है, और क्रिप्टो रूटिंग पैकेट स्वीकार करती है। यह नहीं कहता कि पैकेट बाद में सर्वर छोड़ सकता है या नहीं।
इसलिए अनुमान लगाने के बजाय एक पैकेट का पीछा करें। चार जगहें हैं जहाँ वह मर सकता है, और हर जगह अलग निशान छोड़ती है।
हैंडशेक वास्तव में क्या साबित करता है
WireGuard एक UDP प्रोटोकॉल है जो Noise हैंडशेक से सत्र स्थापित करता है और फिर किसी साथी के लिए पैकेट एन्क्रिप्ट करता है। जब wg show कुछ सेकंड पुराना हैंडशेक और बढ़ता ट्रांसफ़र काउंटर दिखाता है, तो एंडपॉइंट, कुंजियाँ और साथी की सार्वजनिक कुंजी सब सही हैं।
जो यह साबित नहीं करता वह है कि आपका क्लाइंट इंटरनेट की ओर जाने वाला ट्रैफ़िक इंटरफ़ेस में भेजता ही है, सर्वर उसे आगे भेजने को तैयार है, या कोई जवाब वापसी का रास्ता खोज सकता है। ये कर्नेल रूटिंग और फ़ायरवॉल के फ़ैसले हैं, और ये टनल के बाहर लिए जाते हैं।
इसीलिए सर्वर के टनल पते को पिंग करना इतनी भ्रमित करने वाली परीक्षा है। वह पैकेट सर्वर को ही संबोधित है, इसलिए वह स्थानीय रूप से खत्म होता है। उसे कभी फ़ॉरवर्डिंग नहीं चाहिए, कभी अनुवाद नहीं चाहिए, और कभी इंटरनेट से वापसी रूट नहीं चाहिए।
AllowedIPs एक रूटिंग फ़ैसला है
क्लाइंट पर AllowedIPs दो काम करता है। यह क्रिप्टोकुंजी रूटिंग तालिका है जो तय करती है कि कौन से गंतव्य पते इस साथी के टनल में भेजे जाते हैं, और यह उन स्रोत पतों की सूची है जो साथी आपसे स्वीकार करेगा। अगर क्लाइंट कॉन्फ़िग में सिर्फ़ 10.8.0.0/24 है, तो सार्वजनिक गंतव्य कभी इंटरफ़ेस में नहीं आते और आपका सामान्य डिफ़ॉल्ट रूट उन्हें टनल के बाहर ले जाता है। तब टनल बिलकुल ठीक काम करता है और आप जो चाहते थे उसमें से कुछ भी नहीं करता।
कॉन्फ़िग फ़ाइल क्या कहती है, उसके बजाय देखें कि क्लाइंट ने वास्तव में क्या इंस्टॉल किया:
wg show wg0 allowed-ipsip route get 1.1.1.1
दूसरा कमांड निर्णायक है। अगर जवाब आपका भौतिक इंटरफ़ेस और सामान्य गेटवे बताता है, तो पैकेट टनल से नहीं जा रहा है और सर्वर की तरफ़ कोई भी बदलाव इसे ठीक नहीं करेगा। IPv4 के लिए 0.0.0.0/0 और IPv6 के लिए ::/0 अलग-अलग जोड़ें; एक परिवार के लिए सब कुछ पकड़ने वाला नियम दूसरे को उसके मूल रास्ते पर छोड़ देता है, और यह काम करते IPv4 टनल और अटके IPv6 लुकअप का आम कारण है।
गेटवे पर पैकेट कहाँ मरता है
अगर रूट सही है और पैकेट फिर भी कहीं नहीं जाता, तो वह सर्वर तक पहुँचकर वहीं रुक जाता है। चार जाँचें ज़्यादातर गेटवे कवर कर लेती हैं।
फ़ॉरवर्डिंग। sysctl net.ipv4.ip_forward का 0 लौटाना क्लासिक जवाब है, और कई डिस्ट्रीब्यूशन अब भी डिफ़ॉल्ट रूप से 0 पर हैं। यह 1 होना चाहिए, और इसे sysctl फ़ाइल में स्थायी रूप से सेट करना चाहिए, न कि ऐसे कमांड से जो रीबूट पर गायब हो जाए। IPv6 फ़ॉरवर्डिंग अलग स्विच है।
फ़िल्टर नीति। डिफ़ॉल्ट ड्रॉप नीति वाली FORWARD चेन टनल का ट्रैफ़िक गिरा देगी जबकि होस्ट तक जाने वाले ट्रैफ़िक को अनुमति देगी, जो लक्षण से बिलकुल मेल खाता है। सहेजी गई फ़ाइल नहीं, जीवंत नियम-समूह पढ़ें: nft list ruleset या iptables -S।
अनुवाद या रूटिंग। निजी टनल पते इस्तेमाल करने वाले क्लाइंट को या तो सर्वर के एग्रेस इंटरफ़ेस पर स्रोत NAT चाहिए, या ऐसा रूट किया गया प्रीफ़िक्स चाहिए जिसे ऊपरी नेटवर्क वापस भेजना जानता हो। दोनों में से चुनाव पता योजना के अनुसार होता है। ऐसे नेटवर्क में MASQUERADE जोड़ना जो पहले से आपका प्रीफ़िक्स वापस रूट करता है, हानिरहित पर बेकार है, और जहाँ कोई रूट नहीं है वहाँ इसे छोड़ देना जवाबों को गैर-रूटेबल निजी श्रेणी पर संबोधित छोड़ देता है।
वापसी मार्ग। रूट किए गए डिज़ाइन में ऊपरी राउटर को आपके सर्वर की ओर इशारा करने वाला रूट चाहिए। प्रदाता का नेटवर्क भी इसे रोक सकता है: कई क्लाउड इंस्टेंस पर स्रोत और गंतव्य जाँच चालू करते हैं, जो उन पैकेटों को चुपचाप गिरा देती है जिनका स्रोत इंस्टेंस का अपना पता नहीं है, जब तक वह जाँच बंद न की जाए।
DNS रूटिंग से अलग तरह से विफल होता है
किसी ज्ञात पते पर पैकेट और नाम की लुकअप दो अलग विफलताएँ हैं, और त्रुटि संदेश उलटी दिशाओं में भ्रमित करते हैं। अगर ping 1.1.1.1 काम करता है और ब्राउज़र कुछ भी लोड नहीं कर पाता, तो रूट ठीक है और नाम विभेदन नहीं। अगर पिंग खुद विफल हो, तो DNS अप्रासंगिक है और आप पिछले खंड पर लौट आए हैं।
wg-quick कॉन्फ़िग की DNS = पंक्ति से रिज़ॉल्वर सेट कर सकता है, और systemd-resolved का हर लिंक के लिए अपना व्यवहार है। जो VPN रिज़ॉल्वर को ऐसे पते से बदल देता है जो सिर्फ़ टनल के अंदर पहुँच में है, वह टनल गिरते ही हर लुकअप विफल कर देगा, जो ऐसा दिखता है जैसे टनल इंटरनेट तोड़ रहा है।
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
एक क्रम जो सबूत देता है
पहले क्लाइंट पक्ष की जाँच चलाएँ, क्योंकि यह एक कमांड है और आधी संभावनाएँ हटा देती है। फिर पुष्टि करें कि सर्वर इंटरनेट निकास होने के लिए ही बना है; निजी पहुँच के लिए बना गेटवे सार्वजनिक गंतव्य विफल होने पर टूटा नहीं है।
सर्वर पर, क्लाइंट से पिंग भेजते समय इंटरफ़ेस देखें: tcpdump -ni wg0 icmp अनुरोध दिखाना चाहिए, और tcpdump -ni eth0 icmp उसे निकलता हुआ दिखाना चाहिए, अनुवादित हो या न हो। अगर वह पहले पर दिखे और दूसरे पर कभी न दिखे, तो रुकावट सर्वर पर स्थानीय है। अगर वह निकले और कोई जवाब वापस न आए, तो समस्या ऊपर है, और वह अलग बात है।
अंत में ऐसा करें कि सुधार रीबूट के बाद भी टिके। फ़ॉरवर्डिंग sysctl फ़ाइल में होनी चाहिए, फ़ायरवॉल नियम उस सेवा में जो उन्हें लोड करती है, और क्लाइंट रूट उस कॉन्फ़िग में जो इंटरफ़ेस उठाता है, न कि ऐसी शेल में जिसे आप भूल जाएँगे। फिर से कनेक्ट करें, वही दो परीक्षण दोहराएँ और पुष्टि करें कि काउंटर आगे बढ़ रहे हैं।