WireGuard अटकता है: MTU सीमा या गायब फ़ॉरवर्ड नियम?
सर्वर के आगे कुछ भी काम न करना फ़ॉरवर्डिंग या वापसी रूट की समस्या है। छोटे अनुरोध चलें और बड़े अटकें, यह पैकेट आकार का हस्ताक्षर है।
आदत यह है कि WireGuard के बिगड़ते ही MTU घटा दिया जाए, और यह आदत एक अलग ख़राबी को छिपा देती है। जो गेटवे आगे नहीं भेजता और जो मार्ग बड़े पैकेट नहीं ढोता, वे अलग-अलग पैटर्न बनाते हैं: एक दोनों दिशाओं में और हर आकार पर विफल होता है, दूसरा छोटे अनुरोधों में बचा रहता है और बड़े में मर जाता है। कोई भी संख्या बदलने से पहले तय करें कि आपके पास कौन-सी आकृति है। परीक्षण सस्ता है और संभावित कारणों में से आधे हटा देता है।
दो विफलताएँ, दो अलग आकृतियाँ
फ़ॉरवर्डिंग की समस्या सर्वर के ठीक बाद दिखती है। हैंडशेक सफल होता है, टनल का पता उत्तर देता है, और गेटवे के पीछे छोटे अनुरोध से भी कुछ नहीं पहुँचता। पैकेट सर्वर तक पहुँचा और आगे नहीं भेजा गया, या उत्तर के पास वापसी का कोई मार्ग नहीं था।
आकार की समस्या केवल एक सीमा के ऊपर दिखती है। DNS, एक TCP हैंडशेक और एक छोटा API कॉल चलते हैं, जबकि फ़ाइल डाउनलोड या बड़ा उत्तर अटक जाता है। जो पैकेट फ़िट हुए वे एक सिरे से दूसरे सिरे तक गए, और जो नहीं फ़िट हुए वे कहीं बिना किसी उपयोगी रिपोर्ट के गिरा दिए गए।
ये विवरण अलग-अलग लोगों और अलग-अलग कॉन्फ़िगरेशन फ़ाइलों की ओर इशारा करते हैं, इसीलिए अनुमान से बेहतर है आकृति को मापना। गेटवे पर एक अकेला पिंग उन्हें अलग नहीं कर सकता।
कुछ भी घटाने से पहले फ़ॉरवर्डिंग को बाहर करें
गेटवे के पार गंतव्य का परीक्षण करें, गेटवे का नहीं। सर्वर के टनल पते पर पिंग केवल यह सिद्ध करता है कि इंटरफ़ेस चालू है और आप उस मशीन तक पहुँचते हैं जो टनल समाप्त करती है। व्यापक नेटवर्क का ट्रैफ़िक उस मशीन पर IP फ़ॉरवर्डिंग चालू होने और फ़ॉरवर्ड किए गए प्रवाह को अनुमति देने वाले फ़ायरवॉल पर निर्भर करता है। दोनों सत्य होने चाहिए, और किसी एक के ग़लत होने पर वही मौन उत्पन्न होता है।
वापसी रूटिंग का भी उतना ही महत्व है। यदि गंतव्य नेटवर्क को यह नहीं पता कि क्लाइंट के टनल पते तक कैसे पहुँचना है, तो अनुरोध आता है और उत्तर गायब हो जाता है, और क्लाइंट ऐसा टाइमआउट बताता है जो गिराए गए फ़ॉरवर्ड जैसा ही दिखता है।
जहाँ डिज़ाइन पता अनुवाद का उपयोग करता है, वहाँ अनुवाद नियम उस वापसी मार्ग का हिस्सा है। MTU समस्या का पीछा करते हुए उसे हटाना एक काम करने वाले डिज़ाइन को टूटा हुआ बना देता है, इसलिए मौजूदा नियमों को संपादित करने से पहले पढ़ें।
मापें कि टूट कहाँ से शुरू होती है
पहले फ़ॉरवर्डिंग की स्थिति और फ़िल्टर नियम पढ़ें। ये केवल पढ़ने की जाँच हैं और सस्ते प्रश्न का उत्तर देती हैं:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9फिर क्लाइंट से गेटवे के पार किसी होस्ट की ओर, don’t-fragment बिट के साथ आकार जाँचें:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9यदि पहली जाँच चलती है और दूसरी फ़्रैगमेंटेशन त्रुटि के साथ विफल होती है, तो मार्ग आपको अपना उपयोगी आकार बता रहा है। यदि दोनों में से कोई नहीं चलती, तो आप फ़ॉरवर्डिंग या रूटिंग देख रहे हैं, और MTU बदलने वाला चर नहीं है।
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
जिस परत को आपने सिद्ध किया उसे ठीक करें
जब फ़ॉरवर्डिंग ख़राबी हो, तो सुधार एक फ़ॉरवर्डिंग नियम या मार्ग है, जिसे डिज़ाइन जितना संकीर्ण अनुमति दे उतना संकीर्ण व्यक्त किया गया हो। जब आकार ख़राबी हो, तो सुधार ऐसा MTU है जो इस विशेष मार्ग पर एनकैप्सुलेशन का हिसाब रखता है, और ज़रूरत वाले इंटरफ़ेस पर लागू होता है, बेड़े के हर एडाप्टर पर नहीं।
किसी भी तरह, बाद में उसी गंतव्य के विरुद्ध वही कार्य दोहराएँ। यदि मूल बड़ा स्थानांतरण अब पूरा होता है, तो बदलाव ने उस परत को संबोधित किया जो विफल हो रही थी। यदि केवल छोटी जाँच बेहतर हुई, तो आपने लक्षण का इलाज किया और असली सीमा अभी भी अपनी जगह है।
लिख लें कि बदलाव से पहले आपने कौन-सी आकृति देखी। सुधार के बगल में दर्ज वह एक पंक्ति ही अगले व्यक्ति को ऐसा MTU घटाने से रोकती है जो कभी समस्या नहीं था।