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 त्याचे कॉन्फिग लागू केल्याशिवाय तयार झाले आहे। पत्ते आणि मार्ग असूनही काउंटर शून्यावर राहिले तर फाइल लोड झाली आहे आणि हस्तांदोलन अपयशी होत आहे, ही विभाग-क्रमाची नाही तर किल्ली किंवा टोकाची समस्या आहे। संपादनापूर्वी दोन्ही दृश्ये तुलना करा, कारण त्यांच्यातील अंतर हाच सहसा खरा दोष असतो।