WireGuard हैंडशेक काम करता है, सेवा नहीं

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

जो पहला न मिले वहीं रुकें, और बाकी के लिए नियम न जोड़ें।

हैंडशेक केवल टनल सिद्ध करता है

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

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

सुनने वाले और मार्ग को पढ़ें

क्लाइंट पर पुष्टि करें कि सर्वर का टनल पता टनल में रूट होता है। सर्वर पर पुष्टि करें कि क्लाइंट जिस पते का उपयोग कर रहा है वहाँ सॉकेट मौजूद है, और उसके पीछे की प्रक्रिया वही है जो आपका इरादा था।

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

127.0.0.1 पर सुनने वाला 10.66.0.1 को भेजे गए अनुरोध का कभी उत्तर नहीं देगा, चाहे फायरवॉल कुछ भी अनुमति दे। वाइल्डकार्ड पते पर सुनने वाला उत्तर देगा, जब तक कोई नियम उसे अवरुद्ध न करे। इसलिए किसी भी नियम की जाँच से पहले सॉकेट सूची आधे मामले तय कर देती है। पोर्ट और पता मिलकर तय करते हैं कि अनुरोध पहुँच सकता है या नहीं।

क्लाइंट जो पता उपयोग करता है उसकी तुलना उस पते से करें जो सर्वर के पास टनल इंटरफ़ेस पर वास्तव में है। किसी भी ओर पुराना कॉन्फ़िगरेशन ऐसा अनुरोध बनाता है जो सही ढंग से ऐसे सहकर्मी तक रूट होता है जिसके पास वह पता नहीं है।

स्थानीय इनपुट के लिए नियम लागू करें, फ़ॉरवर्डिंग के लिए नहीं

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

होस्ट खोलने के बजाय इच्छित सेवा तक एक ही अनुमत पोर्ट से परीक्षण करें। फिर एप्लिकेशन की अपनी अधिकृति जाँचें: अनुमत सूची, खाता आवश्यकता या किसी विशेष होस्टनाम से बंधाव ऐसे अनुरोध को अस्वीकार कर सकते हैं जिसे नेटवर्क ने सफलतापूर्वक पहुँचाया हो।

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

नाम, आकार और पहचान की विफलताएँ अलग करें

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

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

दर्ज करें कि कौन-सा जाँच बिंदु विफल हुआ: सॉकेट, इनपुट नियम या एप्लिकेशन नीति। वह एक पंक्ति नेटवर्क खराबी को अधिकृति निर्णय से अलग करती है। यह अगले व्यक्ति को ऐसे पोर्ट खोलने से भी रोकती है जो कभी समस्या नहीं थे।