क्लाइन्ट भन्छ जोडिएको छ, ताल्चा लागेको छ, अनि पनि एउटा साइट तपाईंको फ्ल्याटको ठेगाना दर्ता गरिरहेको छ। केही पनि असफल भएको छैन। टनेलले तपाईंको 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

टनेलभित्र पहिलो हप साथीको भित्री ठेगाना हो, तपाईंको राउटर होइन। टनेल इन्टरफेसमा गरिएको क्याप्चरले भित्री प्याकेटहरू देखाउँछ, त्यो त्यस्तो ट्राफिक हो जो एप्लिकेसनले पठाइरहेको छु भनी ठान्छ। सोही समयमा भौतिक इन्टरफेसमा क्याप्चर गर्दा बाहिरी प्याकेटहरू देखिन्छन्, र दुवै मिलेर टनेलले वास्तवमा के गर्छ भन्ने सबैभन्दा स्पष्ट प्रदर्शन हो।

तीन ठेगाना, र साइटले एउटा मात्र देख्छ

मानिसहरूले यिनलाई निरन्तर भ्रमित गर्छन्, र त्यो भ्रमले झुटा चुहावट प्रतिवेदन उत्पन्न गर्छ। यी फरक हेडरका फरक फिल्ड हुन्, जसको आयु पनि फरक हुन्छ।

AddressWhere it appearsWho can see it
Endpoint addressOuter header, the peer you connect toYour access network and the path to it
Inner tunnel addressInside the envelope, on the virtual interfaceThe peer, and anything the peer routes to
Exit addressSource of the packet that reaches the websiteThe 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 मा पनि लागू हुन्छ। एकपटक तपाईं भित्री प्याकेट र बाहिरी प्याकेटलाई छुट्टाछुट्टै वस्तुका रूपमा देखाउन सक्नुभयो भने, टनेलको अधिकांश व्यवहार रहस्यमय रहन छोड्छ र तपाईंले पढ्न सक्ने रुटिङ तालिका बन्छ।

सम्बन्धित लेखहरू