साझा VPN खाता: डिवाइस सीमा क्लाइंट अलगाव नहीं है

आठ एक साथ कनेक्शन लाइसेंस पृष्ठ की एक संख्या है, और यह इस बारे में कुछ नहीं कहती कि ये आठ डिवाइस एक-दूसरे के साथ क्या कर सकते हैं। एक साझा लॉगिन प्रति-सत्र कुंजियों के साथ रह सकता है, और ऐसे गेटवे के साथ भी रह सकता है जो एक क्लाइंट का ट्रैफ़िक खुशी से दूसरे की ओर भेज देता है। गलती खाते को सुरक्षा सीमा मानने की है। इसके बजाय चार अलग प्रश्न पूछें: क्या खरीदा गया, टनल की रक्षा क्या करती है, पीयर के बीच क्या जा सकता है, और स्थानीय कड़ी को क्या गिरा सकता है।

कनेक्शन अनुमति वास्तव में क्या वादा करती है

डिवाइस सीमा गिनती है कि प्रदाता एक सदस्यता के लिए कितने सत्र स्वीकार करेगा। यह वाणिज्यिक और परिचालन नियंत्रण है, पहचान या अलगाव के बारे में कोई कथन नहीं। कुछ प्रदाता एक खाते के अंतर्गत हर डिवाइस के लिए अलग प्रमाणपत्र जारी करते हैं; अन्य हर कनेक्शन में एक ही क्रेडेंशियल फिर से उपयोग करते हैं। अंतर रद्द करने के समय दिखता है, क्योंकि अलग क्रेडेंशियल आपको एक डिवाइस काटने देते हैं, जबकि साझा क्रेडेंशियल आपको यह विकल्प नहीं छोड़ता।

कुंजी पृथक्करण के बारे में कुछ मानने से पहले पढ़ें कि प्रदाता क्रेडेंशियल कैसे जारी करता है। खाते का नाम स्वयं इसका कुछ भी उजागर नहीं करता।

जाँचें कि गेटवे क्लाइंट के बीच फ़ॉरवर्ड करता है या नहीं

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

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

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

पीयर से पहले सत्र की रक्षा करें

टनल सुरक्षा और पीयर पहुँच अलग गुण हैं, और मज़बूत साइफ़र अलगाव का अर्थ नहीं है। TLS मोड में हर क्लाइंट अपनी सत्र कुंजियाँ व्युत्पन्न करता है, इसलिए एक क्लाइंट दूसरे का ट्रैफ़िक नहीं पढ़ सकता, भले ही गेटवे उसे भेजे। पुरानी स्थिर-कुंजी व्यवस्था सबके बीच एक ही कुंजी साझा करती है, इसीलिए वहाँ लॉगिन दोबारा उपयोग करने के परिणाम कहीं अधिक बुरे होते हैं। मार्केटिंग पृष्ठ के बजाय कॉन्फ़िगर किया गया मोड जाँचें, फिर आँकें कि खाता साझा करना संबंधित डेटा के अनुकूल है या नहीं।

हर होस्ट पर सेवा प्रमाणीकरण अब भी महत्वपूर्ण है, क्योंकि टनल केवल यह सिद्ध करती है कि कोई क्लाइंट नेटवर्क तक पहुँचा, यह नहीं कि उसे किसी विशेष डेमन तक पहुँचना चाहिए।

स्थानीय Wi-Fi विफलताएँ VPN उल्लंघन नहीं हैं

टूटा हुआ कनेक्शन सिद्ध करता है कि स्थानीय कड़ी विफल हुई, यह नहीं कि किसी ने टनल तोड़ दी। व्यवधान, खोया DHCP पट्टा और रोमिंग हैंडऑफ़—सभी क्रेडेंशियल या साइफ़रटेक्स्ट को छुए बिना सत्र समाप्त करते हैं। डिस्कनेक्शन को उपलब्धता का निष्कर्ष मानें और इसे गोपनीयता तथा पीयर पहुँच के निष्कर्षों से अलग रखें। जहाँ स्थानीय नेटवर्क भरोसेमंद नहीं है, वहाँ केवल टनल पर निर्भर रहने के बजाय ट्रैफ़िक को सिरे से सिरे तक सुरक्षित करें।

चार उत्तर लिख लें: अनुमति, कुंजी मॉडल, पीयर नीति और स्थानीय कड़ी पर निर्भरता। वह अभिलेख साझा खाते की अस्पष्ट चिंता को ठोस नियंत्रणों में बदल देता है।