TunnelCrack विरुद्ध TunnelVision: प्रत्येक प्रत्यक्षात काय तोडतो
TunnelCrack आणि TunnelVision वेगवेगळ्या राउटिंग अपवादांचा गैरवापर करतात: स्थानिक नेटवर्क अपवाद, सर्व्हरचा मार्ग आणि प्रत्येक क्लायंट बिल्डसाठी DHCP पर्याय 121 यांचे पुनरावलोकन करा।
टनेलमधून बाहेर पडणाऱ्या कोणत्याही VPN रहदारीसाठी दोन संशोधन नावे एकमेकांच्या जागी वापरली जातात, पण त्यांच्या मागील यंत्रणा एकसारख्या नाहीत। TunnelCrack राउटिंग अपवादांच्या दोन कुटुंबांचे वर्णन करते; TunnelVision अंतिम उपकरणावर DHCP पुरवतो त्या मार्गाचे वर्णन करते। दोन्हीपैकी कोणीही एन्क्रिप्शन तोडत नाही, आणि कोणीही आज विशिष्ट क्लायंट बिल्ड काय करते हे सांगत नाही। पाच तपासण्या यंत्रणा मथळ्यापासून वेगळ्या करतात।
पहिली पायरी: तुम्ही तपासत असलेल्या यंत्रणेला नाव द्या
ऑगस्ट 2023 मधील TunnelCrack उघडकीस आणणे दोन हल्ला कुटुंबांचे वर्णन करते। स्थानिक नेटवर्कच्या बाबतीत, क्लायंट स्थानिक नेटवर्कचा भाग मानतो ती रहदारी स्थानिक-प्रवेश अपवाद घेते आणि टनेलमधून बाहेर पडते। सर्व्हर पत्त्याच्या बाबतीत, VPN सर्व्हरपर्यंत पोहोचण्यासाठी क्लायंटला आवश्यक असलेला मार्ग टनेलबाहेर असतो, आणि तो पत्ता नियंत्रित करणारा विरोधक या अपवादाचा फायदा घेऊ शकतो।
TunnelVision हा DHCP पुरवतो त्या वर्गहीन स्थिर मार्गांबद्दलचा स्वतंत्र अहवाल आहे। दुर्भावनापूर्ण DHCP सर्व्हर अंतिम उपकरणाला रहदारीचा मार्ग बदलणारे मार्ग देऊ शकतो, त्यात VPN सर्व्हरकडील मार्गही समाविष्ट आहे। अहवाल संबंधित राउटिंग परिणामांवरील पूर्वीच्या कामाची दखल घेतो, जे मूळ यंत्रणा नावापेक्षा जुनी असल्याची आठवण करून देते।
| Case | Exception it abuses |
|---|---|
| TunnelCrack local network | Traffic classified as local bypasses the tunnel |
| TunnelCrack server address | The route to the VPN server sits outside the tunnel |
| TunnelVision | DHCP option 121 installs routes that redirect traffic |
नावे त्यांच्या यंत्रणांशी जोडलेली ठेवा। दुसरे बातम्यांत आहे म्हणून एकासाठी दुरुस्ती लागू करणे हा तो मार्ग आहे ज्याने पुनरावलोकन व्याप्तीशिवाय हालचाल निर्माण करते।
दुसरी पायरी: स्थानिक-प्रवेश अपवाद पहा
बहुतांश क्लायंट टनेल सुरू असताना प्रिंटर, स्क्रीन प्रक्षेपण आणि फाइल शेअरिंग चालू राहावे म्हणून स्थानिक नेटवर्क रहदारीला सूट देतात। तो अपवाद सुरक्षा खर्च असलेला धोरण निर्णय आहे: त्याच नेटवर्कवरील विरोधक स्वतःला स्थानिक होस्ट म्हणून सादर करू शकतो, आणि त्याच्यापर्यंत पोहोचणारी रहदारी कधीही टनेलमध्ये गेली नाही।
तैनात प्रोफाइलला हा अपवाद अजिबात हवा आहे का, विचारा। स्थानिक शोध कधीही न वापरणारे दूरस्थ कार्यबल तो बऱ्याचदा बंद करू शकते, आणि उर्वरित स्थानिक सेवांपर्यंत दस्तऐवजीकृत मार्गाने पोहोचता येते। जिथे अपवाद आवश्यक आहे, तिथे त्याला स्थानिक रहदारी म्हणण्याऐवजी तो कोणत्या गंतव्यांना व्यापतो ते सांगा।
तपासणी हा संरचनेचा प्रश्न आहे, पॅकेट कॅप्चर नाही। तुम्ही तैनात करत असलेल्या बिल्डसाठी प्रोफाइल सेटिंग आणि क्लायंट दस्तऐवज वाचा, कारण डीफॉल्ट उत्पादनांमध्ये आणि एकाच उत्पादनाच्या आवृत्त्यांमध्ये वेगळा असतो। उत्तर प्रोफाइलच्या शेजारी लिहा, जेणेकरून पुढील पुनरावलोककाला ते वर्तनातून काढावे लागणार नाही। कोणीही दस्तऐवजीकृत न केलेला अपवाद हा असा अपवाद आहे ज्याचे कोणीही पुनरावलोकन करत नाही।
तिसरी पायरी: सर्व्हरचा पत्ता कसा शिकला जातो ते पहा
कोणतेही टनेल तयार होण्यापूर्वी क्लायंटला VPN सर्व्हरपर्यंत पोहोचावे लागते, म्हणून ते गंतव्य रचनेनुसार टनेलबाहेर मार्गस्थ केले जाते। पत्ता नावावरून शिकला जात असेल, तर निराकरणाची पायरी विश्वासाच्या मार्गाचा भाग असते, आणि त्या प्रश्नाला उत्तर देऊ शकणारा विरोधक क्लायंटला आपल्या नियंत्रणातील होस्टकडे वळवू शकतो।
पत्ता पिन करणे, योग्य नावासह सत्यापित प्रमाणपत्र वापरणे आणि असत्यापित सर्व्हरवर परत पडण्यास नकार देणे हे सर्व उघडपणा कमी करतात। यापैकी कोणीही टनेलबाहेर सर्व्हरपर्यंत पोहोचण्याची गरज काढून टाकत नाही; ते त्या पत्त्यासाठी कोण उत्तर देऊ शकतो हे बदलतात।
resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule showमार्ग शोध सर्व्हर पत्त्यासाठी क्लायंट वापरेल ते इंटरफेस दाखवतो, हा अपवादाचा ठोस आकार आहे। तो शोध टनेल इंटरफेस परत देत असेल, तर क्लायंट टनेल स्थापितच करू शकत नाही, म्हणून बाहेरील मार्ग अपेक्षित आहे आणि प्रश्न फक्त त्याचे गंतव्य कसे निवडले जाते हा आहे।
चौथी पायरी: DHCP पुरवतो ते मार्ग पहा
वर्गहीन स्थिर मार्ग DHCP सर्व्हरला राउटिंग तक्त्यातील नोंदी वाटून देऊ देतात, आणि अंतिम उपकरण सहसा न विचारता त्या स्वीकारते। ज्या नेटवर्कमध्ये विरोधक कायदेशीर सर्व्हरपेक्षा जलद DHCPला उत्तर देऊ शकतो, तिथे त्या नोंदी वापरकर्त्याला टनेलमध्ये आहे असे वाटणारी रहदारी वळवू शकतात।
अंतिम उपकरणावरील मार्गांची तुम्ही अपेक्षित असलेल्या मार्गांशी तुलना करा। टनेल सुरू असताना स्थानिक गेटवेकडे निर्देश करणारा डीफॉल्ट मार्ग किंवा रुंद उपसर्ग हे तपासण्यायोग्य लक्षण आहे, आणि ते कोणत्याही हल्ला रहदारीशिवाय दिसते।
ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"शेवटची सेटिंग अंतिम उपकरणाच्या बाजूचे नियंत्रण आहे जे अनेक क्लायंट आणि प्लॅटफॉर्म काही ना काही स्वरूपात देतात: नेटवर्क पुरवते ते मार्ग दुर्लक्षित करा। स्वयंचलित मार्ग स्वीकृती बंद करणे ही देवघेव आहे, कारण ते कॉर्पोरेट DHCP सर्व्हरकडून येणारे कायदेशीर विभाजित राउटिंगही बंद करते, म्हणून ते जागतिक नाही तर नेटवर्क वर्गानुसार ठरवा।
पाचवी पायरी: सूचना सध्याच्या बिल्डपासून वेगळी करा
प्रकाशित हल्ला ठराविक वेळी ठराविक क्लायंट आवृत्त्यांवर निरीक्षण केलेल्या वर्तनाचे वर्णन करतो। तो तुमच्यासमोरील लॅपटॉप बाधित आहे हे सिद्ध करत नाही, आणि तो दुरुस्त झाला हेही सिद्ध करत नाही। दोन्ही दाव्यांना प्रत्यक्ष बिल्ड क्रमांक आणि विक्रेत्याची सध्याची सूचना आवश्यक आहे।
क्लायंट आवृत्ती, प्लॅटफॉर्म, वरील अपवाद नियंत्रित करणारी प्रोफाइल सेटिंग आणि तुम्ही तपासलेली तारीख नोंदवा। ती नोंद प्रामाणिकपणे जुनी होते, पण VPN TunnelCrackसाठी पॅच झाली असे म्हणणारी टीप तशी जुनी होत नाही। क्लायंट अद्ययावत होताच ती पुन्हा वाचा, कारण तुम्ही स्पर्श न केलेल्या आवृत्तीखाली प्रोफाइल डीफॉल्ट बदलू शकतो।
तुम्ही प्रत्यक्ष सत्यापन करता तेव्हा मंजूर आराखडा तुमच्या स्वतःच्या अंतिम उपकरणाविरुद्ध आणि निरुपद्रवी गंतव्याविरुद्ध वापरा। सामायिक नेटवर्कवर इतर वापरकर्त्यांविरुद्ध हल्ला पुनरुत्पादित करणे ही चाचणी नाही, आणि निरीक्षण सोपे करण्यासाठी पीअर सत्यापन किंवा अनुप्रयोग एन्क्रिप्शन बंद करणे हे तुम्ही मोजू पाहत असलेले संरक्षण काढून टाकते।
शेवटी, अनुप्रयोग-स्तरीय संरक्षण चित्रात ठेवा। राउटिंग अपवाद टनेल वाहून नेईल अशी रहदारी उघड करू शकतो, आणि अनुप्रयोगाचे TLS ती रहदारी टोकापासून टोकापर्यंत अजूनही संरक्षित करते। दोन्ही स्तर स्वतंत्रपणे अयशस्वी होतात, म्हणून जोडलेला नियंत्रण चॅनेल प्रत्येक प्रवाह इच्छित मार्गाने गेला याचा पुरावा नाही।