VPN टनेल काय आहे आणि संरक्षण कुठे थांबते
टनेल निवडक पॅकेट्सना तुमच्याकडे आधीच असलेल्या लिंकवर दुसऱ्या लिफाफ्यात गुंडाळते। एक विनंती मागोवा घ्या आणि साइट प्रत्यक्षात कोणता पत्ता नोंदवते ते पाहा।
क्लायंट म्हणतो जोडलेला आहे, कुलूप लावलेले आहे, आणि तरीही एक साइट तुमच्या फ्लॅटचा पत्ता नोंदवत आहे। काहीच अयशस्वी झाले नाही। टनेल तुमचे Wi-Fi किंवा मोबाइल लिंक बदलत नाही; ते निवडक पॅकेट्सभोवती दुसरे लिफाफे ठेवते आणि ते लिफाफे तुमच्याकडे आधीच असलेल्या नेटवर्कवर पाठवते। ही युक्ती समजणे म्हणजे मुख्यतः एक विनंती मागोवा घेणे आणि लिफाफा कुठे उघडतो हे लक्षात घेणे, कारण घरच्या पत्त्याची गळती ते मोठ्या डाउनलोडचा अडकणे यापर्यंत जवळजवळ प्रत्येक गोंधळात टाकणारे लक्षण त्या सीमेतूनच येते।
दोन लिफाफे, एक भौतिक लिंक
तुमचा लॅपटॉप राउटरशी त्याचे सामान्य कनेक्शन ठेवतो, आणि राउटर प्रदात्याशी त्याचे सामान्य कनेक्शन ठेवतो। टनेल वर आल्यावर त्या मार्गावर काहीही बदलत नाही। जे बदलते ते म्हणजे निवडक पॅकेट्स व्हर्च्युअल इंटरफेसला दिले जातात, VPN सहकाऱ्याला उद्देशून नवीन पॅकेटमध्ये गुंडाळले जातात, आणि भौतिक लिंकवर सामान्य रहदारी म्हणून पाठवले जातात।
प्राप्त करणारे टोक असे उपकरण आहे जे लिफाफा उघडते आणि मूळ पॅकेट त्याच्या गंतव्याकडे पुढे पाठवते। दोन टोकांमध्ये, निरीक्षक बाहेरील हेडर पाहतो आणि आतील बद्दल काहीही पाहत नाही, जर प्रोटोकॉल ते एन्क्रिप्ट करत नसेल, जे बहुतेक ग्राहक प्रोटोकॉल करतात आणि सामान्य तंत्राची ती मागणी नाही।
म्हणूनच व्हर्च्युअल इंटरफेस एकाच वेळी खरा आणि दिशाभूल करणारा आहे। तो पत्ता आणि कमाल ट्रान्समिशन युनिट असलेली कर्नेल वस्तू म्हणून अस्तित्वात आहे, आणि ऑपरेटिंग सिस्टम इतर कोणत्याही इंटरफेसप्रमाणे त्यात रहदारी पाठवते। तो केबल नाही, आणि त्याचे अस्तित्व फक्त एवढे सिद्ध करते की एक घटक स्थापित आहे। तुमचा ब्राउझर तो वापरतो का हे मार्ग ठरवतात, इंटरफेस सुरू आहे का नाही ते नाही।
एका विनंतीचा प्रवास पाहा
एक गंतव्य निवडा आणि कर्नेलला विचारा की तो कोणता इंटरफेस वापरेल। हा एकच आदेश टनेल काही करत आहे का याबद्दलचे बहुतेक वाद सोडवतो:
ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0जर मार्गाचे आउटपुट टनेल इंटरफेसचे नाव घेते, तर पॅकेट गुंडाळले जाईल। जर ते भौतिक इंटरफेसचे नाव घेते, तर होणार नाही, आणि क्लायंट कितीही वेळा पुन्हा सुरू केला तरी ते बदलणार नाही। दुसरा आदेश दोन्ही इंटरफेस शेजारी दाखवतो, आणि पत्त्याशिवाय किंवा चुकीच्या कुटुंबातील पत्त्यासह वर आलेले टनेल अशाच प्रकारे ओळखता येते।
मग लिफाफ्याच्या आतून पहिला हॉप पाहा, आणि बाहेरील पहिल्या हॉपशी त्याची तुलना करा:
traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5टनेलच्या आत पहिला हॉप सहकाऱ्याचा अंतर्गत पत्ता आहे, तुमचा राउटर नाही। टनेल इंटरफेसवरील कॅप्चर अंतर्गत पॅकेट्स दाखवते, ही अशी रहदारी आहे जी अनुप्रयोग पाठवत असल्याचे मानतो। त्याच वेळी भौतिक इंटरफेसवर कॅप्चर केल्यास बाह्य पॅकेट्स दिसतात, आणि दोन्ही एकत्र मिळून टनेल प्रत्यक्षात काय करते याचे सर्वात स्पष्ट प्रात्यक्षिक ठरते।
तीन पत्ते, आणि साइटला फक्त एकच दिसतो
लोक हे सतत गोंधळात टाकतात, आणि त्या गोंधळातून खोटे गळती अहवाल तयार होतात। ही वेगवेगळ्या हेडरमधील वेगवेगळी फील्ड आहेत, त्यांचे आयुष्यही वेगवेगळे आहे।
| Address | Where it appears | Who can see it |
|---|---|---|
| Endpoint address | Outer header, the peer you connect to | Your access network and the path to it |
| Inner tunnel address | Inside the envelope, on the virtual interface | The peer, and anything the peer routes to |
| Exit address | Source of the packet that reaches the website | The website and its upstream |
व्हर्च्युअल अडॅप्टरच्या बाजूचा क्रमांक दुसरी पंक्ती आहे। तो साइट नोंदवते तो पत्ता नाही, आणि त्याला तुमचा सार्वजनिक IP म्हणून उद्धृत करणे फक्त चूक आहे। साइटला दिसणारा पत्ता एक्झिट ठरवते, आणि खाजगी नेटवर्कच्या टनेलमध्ये सार्वजनिक एक्झिट अजिबात नसू शकतो, कारण गंतव्य इंटरनेटवर नाही, संस्थेच्या आत आहे।
साइट-टू-साइट टनेल वेगळ्या टोकांसह तीच यंत्रणा आहे। दोन राउटर नेटवर्कदरम्यान रहदारी गुंडाळतात, आणि कोणत्याही वैयक्तिक उपकरणात क्लायंट स्थापित नसतो। लिफाफा तत्त्वतः एकसारखा आहे, प्रशासकीय सीमा नाही।
लिफाफा कुठे उघडतो, आणि त्यातून काय टिकते
टनेल त्याच्या सहकाऱ्यावर संपते। जर अनुप्रयोगाचे स्वतःचे एन्क्रिप्शन अधिक दूर जात असेल, तर ते ती सीमा पार करून टिकते, जो HTTPS साठी सामान्य प्रकार आहे: ब्राउझरचे सत्र साइटवर संपते, म्हणून एक्झिट असे सिफरटेक्स्ट पाठवते जे ते वाचू शकत नाही।
दुसरे काहीही डीफॉल्टनुसार टिकत नाही। एन्क्रिप्ट न केलेली विनंती एक्झिटवर तशाच प्रकारे वाचनीय असते जशी ती कॅफेच्या Wi-Fi वर होती, आणि टनेल असे संरक्षण जोडत नाही जे अनुप्रयोगाकडे कधीच नव्हते। त्याचप्रमाणे, एक्झिटचे फायरवॉल नियम आणि फॉरवर्डिंग धोरण पुढे काय होईल ते ठरवतात; यशस्वी हँडशेक सहकाऱ्याशी असलेल्या कनेक्शनबद्दलची वस्तुस्थिती आहे, उर्वरित प्रवासाबद्दल नाही।
ओव्हरहेड हा दुसरा दृश्य परिणाम आहे। प्रत्येक पॅकेट अतिरिक्त हेडर वाहून नेते, आणि बाह्य वाहतूक स्वतःचे जोडू शकते, त्यामुळे प्रति पॅकेट उपयुक्त पेलोड कमी होतो। निश्चित कमाल ट्रान्समिशन युनिट असलेल्या मार्गावर, टनेल पिंग पार करू शकते आणि मोठे अपलोड अडकवू शकते याचे हेच कारण आहे।
अनुप्रयोगाने प्रत्यक्षात घेतलेला मार्ग तपासा
शेवटची पायरी म्हणजे सामान्यपणे यंत्र नाही, तर विशिष्ट अनुप्रयोगाची पुष्टी करणे। गंतव्य सोडवा, त्या पत्त्यासाठीचा मार्ग पाहा, आणि नंतर कनेक्शन उघडे असताना त्याचे निरीक्षण करा:
getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'जर मार्ग टनेलचे नाव घेतो पण सॉकेट यादी भौतिक इंटरफेसच्या स्रोत पत्त्यासह कनेक्शन दाखवते, तर अनुप्रयोग एखाद्या विशिष्ट गोष्टीला बांधलेला आहे, किंवा दुसरे टनेल डीफॉल्ट मार्गासाठी स्पर्धा करत आहे। हा राउटिंगचा प्रश्न आहे, आणि त्याचे उत्तर क्लायंटच्या स्थिती स्क्रीनऐवजी या तीन आउटपुटमधून दिले जाऊ शकते।
RFC 4301 सुरक्षा स्थापत्य IPsec साठी या गुंडाळणीची IP-स्तर आवृत्ती वर्णन करते, आणि तोच स्तर-तर्क WireGuard आणि OpenVPN वरही लागू होतो। एकदा तुम्ही आतील पॅकेट आणि बाहेरील पॅकेट स्वतंत्र वस्तू म्हणून दाखवू शकलात, की टनेलचे बहुतेक वर्तन रहस्यमय राहणे थांबते आणि ते तुम्ही वाचू शकता असे राउटिंग तक्त्यात बदलते।