WireGuard कॉन्फ़िग को पंक्ति दर पंक्ति पढ़ें, Interface से Peer तक

अधिकतर टूटे WireGuard कॉन्फ़िग किसी मान में ग़लती नहीं करते; वे सही मान ग़लत ओर रखते हैं। निजी कुंजी इस मशीन की है, peer दूसरी मशीन की सार्वजनिक कुंजी रखता है, और पता interface ब्लॉक में बैठता है हालाँकि वह बताता है कि सुरंग कहाँ रहती है। फ़ाइल को दो दिशाओं के मिलने की तरह पढ़ें, फिर देखें कि सहायक स्क्रिप्ट ने ऊपर क्या जोड़ा। प्रोटोकॉल में फ़ाइल से कम फ़ील्ड हैं, और अतिरिक्त फ़ील्ड अलग से जानने लायक हैं।

Interface की कुंजियाँ इस मशीन का वर्णन करती हैं

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

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

असली क्लाइंट वाले [Interface] ब्लॉक में बाक़ी सब कुछ आमतौर पर wg-quick जोड़ता है: DNS, MTU, Table, और हुक पंक्तियाँ। ये प्रोटोकॉल फ़ील्ड नहीं हैं, और नंगा wg सेटअप इन्हें पूरी तरह अनदेखा करता है।

हर peer प्रविष्टि एक दूसरा पक्ष बताती है

[Peer] ब्लॉक दूर का पक्ष है। PublicKey उस पक्ष की निकाली गई कुंजी है, कभी उसकी निजी कुंजी नहीं, और PresharedKey एक वैकल्पिक अतिरिक्त रहस्य है जिसे दोनों पक्षों को एक जैसा रखना होता है। Endpoint यह है कि कहाँ भेजना है, और PersistentKeepalive इस होस्ट से कहता है कि अंतराल के बाद पैकेट भेजे जब और कुछ बाहर न जा रहा हो।

यहाँ की अधिकतर उलझन दो ग़लतियाँ समझाती हैं। अपनी निजी कुंजी को peer ब्लॉक में नक़ल करने से दोनों सिरे एक ही पहचान साझा करने लगते हैं, और हैंडशेक ऐसे विफल होता है जिसका लॉग ख़राब बनता है। Endpoint को क्लाइंट पर छोड़ देना आमतौर पर जानबूझकर होता है, क्योंकि सर्वर पता आने वाले हैंडशेक से सीखता है; जिस सर्वर को शुरू करना है उस पर इसे छोड़ देना ऐसा नहीं है। यह भी याद रखें कि keepalive एक NAT मैपिंग खुली रखता है, और यह थ्रूपुट नहीं सुधारता न विलंब घटाता है, इसलिए जब ट्रैफ़िक पहले से बह रहा हो तो तीस सेकंड के अतिरिक्त पैकेट कुछ नहीं ख़रीदते।

AllowedIPs रूटिंग है, अनुमति सूची नहीं

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

संकीर्ण AllowedIPs सर्वर पर क्लाइंट के लिए इसका अर्थ है कि सर्वर केवल वही पैकेट स्वीकार करेगा जो उन स्रोतों का दावा करें, और केवल वही गंतव्य उस क्लाइंट को भेजेगा। एक पक्ष को दूसरे को चौड़ा किए बिना चौड़ा करें, और आपको ऐसी सुरंग मिलेगी जो ऊपर आती है और कुछ पार नहीं कराती।

wg-quick प्रोटोकॉल के आसपास क्या जोड़ता है

wg-quick वही फ़ाइल पढ़ता है और वे नेटवर्क चरण करता है जो प्रोटोकॉल ऑपरेटिंग सिस्टम पर छोड़ता है। यह interface पता सौंपता है, AllowedIPs से निकले मार्ग जोड़ता है, रिज़ॉल्वर सेटिंग्स लिखता है और हुक कमांड क्रम से चलाता है।

वह परत पारंपरिक असममिति समझाती है। 0.0.0.0/0 और DNS पंक्ति वाली फ़ाइल क्लाइंट को डिफ़ॉल्ट मार्ग और रिज़ॉल्वर देती है, और सर्वर के फ़ॉरवर्डिंग या NAT नियमों को कुछ भी नहीं करती। वे सर्वर के अपने कॉन्फ़िग के हैं, और कोई क्लाइंट फ़ाइल उन्हें नहीं दे सकती।

फ़ाइल के लिए एक ही मालिक रखें। SaveConfig सक्षम होने के दौरान उसे हाथ से संपादित करने का अर्थ है कि अगली बार interface के नीचे जाने पर आपका संपादन ग़ायब हो जाएगा, और interface आपको नहीं बताएगा कि ऐसा हुआ।

फ़ाइल नहीं, लागू स्थिति जाँचें

फ़ाइल एक इरादा है। लागू स्थिति वह है जो कर्नेल रखता है, और सक्रियण के बाद जब भी किसी सहायक, drop-in या हुक ने कुछ संपादित किया, दोनों अलग हो जाते हैं।

जीवंत स्थिति और पताकरण साथ पढ़ें, फिर दोनों की तुलना उससे करें जो आपने लिखा:

sudo wg show
ip -4 addr show dev wg0
ip -4 route show dev wg0
grep -v "^#" /etc/wireguard/wg0.conf

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