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 होस्टसाठी कोणता इंटरफेस वापरेल, आणि तिसरा दाखवतो की मार्ग नियम तुम्ही ठरवलेल्या स्वरूपात आहे का। दोन्ही बरोबर वाटत असूनही सेवा अजूनही वेळ संपवत असेल, तर उर्वरित संशयित परतण्याचा मार्ग आहे।