WireGuard 5G शाखा: शाखा को ही हब डायल करने दें

शाखा को हब की ओर इंगित करना इस डिज़ाइन का आसान आधा है, जब शाखा बदलते सेलुलर पते के पीछे बैठी हो और हब के पास स्थिर नाम हो। तब हब शाखा को प्रमाणित ट्रैफ़िक से सीखता है, ऐसे रिकॉर्ड से नहीं जिसे आपको अद्यतन रखना पड़े। अनुबंध सरल है: शाखा हमेशा शुरू करती है।

इसे जानबूझकर कॉन्फ़िगर करें और फिर उस हिस्से को जाँचें जिसे लोग काम करता मानते हैं। दोनों चरणों में मिनट लगते हैं, और इन डिज़ाइनों की विफलता आम तौर पर दूसरे में होती है।

कौन-सा पक्ष स्थिर एंडपॉइंट रखता है

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

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

शाखा को ऐसा कॉन्फ़िगरेशन दें जो पुनः क्रमांकन सह ले

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

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

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

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

मैपिंग और फ़ेलओवर जाँचें

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

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

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

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

यह डिज़ाइन क्या हल नहीं करता

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

शाखा के प्रीफ़िक्स को हर दूसरी साइट से अलग रखें, और सीमित करें कि उसका गेटवे क्या अग्रेषित करेगा। स्थिर हब एंडपॉइंट खोज को सरल बनाता है और राउटिंग डिज़ाइन, पता नियोजन या इस प्रश्न के लिए कुछ नहीं करता कि कौन-से अनुप्रयोग मार्ग फ़ेलओवर सह लेंगे।

रनबुक में चार बातें लिखें: कौन शुरू करता है, कौन-से प्रीफ़िक्स अनुमत हैं, keepalive कितना लंबा है, और प्राथमिक लिंक गिरने पर क्या होता है। भविष्य के ऑपरेटर को रात तीन बजे वास्तव में जिन पंक्तियों की ज़रूरत होती है, वही ये हैं।