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 किती लांब आहे, आणि प्राथमिक लिंक पडल्यावर काय होते। भविष्यातील ऑपरेटरला रात्री तीन वाजता खरोखर ज्या ओळींची गरज असते त्या याच आहेत।