कॉर्पोरेट फ़ायरवॉल VPN के अंदर क्या देख सकता है और क्या नहीं

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

ब्लॉक करना और पढ़ना अलग शक्तियाँ हैं

इनकार सस्ता और शोरगुल वाला होता है: सॉकेट खुलता है और कोई जवाब नहीं देता, या तुरंत रीसेट आ जाता है। इनमें से कोई भी निरीक्षण नहीं दर्शाता, क्योंकि कोई पेलोड तार के पार नहीं गया।

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

आवरण मुफ़्त में क्या दे देता है

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

होस्टनाम उनमें नहीं है। साइटें दूसरे दरवाज़ों से चूती हैं, और सबसे चौड़ा DNS है: अगर लैपटॉप अब भी स्थानीय रिज़ॉल्वर से पूछता है, तो नाम खुले में दिखते हैं।

समय और मात्रा सम्मान के योग्य हैं, बिना अतिशयोक्ति के। प्रति मिनट बाइट दिखा सकते हैं कि 14:20 पर एक बड़ा स्थानांतरण शुरू होता है; वे नहीं दिखा सकते कि कौन-सी फ़ाइल हिली। यह व्यवहार के बारे में असली खुलासा है, और सामग्री पढ़ने से अलग श्रेणी है।

TLS अवरोधन के लिए ऐसा रूट चाहिए जिस पर आप पहले से भरोसा करें

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

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

VPN चैनल HTTPS सत्र क्यों नहीं है

VPN डेटा चैनल निरीक्षक को ऐसा कोई सहारा नहीं देता। IKEv2 और WireGuard अपने स्वयं के हैंडशेक और कुंजी क्रम चलाते हैं, समाप्त करने के लिए कोई TLS नहीं, जबकि OpenVPN अपने नियंत्रण चैनल के लिए TLS को बदले हुए रूप में उधार लेता है और फिर डेटा को अपने तरीके से सुरक्षित करता है। HTTPS के लिए बना प्रॉक्सी उस सत्र को ऐसी चीज़ के रूप में नहीं पहचानता जिसे वह पार्स कर सके।

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

अपनी मशीन से जाँचें

साइट जो श्रृंखला प्रस्तुत करती है उससे शुरू करें। ब्राउज़र की साइट जानकारी जारीकर्ता दिखाती है, और कमांड लाइन सारांश के बिना वही बताती है:

openssl s_client -connect example.com:443 -servername example.com

फिर काउंटरों से अस्वीकृत हैंडशेक को फ़िल्टर किए गए आंतरिक ट्रैफ़िक से अलग करें। किसी भी ड्रॉप नियम से पहले ट्रांसपोर्ट पोर्ट लॉग करें और प्रयास के बाद उन्हें पढ़ें:

iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbers

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

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