क्या ZeroTier पर HTTP एन्क्रिप्टेड है? देखें ओवरले कहाँ खत्म होता है
ZeroTier पीयर-टू-पीयर हॉप्स को एन्क्रिप्ट करता है, राउटर या ब्रिज के पीछे के LAN हिस्से को नहीं। सादे HTTP को सुरक्षित कहने से पहले देखें ओवरले कहाँ खत्म होता है।
इन जाँचों को क्रम से करें और पहली विफल जाँच पर रुकें, क्योंकि हर उत्तर अगले कदम का अर्थ बदल देता है। असली सवाल संकीर्ण है: ZeroTier नेटवर्क पर सादा HTTP इंटरनेट पर खुले रूप में जाता है या नहीं। दो ZeroTier पीयर के बीच आम तौर पर नहीं, क्योंकि ओवरले उस हॉप को एन्क्रिप्ट करता है। पर यह दो सिरों के बारे में कथन है, किसी अनुरोध द्वारा पार किए जाने वाले हर खंड के बारे में नहीं। राउटर, ब्रिज या रिवर्स प्रॉक्सी सिरे को हटा देते हैं, और उसके दूसरी ओर सादा पाठ फिर शुरू हो जाता है।
जाँच 1: वह पता खोजें जिसे ब्राउज़र डायल करता है
URL की तुलना उससे करें जो मशीन के पास वास्तव में है। ip -brief addr show zt इंटरफ़ेस और नेटवर्क कंट्रोलर द्वारा दिया गया ओवरले पता सूचीबद्ध करता है; अगर URL उस पते का उपयोग करता है, तो ब्राउज़र का सॉकेट ओवरले में जाता है।
जब नाम इसके बजाय LAN पते पर हल होता है, तो ओवरले शायद बिल्कुल शामिल न हो, चाहे क्लाइंट का स्टेटस संकेतक कुछ भी सुझाए। ip route get 10.147.20.5 इंटरफ़ेस और वह स्रोत पता छापता है जो कर्नेल चुनता, इसलिए वहाँ zt इंटरफ़ेस का मतलब है कि पैकेट ओवरले में जाता है और आपके भौतिक NIC के नाम का मतलब है कि नहीं जाता। नाम एक और परत जोड़ते हैं: ओवरले पते की ओर इशारा करने वाला रिकॉर्ड LAN पते की ओर इशारा करने वाले से अलग व्यवहार करता है, और खोज सफ़िक्स या hosts फ़ाइल की प्रविष्टि चुपचाप तय कर सकती है कि आपको कौन सा मिलेगा।
जाँच 2: पुष्टि करें कि दोनों सिरे पीयर हैं, डिक्रिप्ट करने वाला रिले नहीं
ZeroTier पीयर के बीच एन्क्रिप्ट करता है, और जहाँ सीधा रास्ता नहीं है वहाँ पैकेट एक रूट से गुज़रते हैं जो उन्हें अभी भी एन्क्रिप्टेड आगे भेजता है। zerotier-cli peers हर पीयर के रास्ते को विलंब संख्या के साथ DIRECT या RELAY के रूप में चिह्नित करता है। रिले किया गया रास्ता चक्कर लगाता है, गोपनीयता नहीं।
जवाब वास्तव में वह सदस्य बदलता है जो असली सिरा नहीं है। जब दूसरी ओर ZeroTier सदस्य हो जो किसी भौतिक LAN में रूट या ब्रिज करता है, तो ओवरले उस सदस्य पर खत्म होता है और अगली हॉप साधारण ईथरनेट है।
जाँच 3: देखें कि अनुरोध कहाँ पढ़ने योग्य होता है
जिस होस्ट को आप पेज परोसने वाला मानते हैं, उस पर रीलोड करते समय ओवरले इंटरफ़ेस कैप्चर करें: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'। उस आउटपुट में पढ़ने योग्य अनुरोध पंक्ति साबित करती है कि ट्रैफ़िक उस होस्ट पर डिक्रिप्ट होकर पहुँचा, और यही वह सीमा है जिसे आप खोज रहे हैं।
फिर बाकी LAN की ओर देखने वाले इंटरफ़ेस पर कैप्चर करें। अगर वही अनुरोध वहाँ खुले रूप में दिखता है, तो उसने एप्लिकेशन तक पहुँचने से पहले ओवरले छोड़ दिया और उस खंड का हर उपकरण उसे पढ़ सकता है। अगर LAN की ओर कुछ नहीं दिखता और पेज फिर भी लोड होता है, तो एप्लिकेशन ZeroTier होस्ट पर ही समाप्त होता है।
सामने रिवर्स प्रॉक्सी होने पर लूपबैक कैप्चर करना भी मायने रखता है, क्योंकि HTTPS स्वीकार कर HTTP आगे भेजने वाला प्रॉक्सी सीमा को अपने बैकएंड पर ले जाता है।
जाँच 4: राउटर या ब्रिज के पीछे की हर हॉप का हिसाब रखें
ओवरले और LAN के बीच रूट करने के लिए कॉन्फ़िगर किया गया सदस्य सामान्य डिज़ाइन है और यही वह जगह है जहाँ इनमें से ज़्यादातर धारणाएँ टूटती हैं। ओवरले ब्राउज़र से राउटर तक का हिस्सा बचाता है और उसके बाद कुछ नहीं। ब्रिज वही कहानी दूसरी व्यवस्था से कहता है: ओवरले और भौतिक खंड एक ही ब्रॉडकास्ट डोमेन बन जाते हैं, इसलिए ब्रिज किए गए लैपटॉप से आया अनुरोध साधारण ईथरनेट पार करता है, चाहे वह लैपटॉप ZeroTier नेटवर्क पर हो।
मानने के बजाय इसे ट्रेस करें। क्लाइंट से सेवा पते तक traceroute और गेटवे सदस्य पर रूटिंग तालिका दिखाते हैं कि आखिरी हॉप zt है या eth।
ZeroTier विश्वसनीय-पथ मोड भी देता है जो प्रदर्शन के लिए निर्दिष्ट स्थानीय पथों पर ट्रांसपोर्ट सुरक्षा छोड़ सकता है। इसका उपयोग करने वाला नेटवर्क सामान्य एन्क्रिप्टेड-पथ धारणा विरासत में नहीं पाता, इसलिए किसी को उद्धृत करने से पहले नेटवर्क कॉन्फ़िगरेशन पढ़ें। प्रोटोकॉल दस्तावेज़ पीयर एन्क्रिप्शन और उस अपवाद दोनों का वर्णन करते हैं।
जाँच 5: तय करें कि एप्लिकेशन को अभी और क्या करना है
ओवरले सदस्यता किसी उपकरण को नेटवर्क के प्रति प्रमाणित करती है और इस बारे में कुछ नहीं कहती कि दूसरी ओर की सेवा वही है जिस तक आप पहुँचना चाहते थे। HTTPS दूसरे सवाल का जवाब होस्टनाम को कुंजी से बाँधकर देता है, इसलिए दोनों सुरक्षाएँ एक-दूसरे को बदले बिना ओवरलैप करती हैं। अधिकृत पीयर फिर भी गलत सेवा हो सकता है, और समझौता किया गया सिरा अनुरोध को एन्क्रिप्शन से पहले और डिक्रिप्शन के बाद दोनों समय पढ़ता है। दोनों में से कोई भी तंत्र ऑडिट नहीं करता कि एप्लिकेशन क्या दर्ज करता है।
फिर से उपयोग होने वाले सत्र या पासवर्ड वाली किसी भी चीज़ के लिए एप्लिकेशन में या आपके नियंत्रण वाले प्रॉक्सी में TLS समाप्त करें और प्रमाणपत्र सत्यापन चालू रखें। जहाँ पुरानी सेवा को सादे HTTP पर ही रहना है, वहाँ वह जो सटीक होस्ट-से-होस्ट पथ उपयोग कर सकती है, कौन उस तक पहुँच सकता है और कौन सा खंड असुरक्षित रहता है, लिखें; भावी समीक्षक को वही टिप्पणी चाहिए।
"VPN जुड़ा है" इनमें से किसी का आकलन नहीं है। ईमानदार संस्करण दोनों सिरे, उनके बीच का पथ और पहली बिना ढकी हॉप का नाम लेता है।
कैप्चर आउटपुट और पीयर सूची को सेवा दस्तावेज़ के पास रखें, ताकि जो कोई रास्ता बदले या ब्रिज जोड़े वह देख सके कि कौन सी धारणा तोड़ने वाला है।