दुई सेलुलर साइट, भित्री पोर्ट छैन: काम गर्ने हब बनाउनुहोस्

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

कुनै पनि साइटमा डायल गर्न सकिँदैन, त्यसैले दुवैले बाहिर डायल गर्नुपर्छ

डिजाइन गर्नुअघि बाधा पुष्टि गर्नुहोस्। यदि अपरेटरले WAN इन्टरफेसलाई निजी ठेगाना दिन्छ भने, साइटको आफ्नै राउटरमा कुनै पनि पोर्ट फर्वार्डिङले यसलाई पुग्न सकिने बनाउँदैन, किनकि अनुवाद माथि हुन्छ। त्यही लिङ्कमा सार्वजनिक IPv6 ठेगाना हुन सक्छ र डिजाइन पूरै बदल्न सक्छ, त्यसैले जाँचले दुवै परिवार समेट्छ। प्रत्येक साइटका लागि उत्तर लेख्नुहोस्, किनकि दुवैले एउटै अपरेटर साझा गरे पनि तिनीहरूका बाधा विरलै एउटै हुन्छन्।

सामान्य सेलुलर अवस्था अपरेटरको अनुवादित दायराको ठेगाना र त्यसबाट जाने पूर्वनिर्धारित मार्गजस्तो देखिन्छ। यो सुधार गर्नुपर्ने खराबी होइन; हब रहनुको कारण यही हो। तपाईं खोजिरहनुभएको कुरा साइटले पहिले नबोलीकन तेस्रो पक्ष पुग्न सक्ने कुनै पनि ठेगाना हो।

तपाईंको अगाडि रहेको साइटको ठेगाना प्रश्नको उत्तर दुई आदेशले दिन्छ। तिनीहरूलाई साइटको राउटरमा चलाउनुहोस्, त्यसको पछाडिको ल्यापटपमा होइन:

ip -4 addr show scope global
ip -6 addr show scope global

कसले पियरहरूको चिनारी गराउँछ र कसले प्याकेट बोक्छ

चिनारी र ढुवानी अलग काम हुन्, जसलाई उत्पादनहरूले सीमा देखाउनै नदिई एकै ठाउँमा जोड्छन्। भेटघाट संयन्त्रले दुई पियरलाई सम्भावित मार्ग खोज्न मद्दत गर्छ; सिधा मार्ग नभए रिलेले तिनका प्याकेट बोक्छ। पियरहरूको चिनारी गराउने सेवा किनेर तपाईंले राउटर पाउनुहुन्न, र यही भिन्नताले डिजाइनलाई हब आवश्यक छ कि छैन भन्ने निर्धारण गर्छ।

ट्राभर्सलको आफ्नै शब्दावली छ, र शब्दहरूले भूमिका बताउँछन्, ग्यारेन्टी होइन। ICE स्पेसिफिकेसन ले उम्मेदवार र जडान जाँचको वर्णन गर्छ, STUN ले ठेगाना अनुवादबारे जान्ने एउटा तरिका बताउँछ, र TURN ले यसलाई लागू गर्ने अनुप्रयोगका लागि रिले ढुवानीको वर्णन गर्छ। यी कुनै पनि संयन्त्र सामान्य गेटवेमा देखिँदैन, किनकि तपाईंले यसलाई खोज ठेगानातर्फ निर्देशित गर्नुभयो। ट्राभर्सललाई उत्पादन क्षमताका रूपमा जाँच्नुहोस्, र परीक्षणले उल्टो नदेखाएसम्म रिले मान्नुहोस्।

प्रत्येक साइटका लागि एउटा मार्ग, पियरको स्वामित्वमा

हबलाई प्रत्येक साइटका लागि एउटा सुरुङ, प्रत्येकको पछाडि छुट्टै LAN प्रिफिक्स, र प्रत्येक प्रिफिक्सका लागि स्वामीको नाम बताउने मार्ग चाहिन्छ। उदाहरणमा हब 10.61.0.1 हो, साइट A भनेको LAN 10.60.10.0/24 भएको 10.61.0.11 हो, र साइट B भनेको LAN 10.60.20.0/24 भएको 10.61.0.12 हो। तलको हरेक मार्ग सुरुङ इन्टरफेसतर्फ होइन, प्रिफिक्स हुने पियरतर्फ सङ्केत गर्छ:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

फर्वार्डिङ सक्षम हुनुपर्छ, नभए प्याकेट हबमै रोकिन्छन् र कारण देखाउने कुनै त्रुटि पनि हुँदैन। अन्तिम आदेशले वास्तविक प्रश्नको उत्तर दिन्छ, किनकि यसले स्रोतलाई खोजमा समेटेर साइट A को LAN बाट साइट B को LAN सम्म प्याकेट कुन बाटो जान्छ भनी सोध्छ। सुरुङ इन्टरफेसको नाम बताउने खोजलाई प्रमाण मान्नुहोस्, र पूर्वनिर्धारित मार्गमा खस्नेलाई पहेली होइन, हराएको मार्ग मान्नुहोस्। त्यसपछि ट्रान्जिट जानाजानी सीमित गर्नुहोस्, किनकि प्रत्येक पियरबीच फर्वार्ड गर्ने हबले दुई साइटलाई समतल सञ्जाल बनाइदिन्छ र तपाईंले ठान्नुभएको पहुँच नीति लागू भइरहँदैन।

इन्क्रिप्शन कहाँ अन्त्य हुन्छ पनि निर्धारण गर्नुहोस्। जब हबले सुरुङका दुई छेउ समात्छ, त्यो मेसिनको अपरेटर र त्यसको कार्यभार विश्वास र उपलब्धताको मोडेलमा जोडिन्छन्, र त्यसको ब्यान्डविथ बाटोको भाग बन्छ।

अपरेटरमार्फत हरेक म्यापिङ जीवित राख्नुहोस्

हरेक साइटले आफ्नै सुरुङ सुरु गर्छ, र हरेकले अनुवाद म्यापिङ जीवित राख्नुपर्छ, नभए अपरेटरले त्यो बिर्सन्छ। सुरु गर्ने पक्षको कीपअलाइभ सन्देशले त्यो म्यापिङ ह्यान्डसेकबीच जोगाउँछ। स्वीकृत प्रिफिक्सलाई हबको ठेगाना र टाढाको LAN मा सीमित गर्नुहोस्, ताकि सम्झौता भएको पियरले आफ्नो नभएको प्रिफिक्स दाबी गर्न नसकोस्:

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

अर्को साइटमा त्यसको आफ्नै टाढाको प्रिफिक्ससहित ब्लक प्रतिबिम्बित गर्नुहोस्, र पूरै सुरुङ दायरा स्वीकार गर्ने चाहनाको प्रतिरोध गर्नुहोस्। रोकिएर नयाँ स्रोत पोर्टबाट फेरि सुरु हुने ह्यान्डसेक म्याद सकिएको म्यापिङको हस्ताक्षर हो, र ह्यान्डसेकका समयचिह्न त्यो भएको प्रमाण हुन्। अपरेटरको समयसीमाभन्दा छोटो अन्तरालले म्याद सकिनबाट रोक्छ, पछि सुधार्दैन। अपरेटरले आफ्नो अनुवाद व्यवहार बदल्दा ती समय पनि सँगै बदलिने अपेक्षा गर्नुहोस्।

दुवै दिशा प्रमाणित गर्नुहोस्, त्यसपछि पुनर्प्राप्ति प्रमाणित गर्नुहोस्

प्रमाणीकरण दिशात्मक छ, त्यसैले A बाट B मा ping ले डिजाइनको आधा भाग प्रमाणित गर्छ र फर्कने मार्गबारे केही पनि होइन. हबमा त्यही स्रोत-सजग खोज प्रयोग गरी प्रतिक्रिया मार्ग जाँच्नुहोस्, त्यसपछि अर्को पट्टिबाट परीक्षण दोहोर्‍याउनुहोस्। नयाँ ह्यान्डसेक पनि प्रमाणमा पर्छन्, किनकि एक घण्टा निष्क्रिय सुरुङले पुरानो म्यापिङ परीक्षण गरिरहेको हुन सक्छ:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

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