WireGuard PersistentKeepalive: NAT मैपिंग को जीवित रखें
अगर उल्टा कनेक्शन केवल पीयर द्वारा ट्रैफ़िक भेजने के तुरंत बाद काम करता है, तो मैपिंग समाप्त हो रही है। राउटर के पीछे keepalive सेट करें और फिर वास्तविक समय-सीमा पढ़ें।
घर का बॉक्स सुरंग खोलता है और बिना किसी परेशानी के क्लाउड सर्वर तक पहुँच जाता है। घर के बॉक्स द्वारा आखिरी बार कुछ भेजने के बाद क्लाउड सर्वर एक-दो मिनट तक घर के एप्लिकेशन तक पहुँच सकता है, और फिर रुक जाता है। WireGuard लॉग में कुछ नहीं दिखता, कोई हैंडशेक त्रुटि नहीं बताई जाती, और सुरंग को फिर से शुरू करने से यह थोड़ी देर के लिए ठीक हो जाता है। यह पैटर्न एक समाप्त होता मैपिंग है, टूटी हुई सुरंग नहीं, और नीचे दी गई रनबुक कुछ भी बदलने से पहले इसकी पुष्टि करती है।
पुष्टि करें कि पैटर्न निष्क्रियता में समाप्ति है
अलग पहचानने वाली बात समय है। अगर उल्टा कनेक्शन घर के पीयर द्वारा ट्रैफ़िक भेजने के तुरंत बाद काम करता है और शांत अंतराल के बाद विफल हो जाता है, तो रास्ता ठीक है और बीच की स्थिति नहीं। अगर यह कभी काम ही नहीं किया, ट्रैफ़िक के तुरंत बाद भी नहीं, तो यह गलत निदान है।
sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transferघर के पीयर द्वारा कुछ भेजने के तुरंत बाद पहले दो चलाएँ, पाँच मिनट प्रतीक्षा करें और फिर उन्हें दोबारा चलाएँ। समय-सारणी के अनुसार बिना किसी नए एंडपॉइंट के नवीनीकृत होने वाला हैंडशेक टाइमस्टैम्प आपको बताता है कि सुरंग जीवित है। जो बदला है वह बाहर से बिना माँगे आने वाले पैकेट की क्षमता है, जो सुरंग की नहीं बल्कि रास्ते की विशेषता है।
फिर उल्टा प्रयास करें और स्थानांतरण काउंटर देखें। अगर क्लाउड पक्ष बाइट भेजता है और घर का पक्ष कोई नहीं प्राप्त करता, तो पैकेट क्लाउड से निकल गया और रास्ते में स्थिति रखने वाले उपकरण में मर गया। यही वह हस्ताक्षर है जो आप खोज रहे हैं। अगर दोनों काउंटर चलते हैं, तो सुरंग ने पैकेट पहुँचा दिया और संदिग्ध एप्लिकेशन है।
keepalive को राउटर के पीछे वाले पीयर पर रखें
स्थायी keepalive समय-सारणी के अनुसार एक छोटा प्रमाणित पैकेट भेजकर NAT मैपिंग और किसी भी फ़ायरवॉल स्थिति को जीवित रखते हैं। यह सेटिंग राउटर के पीछे वाली मशीन पर, दूर के पीयर के लिए उसकी प्रविष्टि में होनी चाहिए, क्योंकि वही पक्ष है जिसका बाहर जाने वाला पैकेट स्थिति बनाता है।
[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25इसे मौजूदा पीयर अनुभाग में मिला दें। उसी सार्वजनिक कुंजी के साथ दूसरा ब्लॉक जोड़ना विकल्प जोड़ने का वैध तरीका नहीं है, और wg-quick उन्हें आपके लिए नहीं मिलाएगा। प्रलेखित 25 सेकंड एक उदाहरण है जिसे सामान्य UDP समय-सीमाओं के नीचे रहने के लिए चुना गया है, कोई विशेष अर्थ वाला मान नहीं।
वही निर्देश क्लाउड पक्ष पर रखने से इस समस्या में मदद नहीं मिलती। उस पीयर के पैकेट पहले से ही एक सार्वजनिक पते से आ रहे हैं, इसलिए जिस दिशा में मायने रखती है वहाँ कोई मैपिंग बचाने की ज़रूरत नहीं। यह ट्रैफ़िक बढ़ाता है और कुछ नहीं बदलता।
अंतराल का अनुमान लगाने के बजाय टाइमर पढ़ें
keepalive इसलिए काम करते हैं क्योंकि वे स्थिति के समाप्त होने से अधिक बार आते हैं। यह समय-सीमा को वह संख्या बनाता है जो आपको वास्तव में चाहिए, और Linux पर इसे अनुवाद करने वाले उपकरण पर पढ़ा जा सकता है:
sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820पहला मान उस UDP प्रवाह के लिए समय-सीमा है जो केवल एक दिशा में देखा गया है, और दूसरा उत्तर देखे जाने के बाद लागू होता है। दोनों आमतौर पर छोटे होते हैं, और शांत हो जाने वाली मैपिंग आपके प्रवाह पर जो लागू होता है उसी का पालन करेगी।
उस संख्या की तुलना अपने अंतराल से करें। 30 सेकंड की समय-सीमा के नीचे 25 सेकंड का keepalive काम करता है; 15 सेकंड की समय-सीमा के नीचे वही keepalive काम नहीं करता। कितनी भी पुनःप्रयास करने से यह गणित नहीं बदलता। कुछ उपभोक्ता राउटर और मोबाइल ऑपरेटर Linux के डिफ़ॉल्ट से कहीं छोटे मान इस्तेमाल करते हैं, इसलिए एक नेटवर्क पर काम करने वाला कॉन्फ़िगरेशन दूसरे पर विफल हो जाता है।
| Observation | What it means | Reasonable response |
|---|---|---|
| Works after traffic, dies when idle | Mapping or firewall state expiring | Lower the keepalive interval |
| Never works, even immediately | No return route, listener or firewall | Stop tuning keepalive |
| Works for hours, then dies once | Carrier-side translation or address change | Check the endpoint and logs together |
श्रोता और फ़ायरवॉल को अलग-अलग जाँचें
जीवित मैपिंग आवश्यक है और पर्याप्त नहीं। घर के बॉक्स पर एप्लिकेशन को सही पते पर सुनना चाहिए, और होस्ट फ़ायरवॉल को डिक्रिप्ट होने के बाद पैकेट की अनुमति देनी चाहिए।
sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/healthअगर सॉकेट केवल भौतिक इंटरफ़ेस के पते से बंधा है, सुरंग के पते से नहीं, तो सुरंग पर आने वाले पैकेट फ़ायरवॉल से पूछे जाने से पहले ही गिरा दिए जाते हैं। यह विफलता क्लाउड पक्ष से मैपिंग समस्या जैसी ही दिखती है, और हर keepalive समायोजन के बाद भी बनी रहती है।
अनुमत सूची की जाँच दूसरी दिशा में भी उतनी ही महत्वपूर्ण है। क्लाउड पीयर को जवाब देने के लिए घर के सुरंग पते को स्रोत के रूप में अनुमति देनी होगी, और घर के पीयर को क्लाउड पते को गंतव्य के रूप में अनुमति देनी होगी। keepalive पैकेट प्रमाणित ट्रैफ़िक हैं और वही नियम लागू करते हैं, इसलिए काम करता दिखने वाला keepalive ऐसे एप्लिकेशन के साथ रह सकता है जो काम नहीं करता।
बदलाव को रोल आउट करें और उसकी सीमाएँ जानें
सेटिंग लागू करें, अगर यही आपका अपडेट तरीका है तो इंटरफ़ेस को फिर से शुरू करें, और फिर तत्काल परीक्षण के बजाय निष्क्रियता परीक्षण दोहराएँ। पहले पढ़ी गई समय-सीमा से अधिक प्रतीक्षा करें, उल्टा अनुरोध करें और पुष्टि करें कि दोनों सिरों पर काउंटर चले हैं।
अंतराल और मापी गई समय-सीमा को उसके बगल में दर्ज करें। भविष्य में राउटर के फ़र्मवेयर में बदलाव, या मोबाइल कनेक्शन पर जाना, समय-सीमा बदल सकता है। नोट ही किसी को मान कॉपी करने के बजाय दोबारा निकालने देता है। एक पंक्ति में दो संख्याएँ बाद में पूरी जाँच बचा लेती हैं।
स्थायी keepalive स्थिति की रक्षा करते हैं। वे पोर्ट नहीं खोलते, अनुमत सूची में प्रविष्टि नहीं जोड़ते, और किसी श्रोता को प्रकट नहीं करते। जब उल्टा कनेक्शन बिल्कुल काम नहीं करता, तो दोष उन तीन में से एक है, और WireGuard की त्वरित शुरुआत keepalive सेटिंग का वर्णन उन्हीं संकीर्ण शर्तों में करती है।