ZeroTier से LAN तक: UFW रूट नियम, पोर्ट अनुमति नहीं

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

तीन काम, तीन मालिक

प्रबंधित रूट ZeroTier नेटवर्क कॉन्फ़िगरेशन का हिस्सा है। यह सदस्यों को बताता है कि कोई प्रीफ़िक्स किसी विशेष सदस्य पते से पहुँचा जा सकता है।

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

वापसी का मार्ग LAN का है। उसके होस्ट और उसके राउटर को जानना होगा कि ओवरले प्रीफ़िक्स आपके गेटवे के LAN पते से पहुँचा जा सकता है, या फिर किसी को ट्रैफ़िक का अनुवाद करना होगा ताकि यह सवाल ही न उठे।

इनमें से हर एक सही हो सकता है जबकि बाकी विफल हों, और इसीलिए केवल गेटवे को पिंग करने वाला परीक्षण उसके पीछे की सेवा के बारे में कुछ साबित नहीं करता।

प्रबंधित रूट को सदस्य की ओर इंगित करें

इच्छित LAN प्रीफ़िक्स के लिए रूट गेटवे के ओवरले पते से जोड़ें, उसके LAN पते से नहीं। ओवरले पता वह है जहाँ अन्य सदस्य पहुँच सकते हैं; LAN पते का अर्थ केवल तार पर है।

डिज़ाइन के काम करने के लिए सदस्यों को प्रबंधित रूट स्वीकार करने होंगे, और उनके अपने स्थानीय नेटवर्क पहले से वह प्रीफ़िक्स इस्तेमाल नहीं कर सकते जिसकी आप घोषणा कर रहे हैं। घर पर 192.168.60.0/24 पर बैठा दूरस्थ लैपटॉप भी ओवरले से 192.168.60.0/24 को रूट नहीं कर सकता।

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

प्रीफ़िक्स और सदस्य पता उसी नोट में लिखें जिसमें फ़ायरवॉल नियम हैं, क्योंकि सबसे सामान्य खराबी गलत सदस्य की ओर इंगित करने वाला रूट है।

कर्नेल में ट्रांज़िट सक्षम करें

कुछ भी बदलने से पहले चालू फ़ॉरवर्डिंग मान पढ़ें, फिर सेटिंग को उसी तंत्र से स्थायी करें जो आपका सिस्टम पहले से उपयोग करता है, ऐसे एकमुश्त आदेश से नहीं जो रीबूट पर गायब हो जाए।

यदि नीति UFW के पास है, तो उसके रूट नियम स्रोत, गंतव्य और इंटरफ़ेस की जोड़ी के लिए फ़ॉरवर्डिंग व्यक्त करते हैं। ये गेटवे पर ही सेवा खोलने वाले इनबाउंड नियमों से अलग हैं:

sysctl net.ipv4.ip_forward
sudo ufw route allow in on zt3f2a1c9d out on eth0 proto tcp to 192.168.60.20 port 443
sudo ufw status verbose

इंटरफ़ेस का नाम उस होस्ट पर वास्तविक ओवरले उपकरण है, जिसे आप ip link से पढ़ सकते हैं; यह सभी इंस्टॉलेशन में स्थिर स्ट्रिंग नहीं है। यदि होस्ट डिफ़ॉल्ट रूप से फ़ॉरवर्ड करता है और UFW मार्ग में नहीं है, तो रूट नियम अनदेखा किया जाएगा और कर्नेल सेटिंग्स ही मायने रखती हैं।

चुनें कि उत्तर कैसे वापस आते हैं

स्रोत संरक्षण के साथ LAN सेवा असली ओवरले पता देखती है और उस पर उत्तर देती है। इसके लिए LAN होस्ट या उसके राउटर पर ऐसा रूट चाहिए जो ओवरले प्रीफ़िक्स को आपके गेटवे की ओर इंगित करे, और यह Linux बॉक्स के बाहर का बदलाव है।

जब वह रूट नहीं जोड़ा जा सकता, तब सीमित स्रोत अनुवाद अनुरोध को ऐसा दिखाता है जैसे वह LAN पर गेटवे से आया हो। तब उत्तर स्थानीय रूप से लौटते हैं और LAN राउटिंग बदलने की ज़रूरत नहीं होती, पर सेवा लॉग में मूल स्रोत खोने की कीमत चुकानी पड़ती है।

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

दोनों में से कोई विकल्प LAN से मनमाने ओवरले सदस्यों तक बिना माँगी पहुँच नहीं देता। यदि यह चाहिए तो यह अपनी समीक्षा वाला अलग नियम है।

वास्तविक सदस्य से परीक्षण करें

गेटवे से नहीं, किसी अन्य सदस्य से जुड़ें और एक अनुमत सेवा का अनुरोध करें। फिर ऐसी सेवा आज़माएँ जो बंद रहनी चाहिए, और दोबारा जुड़ने के बाद तथा गेटवे रीबूट के बाद दोनों परीक्षण दोहराएँ।

जो सदस्य ONLINE की सूचना देता है, या गेटवे के ओवरले पते पर सफल पिंग, रूट, फ़ॉरवर्ड नियम या वापसी के मार्ग को मान्य नहीं ठहराता:

zerotier-cli listnetworks
ip -4 route get 192.168.60.20
sudo ufw status numbered

दूसरा आदेश दिखाता है कि पैकेट LAN होस्ट के लिए कौन-सा इंटरफ़ेस इस्तेमाल करेगा, और तीसरा दिखाता है कि रूट नियम उस रूप में मौजूद है या नहीं जिसकी आपने नीयत की थी। यदि दोनों सही लगें और सेवा फिर भी समय-सीमा पर अटके, तो बाकी संदिग्ध वापसी का मार्ग है।