अनेक ॲप कनेक्शन एकच OpenVPN सत्र का सामायिक करतात

एक ब्राउझर HTTPS पृष्ठ लोड करत आहे, एक SSH क्लायंट दुसऱ्या सर्व्हरपर्यंत पोहोचत आहे आणि एक रिझॉल्व्हर प्रश्नाला उत्तर देत आहे — सर्व एकाच OpenVPN सत्रातून। भौतिक इंटरफेसवर तुम्हाला एक संवाद दिसतो; बोगद्याच्या आत तीन दिसतात। दोन्ही दृष्टिकोन बरोबर आहेत, आणि का हे जाणणे म्हणजे उपयुक्त आणि गोंधळात टाकणाऱ्या कॅप्चरमधला फरक। एक आंतरिक प्रवाह सॉकेटपासून तारेपर्यंत पाहा, थरविभाजन अमूर्त राहत नाही।

एक बाह्य संवाद, अनेक आंतरिक प्रवाह

प्रत्येक ॲप्लिकेशन स्वतःचे सॉकेट उघडते, आणि कर्नेल त्याला स्रोत पत्ता, स्रोत पोर्ट, गंतव्य पत्ता, गंतव्य पोर्ट आणि प्रोटोकॉल यांचे पाच-टपल देते। कोणताही बोगदा सहभागी होण्यापूर्वीच ही टपले अस्तित्वात असतात। नंतर राउटिंग ठरवते की ती सर्व बोगदा उपकरणातून बाहेर पडतात, म्हणून OpenVPN ला दिलेले पॅकेट अजूनही आत मूळ हेडर वाहून नेते। OpenVPN ते आंतरिक पॅकेट एन्क्रिप्ट करते आणि निकाल सहकारी सोबत एकाच बाह्य UDP किंवा TCP संवादात गुंडाळते। म्हणून बाह्य संवाद एक आहे, तर त्याच्या आतील प्रवाह ॲप्लिकेशनांनी उघडले तितके आहेत।

काहीही कोसळत नाही। आंतरिक टपले सुरुवातीपासून शेवटपर्यंत टिकून राहतात, आणि म्हणूनच दूरची बाजू अजूनही तीन प्रवाह वेगळे ओळखू शकते।

स्थिर राहणारा पोर्ट

स्थिर राहते ती बाह्य टपल: तुमचा पत्ता, क्लायंटने बांधलेला स्थानिक पोर्ट, सहकाऱ्याचा पत्ता आणि संरचित सेवा पोर्ट। मार्गातील फायरवॉल किंवा NAT ला परवानगी द्यावी लागणारी हीच टपल आहे, आणि अपलिंकवरील कॅप्चर जे दाखवेल तेही हेच। पुन्हा कनेक्ट केल्यावर किंवा नेटवर्क बदलल्यावर बदलणारीही हीच, कारण क्लायंट दुसरा स्थानिक पोर्ट बांधू शकतो। एका बोगद्याचा अर्थ कायम एक स्थिर स्रोत पोर्ट असा नाही।

आंतरिक पोर्ट हेच टोकांना महत्त्वाचे असते। बाह्य वाहतूक ऑपरेटरने संरचित केलेल्या पोर्टवर बसलेली असली तरी HTTPS प्रवाह बोगद्याच्या आत गंतव्य पोर्ट 443 ठेवतो। ॲप्लिकेशनची टोके बाह्य पोर्टबद्दल कधीही जाणत नाहीत।

दूरच्या टोकावर डीकॅप्स्युलेशन काय बदलते

सहकाऱ्याकडे बाह्य थर काढला जातो, आणि उरते ते आंतरिक पॅकेट। तिथून फॉरवर्डिंग आणि प्रवेश धोरण आंतरिक गंतव्य आणि प्रोटोकॉलवर लागू होते। वेब सर्व्हर अजूनही HTTPS कनेक्शन घेतो, SSH डीमन अजूनही SSH घेतो, आणि रिझॉल्व्हर अजूनही प्रश्न घेतो।

म्हणूनच बाह्य वाहतुकीला परवानगी देणारा नियम आंतरिक सेवेला परवानगी देण्याचा नियम नाही। पहिला मार्ग सांगतो; दुसरा अधिकृतता सांगतो।

बाह्य TCP म्हणजे एक प्रवाह, एक कनेक्शन नाही

बाह्य वाहतूक UDP असताना प्रत्येक आंतरिक प्रवाहाचे भवितव्य स्वतंत्र असते: हरवलेला डेटाग्राम त्याच्या स्वतःच्या पुनःप्रेषणापर्यंत एका हस्तांतरणावर परिणाम करतो। बाह्य वाहतूक TCP असताना सर्व आंतरिक प्रवाह एक विश्वासार्ह बाइट प्रवाह सामायिक करतात।

तोच सामायिक प्रवाह लोक चुकवतात। पुनर्प्राप्ती एकदाच होते, सर्वांसाठी, म्हणून एक हरवलेला विभाग आत मल्टिप्लेक्स केलेल्या प्रत्येक ॲप्लिकेशनच्या रहदारीत विलंब करतो। टोकांवर अजूनही अनेक कनेक्शन आणि तारेवर एक कनेक्शन असते, आणि तारेवरच रांगेच्या डोक्याचा परिणाम राहतो। ऐकणाऱ्या पोर्टची संख्या याबद्दल काहीही सांगत नाही, म्हणूनच बोगद्याच्या कार्यक्षमतेबद्दल विचार करण्यासाठी पोर्ट मोजणे हा कमकुवत मार्ग आहे।

तुमची स्वतःची रचना नेमकी सांगा

यंत्र सर्व काही एका पोर्टमधून पाठवते असे म्हणण्याऐवजी, निवडलेली आंतरिक रहदारी आणि ती वाहून नेणारी विशिष्ट बाह्य वाहतूक नावाने सांगा। स्थानिक सेवा, दुसरा बोगदा आणि दुसरे पत्ता कुटुंब असे प्रवाह तयार करतात जे या संवादात कधीही प्रवेश करत नाहीत। अपलिंकवरील कॅप्चर बाह्य टपल दाखवते; बोगद्यातील कॅप्चर आंतरिक टपले दाखवते।

दोन्ही घ्या, आणि वेळेच्या खुणा शेजारी ठेवा। कोणत्या ॲप्लिकेशनने कोणता आंतरिक प्रवाह तयार केला हे सिद्ध करायचे असेल, तर होस्टवरील सॉकेट तक्ता चांगले साधन आहे, कारण तो पोर्ट थेट प्रक्रियांशी जोडतो। मग तुम्ही पाहिलेली बाह्य टपल आणि पाहिलेला क्षण लिहून ठेवा, कारण पुन्हा कनेक्ट केल्यानंतरचे पुढील कॅप्चर कायदेशीरपणे वेगळे आकडे दाखवू शकते।