डोमेन फ्रन्टिङ VPN होइन: दुई नाम, एक अनुरोध
एउटा HTTPS अनुरोधमा दुई नाम सुरुङ होइनन्। फ्रन्टिङ प्रदायकको रुटिङ नियममा निर्भर छ; VPN कुन प्याकेट जान्छन् भन्ने छान्छ। तिनलाई छुट्टाछुट्टै कोर्नुहोस्।
यी दुई प्रविधिलाई सँगै राखिन्छ किनभने दुवैमा एक मध्यस्थ हुन्छ र दुवै लुकाएको जस्तो सुनिन्छ। तर तिनीहरू फरक वस्तुमा काम गर्छन्। डोमेन फ्रन्टिङ भनेको एउटा HTTPS अनुरोधको कुन तहमा कुन नाम देखिन्छ भन्ने हो। VPN भनेको कुन प्याकेट कुनै निश्चित बाटो भएर सहकर्मीसम्म जान्छन् भन्ने हो। फ्रन्टिङलाई VPN को एक प्रकार भन्नु नचल्ने डिजाइन र गलत प्रश्न सोध्ने समीक्षातर्फ लैजान्छ।
दुई नाम, दुई तह
TLS जडानले आफ्नो ह्यान्डसेकमा सर्भरको नाम बोक्न सक्छ। जडान बनेपछि, HTTP अनुरोधले आफूलाई चाहिने अधिकार पहिचान गर्छ, सामान्यतया Host हेडरमा। यी दुई क्षेत्र हुन् जुन दुई फरक क्षणमा दुई फरक सफ्टवेयर भागले पढ्छन्।
| Layer | What carries the name | Who reads it |
|---|---|---|
| TLS handshake | Server name indication | The TLS terminator in front of the service |
| HTTP request | Authority or Host header | The routing layer that picks a backend |
| Network path | Destination address and port | Routers, and the VPN peer if one is in use |
डोमेन फ्रन्टिङले पहिलो दुईबीचको फरक प्रयोग गर्छ ताकि फ्रन्टिङ सेवाले जडान स्वीकार गरी अनुरोध अन्तै रुट गर्छ। यो त्यहीँ मात्र चल्छ जहाँ त्यो सेवा यसलाई रुट गर्न तयार हुन्छ, र यो प्रोटोकलको चलाखी नभई प्रदायकको नीतिको प्रश्न हो।
फ्रन्टिङ प्रविधिमा होइन, प्रदायकमा निर्भर छ
सीमित उदाहरणको रूपमा, Front Door सम्बन्धी बारम्बार सोधिने प्रश्न Azure का कागजातले डोमेन फ्रन्टिङविरुद्धका सुरक्षाहरू अभिलेख गर्छन्। त्यसमा एउटै सदस्यता र कन्फिगर गरिएका मार्गभित्रका डोमेनहरूका लागि अनुमति दिइएको बेमेल, र बेमेल सुरक्षाले कुनै अनुरोध रोक्दा 421 Misdirected Request प्रतिक्रियाको वर्णन छ।
त्यो एउटै अभिलेखित नीतिले दुवै नारा एकैचोटि रद्द गर्छ। फरक नामको हरेक जोडी चल्दैन, र हरेक बेमेल प्रतिबन्धित पनि छैन। अन्य सेवाका आफ्नै जाँच, आफ्नै तैनाथी आवश्यकता र आफ्नै त्रुटि कोड छन्।
यो अर्को सञ्जालका प्रतिबन्ध छल्ने निर्देशन पनि होइन। प्रदायकका रुटिङ नियम पढेर उसले के अनुमति दिन्छ भन्ने बुझ्नु वास्तुकलाको काम हो; ती नियमलाई छल्ने विधि मान्नु फरक परिणाम भएको फरक क्रियाकलाप हो। तपाईंले लेख्नुभएको कागजातमा यी दुई क्रियाकलाप छुट्टै राख्नुहोस्। समीक्षामा डिजाइन अस्वीकृत हुनुको कारण दोस्रै हो।
VPN ले वास्तवमा के छान्छ
सञ्जाल VPN मा, रुटिङ र प्लेटफर्म नीतिले सहकर्मीतर्फ जाने सुरुङका लागि आन्तरिक ट्राफिक छान्छन्। व्यवस्थाअनुसार यसले धेरै अनुप्रयोग वा निर्धारित उपसमूह समेट्न सक्छ, र HTTP अनुरोध नै नभएका प्रोटोकल पनि बोक्न सक्छ।
फ्रन्टिङले त्यसमध्ये केही पनि गर्दैन। फ्रन्टिङ सेवामार्फत एउटा HTTPS अनुरोध मिलाउनुले निजी सञ्जाल मार्ग स्थापना गर्दैन, स्वेच्छाचारी UDP अनुप्रयोग बोक्दैन, र यन्त्रको हरेक प्रोग्रामलाई सेवा प्रयोग गर्न बाध्य पार्दैन। तपाईंलाई त्यो कभरेज चाहिन्छ भने प्रोक्सी वा सुरुङ चाहिन्छ, नामको चलाखी होइन।
त्यसैले समीक्षामा दुवै अलमलिन्छन्: दुवैलाई मध्यस्थ भनिन्छ, र दुवै पहुँचसम्बन्धी कागजातमा देखिन्छन्। दुवैले दिने इन्टरफेस पूर्ण रूपमा फरक छ, र तीमध्ये एउटा मात्र सञ्जाल मार्ग हो।
दृश्यता द्विपदीय होइन
तुलना पनि केवल लुकेको बनाम देखिने मात्र होइन। DNS प्रश्न, गन्तव्य ठेगाना, ह्यान्डसेकका विशेषता, प्याकेटको आकार र समय सबै तिनलाई देख्ने स्थितिमा रहेकालाई अवलोकनयोग्य रहन्छन्, र त्यो अवलोकनकर्ताले के सिक्छ भन्ने उनी कहाँ बसेको छ भन्नेमा निर्भर छ।
अनुप्रयोगको डेटा पनि तिनलाई अन्त्य गर्ने अन्त्यबिन्दुमा देखिन्छ। तपाईंको अनुरोध रुट गर्ने फ्रन्टिङ सेवा ती बिन्दुमध्ये एक हो, र VPN सहकर्मी अर्को हो। तपाईंलाई सेवा दिन त्यो पढ्नुपर्ने पक्षका लागि दुवै व्यवस्थाले सामग्री अपारदर्शी बनाउँदैनन्।
तीन बाकस कोर्नुहोस्
वास्तुकला समीक्षाका लागि, TLS अन्त्यबिन्दु, HTTP रुटिङ सेवा र अन्तिम अनुप्रयोगलाई तीन छुट्टै बाकसका रूपमा कोर्नुहोस्, त्यसपछि कुनै पनि VPN सहकर्मीलाई फेरि अन्तै कोर्नुहोस्। वेब गन्तव्य छान्ने ठाउँ र निजी सञ्जालका प्याकेट बोक्ने ठाउँ एउटै प्रणाली हुनैपर्छ भन्ने छैन, र सामान्यतया हुँदैन।
बाकस छुट्टिएपछि प्रश्नको उत्तर दिन सकिन्छ: यो प्रदायकले कुन नाम स्वीकार्छ, कुन प्रोटोकललाई ढुवानी चाहिन्छ, र कुन पक्षले के देख्न सक्छ। तिनलाई जोड्ने रेखाचित्रले कसैले पनि लागू गर्न नसक्ने डिजाइन र शब्दावलीमा झगडा गर्ने समीक्षा जन्माउँछ।