दो सेलुलर साइट, कोई इनबाउंड पोर्ट नहीं: ऐसा हब बनाएँ जो काम करे

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

किसी भी साइट को डायल नहीं किया जा सकता, इसलिए दोनों को बाहर डायल करना होगा

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

सामान्य सेलुलर स्थिति ऑपरेटर की अनूदित श्रेणी के पते जैसी दिखती है जिसके भीतर से डिफ़ॉल्ट रूट गुज़रता है। यह ठीक करने लायक खराबी नहीं है; यही हब के होने का कारण है। आप ऐसा कोई भी पता खोज रहे हैं जहाँ साइट के पहले बोले बिना कोई तीसरा पक्ष पहुँच सके।

आपके सामने मौजूद साइट के पते के सवाल का जवाब दो कमांड देते हैं। इन्हें साइट के राउटर पर चलाएँ, उसके पीछे के लैपटॉप पर नहीं:

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

पीयरों का परिचय कौन कराता है और पैकेट कौन ढोता है

परिचय और परिवहन अलग काम हैं जिन्हें उत्पाद अक्सर रेखा दिखाए बिना एक साथ बाँध देते हैं। मिलन तंत्र दो पीयरों को उम्मीदवार मार्ग खोजने में मदद करता है; सीधा मार्ग न हो तो रिले उनके पैकेट ढोता है। पीयरों का परिचय कराने वाली सेवा खरीदने से आपको राउटर नहीं मिलता, और यही अंतर तय करता है कि डिज़ाइन को हब की ज़रूरत है या नहीं।

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

हर साइट के लिए एक रूट, जिसका स्वामी एक पीयर है

हब को हर साइट के लिए एक टनल, हर एक के पीछे अलग LAN प्रीफ़िक्स, और हर प्रीफ़िक्स के लिए एक रूट चाहिए जो उसके स्वामी का नाम ले। उदाहरण में हब 10.61.0.1 है, साइट A 10.61.0.11 है जिसका LAN 10.60.10.0/24 है, और साइट B 10.61.0.12 है जिसका LAN 10.60.20.0/24 है। नीचे का हर रूट उस पीयर की ओर इशारा करता है जो प्रीफ़िक्स रखता है, टनल इंटरफ़ेस की ओर नहीं:

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 विकल्प, और हब के अनुपलब्ध होने पर व्यवहार दर्ज करें। हब अब आपके उपलब्धता मॉडल का हिस्सा है, इसलिए इसे लिख लें, बजाय इसके कि किसी रुकावट के दौरान पता चले।