लगातार दुई 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 अंकसहित लेख्नुहोस्, र अर्को व्यक्तिले एउटा प्रश्नको उत्तर दिन पूरै चित्र फेरि कोर्नु पर्ने छैन।