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 कति लामो छ, र प्राथमिक लिंक खस्दा के हुन्छ। भविष्यको अपरेटरलाई राति तीन बजे साँच्चै चाहिने ती लाइनहरू नै हुन्।