दो पीयर वाला WireGuard परीक्षण कैसे बनाएँ जो एक ही मार्ग सिद्ध करे

डिफ़ॉल्ट रूट, LAN प्रीफ़िक्स, DNS और फ़ायरवॉल अपवाद ले जाने वाला WireGuard परीक्षण आपको यह नहीं बता सकता कि इनमें से कौन टूटा। इसे दो पीयर, एक पता जोड़ी और एक अनुमत सेवा तक घटा दें, और विफलता के छिपने की कोई जगह नहीं बचेगी। उबाऊ आधार ही निदान है। इसे पहले बनाएँ; इसमें पंद्रह मिनट लगते हैं और अनुमान लगाने में बिताई जाने वाली दोपहर बच जाती है।

आधार जो सिद्ध करता है वह अधिकांश लोगों की अपेक्षा से संकीर्ण है। यह सिद्ध करता है कि दो पहचानें सहमत हैं, UDP सुनने वाले पोर्ट तक पहुँचता है और एक अनुमत गंतव्य अनुरोध ले जाता है। फ़ॉरवर्डिंग, NAT, LAN रूट और DNS बाद में जोड़ी जाने वाली अलग विशेषताएँ हैं, एक बार में एक।

कुंजियाँ, पते और एकमात्र एंडपॉइंट

हर सिस्टम पर एक कुंजी जोड़ी बनाएँ और उनके बीच केवल सार्वजनिक आधे हिस्से ले जाएँ। wg genkey | tee privatekey | wg pubkey > publickey प्रलेखित एक-पंक्ति कमांड है, और यह निजी कुंजी को ऐसी फ़ाइल में छोड़ता है जिसे आप बाद में सुरक्षित कर सकते हैं। टनल पते ऐसी श्रेणी से चुनें जो आपके किसी अन्य कॉन्फ़िगरेशन में न दिखे, जैसे 10.99.0.1/24 और 10.99.0.2/24। लिख लें कि कौन-सा पता किस मशीन का है, क्योंकि हर बाद की जाँच उसी मैपिंग पर निर्भर करती है।

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

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

wg से जुड़े फ़ील्ड और जो नहीं हैं

मूल फ़ील्ड समूह छोटा है: Interface के अंतर्गत PrivateKey और ListenPort, Peer के अंतर्गत PublicKey, AllowedIPs और Endpoint। Address और DNS wg के बजाय wg-quick के हैं, और यह अंतर उसी क्षण काटता है जब वही कॉन्फ़िगरेशन किसी दूसरे औज़ार में जाता है।

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs एक साथ दो काम करता है। यह चुनता है कि कौन-से गंतव्य टनल में जाएँगे, और यह पीयर को आगमन पर उन स्रोत पतों का उपयोग करने का अधिकार देता है। इसीलिए दूसरी तरफ़ की प्रतिबिंब प्रविष्टि को आपके टनल पते का ठीक-ठीक नाम लेना होता है; ग़लत पीयर के लिए /32 रूटिंग समस्या की तरह पढ़ा जाता है और अधिकार समस्या की तरह व्यवहार करता है। WireGuard त्वरित शुरुआत फ़ील्ड नामों की तुलना करनी हो तो मानक शब्दावली के साथ वही दो-पीयर आकार दिखाता है।

आइकन के बजाय हैंडशेक पढ़ना

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

दोनों विफलताएँ अलग-अलग जाँचों की ओर संकेत करती हैं। हैंडशेक बिल्कुल न होना कुंजी असंगति, ग़लत Endpoint, अवरुद्ध UDP या स्वयं हैंडशेक गिरा देने वाले फ़ायरवॉल की ओर इशारा करता है। ऐसा हैंडशेक जो सफल हो पर डेटा कहीं न जाए, AllowedIPs, टनल पते पर न सुनने वाली सेवा, या LAN के लिए पोर्ट स्वीकार करने वाले पर टनल इंटरफ़ेस के लिए नहीं, ऐसे होस्ट फ़ायरवॉल की ओर इशारा करता है। ये सिस्टम के अलग-अलग आधे हैं, और नियम बदलने से पहले आधार इन्हें अलग करता है।

एक अनुमत सेवा सिद्ध करना, फिर उलटी दिशा

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

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

आधार को संदर्भ बनाए रखना

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

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