पहला बूट: WireGuard उपकरणों के फ़्लीट के लिए नामांकन

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

इमेज क्या ले जाती है, और क्या नहीं

पैकेज, प्लेसहोल्डर वाला टेम्पलेट, गेटवे की सार्वजनिक कुंजी और नामांकन क्लाइंट भेजें। टेम्पलेट एक आकार है, कोई रहस्य नहीं: उसे प्रोविज़निंग उपयोगकर्ता के लिए पठनीय होना चाहिए और उसमें कोई कुंजी सामग्री नहीं होनी चाहिए।

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

चरण 1: कुंजी स्थानीय रूप से बनाएँ

अंतर्निहित नेटवर्क कनेक्शन के स्वीकृत और कार्यरत होने के बाद संरक्षित निर्देशिका में निर्माण चलाएँ। सबशेल umask परिवर्तन को इसी कार्रवाई तक स्थानीय रखता है, और set -C मौजूदा फ़ाइल को अधिलेखित करने से इंकार करता है:

(
    umask 077
    set -C
    wg genkey > /etc/wireguard/device.key &&
        wg pubkey < /etc/wireguard/device.key > /etc/wireguard/device.pub
)

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

पुनः प्रयासों के दौरान लंबित कुंजी बनाए रखें। हर अस्थायी नेटवर्क विफलता के बाद पहचान दोबारा बनाना ही वह तरीका है जिससे फ़्लीट में ऐसे अनाथ peer रह जाते हैं जिन्हें कोई डिवाइस से नहीं जोड़ सकता।

चरण 2: डिवाइस रिकॉर्ड को अधिकृत करें

मान लें कि इन्वेंटरी इस बोर्ड को device-042 कहती है और इसे 10.90.0.42/32 आवंटित करती है। नामांकन सेवा को सत्यापित करना होगा कि यह अनुरोधकर्ता उस रिकॉर्ड का हकदार है। फ़ॉर्म में टाइप किया गया सीरियल नंबर प्रमाण नहीं है, क्योंकि सीरियल नंबर डिब्बे के बाहर छपे होते हैं।

प्रति-डिवाइस बूटस्ट्रैप क्रेडेंशियल, किसी ऑपरेटर की स्वीकृति, या हार्डवेयर-समर्थित प्रमाणन दावे को स्थापित कर सकते हैं। अनुरोध की अखंडता और प्रतिक्रिया की प्रामाणिकता की रक्षा करें, और एक साझा VPN रहस्य को एक साझा फ़ैक्टरी क्रेडेंशियल से न बदलें।

पंजीकृत रिकॉर्ड डिवाइस, उसकी सार्वजनिक कुंजी, उसे आवंटित पता और उसकी अनुमत प्रबंधन भूमिका को बाँधता है। WireGuard स्वयं कोई नामांकन API परिभाषित नहीं करता, इसलिए वह सेवा ऐसी चीज़ है जिसे आप जानबूझकर बनाते और चलाते हैं।

चरण 3: दो मेल खाती कॉन्फ़िगरेशन लिखें

डिवाइस को ऐसी प्रोफ़ाइल चाहिए जो प्रबंधन प्रीफ़िक्स को टनल में रूट करे, और गेटवे को ऐसी peer प्रविष्टि चाहिए जो केवल इस डिवाइस के अपने स्रोत पते की अनुमति दे। गेटवे 10.90.0.1 पर और प्रबंधन नेटवर्क 10.60.0.0/16 होने पर डिवाइस पक्ष ऐसा दिखता है:

[Interface]
PrivateKey = <device-042 private key>
Address = 10.90.0.42/32

[Peer]
PublicKey = <trusted gateway public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.90.0.1/32, 10.60.0.0/16
PersistentKeepalive = 25

कोष्ठकों के भीतर के मान प्लेसहोल्डर हैं, कुंजियाँ नहीं। keepalive तब मायने रखता है जब बोर्ड NAT के पीछे हो और पहुँच योग्य बना रहना हो; यह हर जगह आवश्यक नहीं है, और आदतवश इसे जोड़ना रेडियो को बिना कारण जगाए रखता है।

गेटवे पर, peer प्रविष्टि जानबूझकर संकीर्ण है:

[Peer]
PublicKey = <device-042 public key>
AllowedIPs = 10.90.0.42/32

डिवाइस की गंतव्य सूची को गेटवे peer पर नकल न करें। डिवाइस पर वह सूची कहती है कि टनल में क्या रूट करना है; गेटवे पर वह कहती है कि यह peer कौन से स्रोत पते उपयोग कर सकता है, और ये अलग कथन हैं।

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

चरण 4: नामांकन को जीवनचक्र स्थिति के रूप में स्थापित करें

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

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

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