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