कसैले 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 पछाडिको प्रयोगकर्ताको वास्तविक ठेगाना पुनःप्राप्त गर्नु, त्यही कारणले असफल हुन्छ: एउटा जडानले एउटा ठेगाना बोक्छ, र सत्रहरूबीचको परिवर्तन धेरै व्याख्यासँग मेल खान्छ। अघिल्लो मानलाई इतिहासका रूपमा लिनुहोस्, सत्यका रूपमा होइन।

सम्बन्धित लेखहरू