WireGuard केवल तब काम करता है जब सर्वर पहले भेजे: एंडपॉइंट की जानकारी

टनल केवल तब काम करती दिखती है जब सर्वर पहले कुछ भेजता है। क्लाइंट से शुरू करें और कुछ नहीं होता, कुछ सेकंड रुकें, फिर कोशिश करें और वह सफल हो जाता है। सामान्य निदान टूटा हुआ NAT है, और सामान्य निदान गलत है। जो बदला वह यह है कि एक पीयर ने सीख लिया कि दूसरा कहाँ रहता है।

एंडपॉइंट की जानकारी, पहुँच नहीं

WireGuard पीयर तब तक हैंडशेक शुरू नहीं करेगा जब तक उसे पता न हो कि उसे कहाँ भेजना है। कॉन्फ़िगरेशन उसे पता और पोर्ट के एंडपॉइंट के रूप में देता है, और चल रही स्थिति उस एंडपॉइंट को ट्रैक करती है जिस पर वह अभी विश्वास करता है।

wg show उस तस्वीर के दोनों पक्ष दिखाता है, और आउटपुट में एंडपॉइंट के बिना कोई पीयर कुछ भी शुरू नहीं कर सकता, चाहे उसकी सार्वजनिक कुंजी और अनुमत प्रीफ़िक्स कितने ही सही हों। कोई भी नियम बदलने से पहले क्लाइंट के दृश्य की सर्वर से तुलना करें, क्योंकि दोनों अक्सर इस पर सहमत नहीं होते कि कौन क्या जानता है।

पीयर एंडपॉइंट कैसे सीखता है

WireGuard जानबूझकर शांत है। जब सही ढंग से प्रमाणित पैकेट किसी ऐसे पते से आता है जिसकी पीयर को अपेक्षा नहीं थी, तो कार्यान्वयन उस पीयर के एंडपॉइंट को नए स्रोत पर अद्यतन कर देता है, और नेटवर्क बदलने वाले लैपटॉप पर रोमिंग इसी तरह काम करती है। वह व्यवहार दिशा-निर्भरता को समझाता है: यदि सर्वर पहले भेजता है और उसका पैकेट क्लाइंट तक पहुँचता है, तो क्लाइंट सर्वर का वर्तमान पता सीख लेता है और उत्तर दे सकता है। तब तक उसके पास भेजने की कोई जगह नहीं है। तंत्र प्रमाणित रोमिंग है, पहले उपयोग पर भरोसे की शॉर्टकट नहीं, क्योंकि एंडपॉइंट के खिसकने से पहले पैकेट का वैध होना ज़रूरी था।

wg के लिए टूल दस्तावेज़ उस अद्यतन का वर्णन करता है, और अगर आप उसके इर्द-गिर्द डिज़ाइन करने वाले हैं तो इसे एक बार पढ़ना उचित है।

स्थिति वाला ट्रांसलेशन अपनी दिशा जोड़ता है

जहाँ UDP किसी अनुवाद करने वाले गेटवे से गुज़रता है, वहाँ गेटवे जो पहला पैकेट देखता है उसके लिए स्थिति बनाता है। RFC 4787 उस व्यवहार और उन समय-सीमाओं का वर्णन करता है जो अंततः मैपिंग हटा देती हैं। निष्क्रिय मैपिंग समाप्त हो जाती है, और दूर की ओर से आने वाला पैकेट तब मेज़बान तक पहुँचने से पहले गेटवे द्वारा गिरा दिया जाता है। पूरी सुबह काम करने वाली टनल ठीक इसी कारण दोपहर में उत्तर देना बंद कर देती है।

यह दूसरा और स्वतंत्र तंत्र है जो वही दिशात्मक लक्षण पैदा करता है। एंडपॉइंट की जानकारी और ट्रांसलेशन स्थिति दोनों सही होनी चाहिए, और एक को ठीक करने से दूसरा ठीक नहीं होता।

जो दिशा आप वास्तव में चाहते हैं उसे कॉन्फ़िगर करें

ऐसे क्लाइंट के लिए जिसे कनेक्शन शुरू करना है, सर्वर का एंडपॉइंट क्लाइंट के पीयर अनुभाग में रखें और उसे वहीं रहने दें। सर्वर के पहले भेजने पर भरोसा करना ट्रैफ़िक के क्रम में उस संयोग पर भरोसा करना है जो शांत नेटवर्क में बदल जाएगा। कॉन्फ़िगरेशन को इच्छित दिशा बतानी चाहिए, उसे खोजना नहीं चाहिए।

अनुवाद के पीछे रहने वाले ऐसे पीयर के लिए जिसे पहुँच में बने रहना है, उस ओर लगातार keepalive सक्षम करें। हर 25 सेकंड में keepalive सामान्य शुरुआती मान है, और इसका उद्देश्य टनल को जाँचना नहीं बल्कि मैपिंग को खुला रखना है। इसे ढोने के लिए एक ही ओर चुनें, क्योंकि दोनों ओर सक्षम करने से परिणाम सुधरे बिना ट्रैफ़िक और लॉग का शोर दोगुना हो जाता है।

ट्रिगर से पहले और बाद की स्थिति की तुलना करें

जिस क्षण यह विफल हो, उस समय दोनों दृश्य कैप्चर करें, फिर सर्वर के भेजने के बाद दोबारा। पहला कमांड एंडपॉइंट और हैंडशेक की आयु दिखाता है। दूसरा दिखाता है कि पोर्ट के लिए कोई ट्रांसलेशन प्रविष्टि है या नहीं। कैप्चर दिखाता है कि वास्तव में कौन सी दिशा तार से गुज़री, और रूट जाँच पुष्टि करती है कि क्लाइंट उस ट्रैफ़िक को बिल्कुल कहीं और नहीं भेज रहा है।

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

एंडपॉइंट कॉलम और ट्रांसलेशन प्रविष्टि साथ लिखें। बिना एंडपॉइंट वाला पीयर और बिना मैपिंग वाला गेटवे दो अलग खराबियाँ हैं। इनमें से केवल एक को keepalive ठीक करता है।