सार्वजनिक VPN होस्टनाव काय सिद्ध करू शकते आणि काय करू शकत नाही

होस्टनावे आणि देशांचे झेंडे सर्व्हरबद्दलची तथ्ये वाटतात, आणि त्यापैकी एकही तथ्य नाही। नाव बदलू शकणाऱ्या पत्त्यांकडे निर्देश करते, आणि त्यातील शब्द ज्याने ते नोंदवले त्यानेच निवडले आहेत। प्रोटोकॉल, निर्गमन स्थान आणि लॉगिंग वर्तन यापैकी प्रत्येकाला स्वतःचा पुरावा लागतो। नाव प्रत्यक्षात कशात सोडवले जाते यापासून सुरुवात करा, मग काय अजून अज्ञात आहे ते ठरवा।

नाव सोडवले जाते, आणि बाकी काहीही ठरलेले नाही

होस्टनाव DNS मधील एक निर्देशक आहे, आणि त्यामागील नोंदी रिझॉल्व्हरनुसार, दिवसाच्या वेळेनुसार आणि क्लायंटला आवडणाऱ्या पत्ता-कुटुंबानुसार वेगळ्या असू शकतात। एकाच डिरेक्टरी नोंदी वाचणारे दोन लोक कायदेशीरपणे वेगवेगळ्या मशीनपर्यंत पोहोचू शकतात। नाव काय मागायचे ते सांगते, काय उत्तर देईल ते नाही।

शोधनिकालाही सूचनेशिवाय बदलतात, जे प्रोफाइलने नावाऐवजी पत्ता पिन केल्यावर महत्त्वाचे ठरते। जुना पत्ता हार्डकोड केलेले प्रोफाइल ऑपरेटरने सेवा हलवल्यानंतरही अयशस्वी होत राहते, आणि ते अपयश अडवलेल्या पोर्टसारखे दिसते। सोडवलेले पत्ते प्रोफाइलच्या शेजारी ठेवा जेणेकरून नंतरच्या तुलनेला आधाररेषा मिळेल। यातील काहीही दुसऱ्या टोकाला कोण चालवते हे सांगत नाही।

dig +short vpn.example.net A
dig +short vpn.example.net AAAA
dig +short vpn.example.net A @1.1.1.1

वाहतूक आणि ओळख वेगवेगळे प्रश्न आहेत

होस्टनावावर उघडलेले वेब पान एका पोर्टवर एका श्रोत्याची चाचणी करते। OpenVPN, IPsec आणि SSTP अन्यत्र, स्वतःच्या पोर्ट आणि प्रोटोकॉलवर ऐकतात, म्हणून पोहोचण्यायोग्य वेब सर्व्हर त्यांच्याबद्दल काहीही सांगत नाही।

डिरेक्टरी नोंद आणि प्रोफाइलने वाहतूक, पोर्ट आणि क्रेडेन्शियल्सवर एकमत असणे आवश्यक आहे। ओळख प्रमाणपत्र साखळीने किंवा क्लायंट ज्या समकक्ष किल्लीच्या फिंगरप्रिंटसह संरचित होता त्याद्वारे पडताळली जाते, होस्टच्या शुद्धलेखनाने नाही। ओळखीचा प्रकल्प-शब्द असलेले नाव फक्त एवढेच सिद्ध करते की कोणीतरी ते नोंदवले। सेवा जे प्रमाणपत्र सादर करते ते वाचा आणि जारीकर्ता व विषयाची प्रोफाइल जे अपेक्षित करते त्याशी तुलना करा।

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -dates

देशाचे शब्द स्थानाचे ऑडिट नाहीत

डिरेक्टरीमधील jp किंवा de लेबल ही नोंदणी आहे, आणि IP भू-स्थान डेटाबेस पुरेशा वेळा एकमत नसतात, त्यामुळे त्यातील कोणतेही पूर्ण सत्य मानले जाऊ नये। सामायिक होस्टिंग, anycast आणि साधी चुकीची संरचना हे सर्व निरीक्षित स्थान लेबलापासून दूर नेतात।

व्यावहारिक चाचणी ही अनुप्रयोगाची स्वतःची वाट आहे: तो कोणत्या पत्त्यावर पोहोचतो, आणि सत्राच्या आतून निर्गमन-पत्ता तपासणी काय दाखवते। निरीक्षित निर्गमन पत्ता त्या क्षणीच्या मार्गाचा गुणधर्म आहे, नावाशी जोडलेली हमी नाही। स्वयंसेवक डिरेक्टर्या आणखी एक थर जोडतात, कारण ज्याने सूची नोंदवली तोच मशीन चालवतो असे नाही। तुम्ही काय मोजले आणि कधी ते लिहून ठेवा, सूचीने जे वचन दिले ते नाही।

दिलेली सेवा तपासा, मग ऑपरेटर

वाहतूक आणि ओळख ठरल्यानंतर उरलेला प्रश्न ऑपरेटरचे वर्तन आहे, आणि त्यासाठी अनुमानाऐवजी दस्तऐवजी पुरावा लागतो। गोपनीयता धोरण, प्रकाशित संपर्क आणि पारदर्शकता सूचना हे हेतूचे पुरावे आहेत; त्यातील एकही प्रत्यक्ष आचरण सिद्ध करत नाही, आणि तिन्ही नसणेही माहिती आहे।

सार्वजनिक किंवा स्वयंसेवकांनी चालवलेल्या नोडसाठी, निर्गमन सामायिक आहे आणि ते चालवणारा त्यातून काय जाते ते पाहू शकतो असे गृहीत धरा। होस्टनाव नाही, हेच गृहीतक तुम्ही बोगद्यातून काय पाठवता हे ठरवले पाहिजे।

curl -sSI https://vpn.example.net/ | head -n 5
whois 203.0.113.25 | grep -i -E 'orgname|netname'

नाव ते ज्यात चांगले आहे त्यासाठी ठेवा: टोक शोधणे आणि त्याला जोडणे। त्यापुढील सर्व काही वेगळे तपासले पाहिजे, ज्या दिवशी ते महत्त्वाचे असेल त्या दिवशी।