VPN एग्ज़िट IP सुरंग का प्रमाण नहीं है: सर्वर क्या देखते हैं

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

सर्वर को प्रति कनेक्शन एक पता दिखता है

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

उस स्रोत पते के बाद सब कुछ एप्लिकेशन डेटा है, और एप्लिकेशन उस पर केवल उतना ही भरोसा कर सकता है जितना वह उसे प्रमाणित करता है।

जाँचें कि आपका एग्ज़िट कैसा दिखता है

नियम लिखने से पहले दोनों सिरों से मार्ग देखें। क्लाइंट का अपने एग्ज़िट के बारे में दृष्टिकोण और सर्वर का कनेक्शन के बारे में दृष्टिकोण ये दो तथ्य हैं जो महत्वपूर्ण हैं।

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

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

दो एग्ज़िट समुच्चयों में से केवल एक को सूचीबद्ध किया जा सकता है

एक मामला अनुरोध के क्षण में जाँचा जा सकता है और दूसरा नहीं, जिससे बहुत अलग गारंटियाँ बनती हैं।

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

प्रकाशित Tor एग्ज़िट सूची प्राप्त और तुलना की जा सकती है, सूची की आयु और हर एग्ज़िट की अपनी नीति के अधीन, इसलिए ज्ञात एग्ज़िट के विरुद्ध अस्वीकृति नियम लागू करने योग्य और समीक्षा योग्य है। वाणिज्यिक VPN के लिए कोई समतुल्य रजिस्ट्री नहीं है। पते बदलते रहते हैं, कई प्रदाता कुछ प्रकाशित नहीं करते, और सुरंग किसी किराए के क्लाउड पते पर चल सकती है जो कभी किसी VPN का नहीं था। आप जो सूची बनाते हैं वह देखे गए पतों का एक स्नैपशॉट है, और उसे होस्टिंग रेंजों तक बढ़ाने से प्रमाण जोड़े बिना असंबंधित कार्यभार जुड़ जाते हैं।

पतों को नीति इनपुट के रूप में उपयोग करें, प्रमाण के रूप में नहीं

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

दर्पण अनुरोध, यानी VPN के पीछे उपयोगकर्ता का असली पता पुनः प्राप्त करना, उसी कारण विफल होता है: एक कनेक्शन एक पता वहन करता है, और सत्रों के बीच परिवर्तन कई व्याख्याओं के अनुरूप है। पिछले मान को इतिहास मानें, सत्य नहीं।