सलग दोन VPN हॉप: तुमचा रहदारी खरंच कोण पाहतो?
सीरियल हॉप पहिल्या गेटवेवर डिक्रिप्ट आणि पुन्हा एन्क्रिप्ट करतात; नेस्टेड हॉप फक्त बाहेरील थर काढतात. दोन्ही डिझाइन पाहा आणि कोणता ऑपरेटर काय वाचतो ते जाणून घ्या.
प्रत्येक क्लायंट प्रोफाइल एका सर्व्हरचे नाव देते, म्हणून वापरकर्त्याच्या जागेवरून एक बोगदा आणि संरक्षण संपणारी एक जागा असते। त्या पहिल्या गेटवेनंतर काय होते हा क्लायंटला कधीही न दिसणारा डिझाइन निर्णय आहे, आणि दोन्ही सामान्य डिझाइन तपासणीत खूप वेगळे वागतात। सीरियल साखळीत पहिला गेटवे डिक्रिप्ट करतो आणि पुन्हा एन्क्रिप्ट करतो। नेस्टेड साखळीत तो बाहेरील थर काढतो आणि स्वतः उघडू न शकणारा आतील बोगदा पुढे पाठवतो। हॉपची संख्या दोन्हीत सारखी आहे, म्हणून फरक मोजायचा नाही, काढायचा आहे।
क्लायंटपासून सुरुवात करा आणि दोन्ही टोकांना नाव द्या
वापरकर्ता जिथून सुरुवात करतो तिथून, म्हणजे कनेक्शन प्रोफाइलमध्ये सुरुवात करा। त्यात एक दूरचा पत्ता, एक प्रमाणीकरण पद्धत आणि डिझाइनला आधार असल्यास मार्गांची यादी असते। क्लायंटपासून गेटवे A पर्यंतच्या त्या बाहेरील बोगद्याला नाव द्या आणि उदाहरण पत्ते द्या: क्लायंटचा बोगदा पत्ता 10.77.0.2, A चा 10.77.0.1, आणि A चा सार्वजनिक अंतिम बिंदू 198.51.100.10, TEST-NET-2 दस्तऐवज श्रेणीतून घेतलेला, जेणेकरून उदाहरणातील काहीही खऱ्या होस्टशी टकरू नये।
त्या प्रोफाइलमध्ये गेटवे B चा उल्लेख नाही, आणि तो दोष नाही। दुसरा हॉप A चा आहे, आणि क्लायंटचे एकमेव कर्तव्य म्हणजे रहदारी A पर्यंत पोहोचवणे आणि परत येणारे स्वीकारणे। A बोगदा संपवतो, पुढे पाठवतो की नवीन उघडतो हा प्रश्न या फेरीचा उर्वरित भाग उत्तर देतो, आणि तोच A काय वाचू शकतो हे ठरवतो।
सीरियल: A डिक्रिप्ट करतो, नंतर पुन्हा एन्क्रिप्ट करतो
सीरियल डिझाइनमध्ये A रहदारी दोन वेळा संपवतो। तो क्लायंटकडून संरक्षण काढतो, अनुप्रयोगाचे IP पॅकेट घेतो, आणि नंतर ते पॅकेट A ने B कडे तयार केलेल्या दुसऱ्या बोगद्यातून पाठवतो। या दोन क्रियांमध्ये पॅकेट A च्या पुढे पाठवण्याच्या मार्गात खाजगी गंतव्याकडे पत्ता दिलेले साधे IP पॅकेट म्हणून बसते।
यातून स्पष्ट सांगण्यासारखे दोन परिणाम येतात। A आतील पॅकेटवर धोरण लागू करू शकतो, मार्ग, फिल्टर नियम आणि स्रोत व गंतव्याच्या नोंदीच्या स्वरूपात, आणि A ला दोन संच ओळखपत्रे ठेवावी लागतात: एक क्लायंटसाठी सर्व्हर म्हणून आणि एक B चा क्लायंट म्हणून। प्रत्येक क्षणी संरक्षण असते, तरी संरक्षित वस्तू A कडे ओळख बदलते।
यावरून A अनुप्रयोगाचा स्पष्ट मजकूर वाचतो असे निष्पन्न होत नाही। क्लायंट आणि सेवा TLS चालवतात आणि एकमेकांची प्रमाणपत्रे तपासतात तेव्हा, A वाचनीय विनंतीऐवजी TLS नोंदींचा प्रवाह पाहतो। ते संरक्षण कुठे संपते हे निश्चित करण्यासाठी बोगद्याचे आकृती नव्हे, सेवेची प्रमाणपत्र साखळी पाहावी लागते।
नेस्टेड: A फक्त बाहेरील थर काढतो
नेस्टेड डिझाइनमध्ये क्लायंट प्रथम B कडे आतील बोगदा बांधतो आणि नंतर तो बोगदा बाहेरील बोगद्याच्या आत घेऊन A पर्यंत जातो। A बाहेरील शीर्षक काढतो, आतील बोगदा शोधतो आणि त्याच्या किल्ल्या न ठेवता पुढे पाठवतो, म्हणून आतील संरक्षण अजूनही B वर संपते।
मग क्लायंटची वरची लिंक दोन थर वाहते, तर A आणि B मधला मार्ग एक। A आतील बोगद्याचे बाहेरील पत्ते पाहतो, जे रहदारी आहे आणि अंदाजे कुठे जाते हे जाणून घेण्यासाठी पुरते, आणि पेलोड वाचण्यासाठी पुरत नाही। सीरियल प्रकरणापासूनचा सर्व फरक एवढाच आहे, आणि कोणताही हॉप मोजणी तो दाखवत नाही। A अजूनही जे करू शकतो ते म्हणजे जे वाचू शकत नाही ते पुढे पाठवण्यास नकार देणे, आणि ते त्या गेटवेच्या ऑपरेटरला नेहमी उपलब्ध असते।
नेस्टिंग त्या गुणासाठी किंमत घेते। प्रत्येक थर शीर्षक ओव्हरहेड जोडतो, म्हणून MTU आणि MSS नियोजन नीटनेटके नव्हे तर अनिवार्य होते, आणि एका थराने चालणारा मार्ग दोनसह मोठे पॅकेट गुपचूप सोडू शकतो। प्रत्येक थराला स्वतःचे पुनर्जोडणी आणि जिवंत ठेवण्याचे वर्तन लागते, आणि एका थरातील बिघाड दुसऱ्यातून अर्धवट खंडासारखा दिसतो।
फक्त बोगदे नव्हे, निरीक्षक काढा
बोगदे हे चित्राचे सोपे भाग आहेत। निरीक्षक हा डिझाइनचा विषय आहे, म्हणून प्रत्येक दृष्टिकोनासाठी एक ओळ लिहा आणि प्रत्येकजण खरोखर काय वाचू शकतो ते भरा।
| Vantage point | Serial chain | Nested chain |
|---|---|---|
| Client's access network | Outer tunnel only | Outer tunnel only |
| Operator of A | Inner IP packet between A and B | Outer addresses of the inner tunnel, not its payload |
| Path between A and B | Second tunnel | Second tunnel |
| Operator of B | Inner packet re-originated by A | Payload after the inner layer is removed |
| Service edge | Traffic from the exit address | Traffic from the exit address |
दोन ओळी सतत एकत्र मिसळल्या जातात: A चा ऑपरेटर आणि क्लायंटच्या बोगद्याचा पुरवठादार। ते एकच संस्था असू शकतात, आणि वेगवेगळी गेटवे नावे त्यांना स्वतंत्र करत नाहीत। स्वतंत्र मालकीला वेगळे प्रशासकीय नियंत्रण, वेगळी ओळखपत्रे आणि वेगळी नोंद लागते।
मेटाडेटा दोन्ही डिझाइनांत टिकते। वेळ, पॅकेटचे आकार आणि जोडण्यांची संख्या प्रत्येक हॉपवर निरीक्षणायोग्य राहतात, म्हणून दोन हॉप सिग्नल काढून न टाकता सहसंबंधाची किंमत वाढवतात। अदृश्यता देणारे डिझाइन कोणी त्यावर विसंबण्यापूर्वी त्या यादीशी तपासले पाहिजे।
निवडण्यापूर्वी बिघाडाचे मार्ग चाला
वापरकर्त्याला भेटतील त्या क्रमाने क्लायंटकडून जाणूनबुजून गोष्टी तोडा। इंटरफेस आणि त्याच्या MTU पासून सुरुवात करा, कारण नेस्टिंग प्रमाणीकरणात अपयशी होण्यापूर्वी खूप आधी पॅकेट आकारावर अपयशी होते।
ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1नंतर संरक्षणाची टोके गृहीत धरण्याऐवजी निश्चित करा। जो बोगदा चालू असेल त्याच्या आतून सेवेकडे तिचे प्रमाणपत्र मागा, आणि क्लायंट जी साखळी पाहतो तिची सेवा खरोखर जी साखळी सादर करते तिच्याशी तुलना करा। पुन्हा स्वाक्षरी करणारा किंवा अडवणारा गेटवे ते प्रमाणपत्र बदलतो, आणि तपासणी एका आदेशात दिसू लागते।
openssl s_client -connect intranet.example.com:443 -brief < /dev/nullपुनर्जोडणी मॅट्रिक्सने समारोप करा: क्लायंटचा बोगदा पडतो, B चा बोगदा पडतो, A आणि B मधला मार्ग बदलतो। काय परत येते आणि काय नाही, आणि आतील जोडणी कधीही तिच्या इच्छित वाहकाबाहेरील मार्गावर पडते का ते नोंदवा। प्रत्येक चाचणीने वापरलेले पत्ते नोंदवा, कारण दुसऱ्या प्रवेश जाळ्यावर ती पुन्हा करणे वेगळ्या प्रश्नाचे उत्तर देते। प्रत्येक पुनर्जोडणीनंतर MTU तपासणीही पुन्हा करा, कारण बदललेला मार्ग एकही संरचना ओळ न हलता वापरण्यायोग्य आकार कमी करू शकतो।
A ला आतील पॅकेटवर धोरण लागू करावे लागत असेल, किंवा क्लायंट दोन थरांचे बोगदे चालवू शकत नसेल तेव्हा सीरियल निवडा। आतील पेलोड A कडे वाचनीय राहू नये असेल तेव्हा नेस्टिंग निवडा। निवड तिच्या निरीक्षकांसह आणि MTU आकड्यांसह लिहून ठेवा, आणि पुढच्या व्यक्तीला एका प्रश्नाचे उत्तर देण्यासाठी पूरे चित्र पुन्हा काढावे लागणार नाही।