पहिलो बुट: 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

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

गेटवेमा, peer प्रविष्टि जानाजान साँघुरो छ:

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

यन्त्रको गन्तव्य सूची गेटवे peer मा प्रतिलिपि नगर्नुहोस्। यन्त्रमा त्यो सूचीले टनेलमा के रुट गर्ने भन्छ; गेटवेमा यसले यो peer ले कुन स्रोत ठेगाना प्रयोग गर्न सक्छ भन्छ, र यी फरक भनाइ हुन्।

फर्वार्डिङ, फायरवाल नियम र व्यवस्थापन नेटवर्कतर्फ फर्कने बाटोले अझै अनुमोदित पहुँचलाई अनुमति दिनुपर्छ। दर्ता गरिएको peer त्यसको पछाडिका प्रत्येक एप्लिकेसनका लागि अनुमति होइन।

चरण 4: दर्तालाई जीवनचक्र अवस्थाका रूपमा स्थापित गर्नुहोस्

प्रत्येक कन्फिगरेसनको मालिकमार्फत गेटवे रेकर्ड र यन्त्र प्रोफाइल लागू गर्नुहोस्, त्यसपछि इच्छित पहिचान र ठेगाना स्वीकार भएपछि मात्र दर्तालाई पूर्ण चिन्ह लगाउनुहोस्। पुनः प्रयासहरूले दोस्रो peer वा दोस्रो ठेगाना तोक्नुको सट्टा त्यही रेकर्ड मिलाउनुपर्छ।

बाधित प्रोभिजनिङका लागि पुनःप्राप्ति बाटो राख्नुहोस्, गेटवेले कुञ्जी स्वीकार गरे पनि यन्त्रले कहिल्यै आफ्नो प्रोफाइल नलेखेको अवस्थासमेत।

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