WireGuard हैंडशेक सफल होता है, लेकिन कोई जवाब वापस नहीं आता

हाल के हैंडशेक अच्छी खबर हैं, और लोग जो वाक्य लिखना चाहते हैं उससे कहीं छोटा दावा हैं। दोनों पक्षों ने प्रमाणित हैंडशेक संदेशों का आदान-प्रदान किया। एप्लिकेशन पैकेट को अब भी अपने आंतरिक गंतव्य तक पहुँचकर वापस आना है।

स्वस्थ कंट्रोल प्लेन और खामोश डेटा प्लेन के बीच यही खाई यहाँ पूरा विषय है। इन्हीं काउंटरों की दो रीडिंग आपको बताती हैं कि आप उसके किस पक्ष पर हैं।

हैंडशेक कुंजियाँ साबित करता है, डिलीवरी नहीं

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

इसलिए टनल पूरी तरह स्थापित हो सकती है जबकि उसके भीतर का हर पैकेट गिरा दिया जाए। गलत राउट किया गया आंतरिक पैकेट और दूसरा रास्ता लेने वाला जवाब क्लाइंट की ओर से एक जैसे दिखते हैं।

एक आंतरिक पता ही पूरा परीक्षण है

एक गंतव्य चुनें और उसी पर टिके रहें। सामने वाले पक्ष का अपना टनल पता सबसे आसान मामला है, और उसके पीछे का होस्ट ठीक एक हॉप जोड़ता है। बदलाव दर्ज किए बिना दोनों के बीच बदलते रहने से ऐसे नतीजे मिलते हैं जिनकी कोई तुलना नहीं कर सकता।

फिर वह रूट देखें जो क्लाइंट चुनता है। अधिक विशिष्ट स्थानीय रूट पैकेट को कहीं और भेज सकता है, WireGuard से पूछे जाने से भी पहले, और ऐसा तब होता है जब घरेलू LAN दूर के रेंज से ओवरलैप करता है।

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

जो पता भौतिक इंटरफ़ेस पर हल होता है, वह सवाल का जवाब दे चुका है। टनल कुछ नहीं गिरा रही। पैकेट उसमें कभी घुसा ही नहीं।

काउंटर सबूत हैं, फैसला नहीं

wg show प्रति पक्ष भेजे और प्राप्त बाइट बताता है, और दोनों संख्याएँ स्वतंत्र रूप से हिलती हैं। एक रीडिंग लें, एक अनुमत अनुरोध करें, फिर उसी मिनट में दूसरी रीडिंग लें।

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

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

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

सामने वाला पक्ष लौटते पैकेट की जाँच खुद करता है

दूर का पक्ष आंतरिक पैकेट तभी स्वीकार करता है जब स्रोत उस पक्ष के allowedips के भीतर आता है। भेजने वाले पर मौजूद रूट काफ़ी नहीं है। प्राप्तकर्ता पर स्रोत प्रविष्टि न होने से लौटता ट्रैफ़िक चुपचाप गिरा दिया जाता है।

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

प्रयोग को ईमानदार रखें

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

छोटा सफल आदान-प्रदान भी हर रास्ते की समस्या को नहीं रद्द करता। बड़े पैकेट वहाँ विफल हो सकते हैं जहाँ छोटे पार होते हैं, और आकार या प्रोटोकॉल से मेल खाने वाला फ़िल्टर लोड में अलग बर्ताव कर सकता है।

हैंडशेक को ज्ञात-कार्यशील चरण मानें और वहीं से आगे बढ़ें। अगला उपयोगी सबूत यह है कि एक आंतरिक अनुरोध कहाँ रुकता है, न कि कुंजियों का नया सेट और अनुमान का एक और दौर।