साझा TAP VPN को पोर्टल पर HTTPS की आवश्यकता क्यों बनी रहती है
TAP VPN साथी की पुष्टि करता है, उसके पीछे की सेवा की नहीं। पोर्टल पर होस्टनाम सत्यापन रखें और जिन पड़ोसियों पर आप भरोसा नहीं करते उन्हें अलग रखें।
दो उपकरणों के पास मान्य VPN क्रेडेंशियल हैं और वे एक ही ब्रिज किए गए Ethernet सेगमेंट साझा करते हैं। इनमें से केवल एक को कार्यालय पोर्टल के लिए उत्तर देना चाहिए, और दूसरा अभी भी उस सेगमेंट पर पोर्टल का पता दावा कर सकता है। सुरंग ने अपना काम किया: उसने दोनों साथियों की पुष्टि की और सर्वर तक हर मार्ग को एन्क्रिप्ट किया। जो उसने नहीं किया वह यह प्रमाणित करना था कि इनमें से किसके पास सेवा का नाम है, और यही अंतराल वह कारण है कि पोर्टल को अभी भी मान्य प्रमाणपत्र चाहिए।
VPN वास्तव में किसकी पुष्टि करता है
VPN हैंडशेक एक प्रश्न का उत्तर देता है: किस साथी ने इस सुरंग को किस कुंजी सामग्री के साथ पूरा किया। वह उत्तर प्रति साथी और प्रति कनेक्शन है, और वह उन सेवाओं के बारे में कुछ नहीं कहता जो वह साथी बाद में प्रस्तुत करता है। TAP सेगमेंट में साथी एक पता भी नहीं है, क्योंकि वह कोई भी MAC और कोई भी IP प्रस्तुत कर सकता है जिसे ब्रिज सीखने को तैयार हो। प्रमाणीकरण सुरंग के अंतिम बिंदु पर रुकता है, अनुप्रयोग पर नहीं।
तीन प्रश्नों को एक में मिलाने के बजाय अलग करें। प्रत्येक का अपना तंत्र और अपनी विफलता विधि है।
| Question | Answered by |
|---|---|
| Which peer sent this packet? | VPN transport authentication |
| Which device owns this IPv4 address? | ARP, trusted only as far as the segment |
| Which service am I talking to? | Application TLS and hostname validation |
किसी परिनियोजन में पूरी तरह प्रमाणित सुरंग और उसके पीछे पूरी तरह अप्रमाणित सेवा हो सकती है। इसमें ऐसे होस्ट पर सत्यापित प्रमाणपत्र भी हो सकता है जिसका दूसरी परत का पता किसी अन्य साथी द्वारा दावा किया जा रहा है, और इसीलिए दोनों नियंत्रण डिज़ाइन में होने चाहिए, एक-दूसरे की जगह नहीं। तालिका तीन पंक्तियों में पूरा तर्क है।
साझा सेगमेंट पर ARP कोई निर्देशिका नहीं है
ARP स्थानीय लिंक पर एक IPv4 पते को MAC से जोड़ता है और उस लिंक पर किसी से भी उत्तर स्वीकार करता है। अनुमति देने वाले ब्रिज किए गए सेगमेंट पर एक साथी किसी दूसरे उपकरण का पता दावा कर सकता है, और ब्रिज फ्रेम उसी को भेजता है जिसने सबसे हाल में उत्तर दिया। सर्वर तक हर क्लाइंट मार्ग को एन्क्रिप्ट करने से यह नहीं बदलता, क्योंकि फ्रेम ब्रिज तक पहुँचने से पहले डिक्रिप्ट हो जाते हैं। ARP की विश्वास सीमा सेगमेंट है, सुरंग नहीं।
देखें कि होस्ट ने वास्तव में क्या सीखा: ip neigh show वर्तमान मैपिंग और उनकी स्थिति सूचीबद्ध करता है, और सामान्य संचालन के दौरान दो MAC पतों के बीच बदलने वाली प्रविष्टि अनदेखा करने के बजाय जाँच के योग्य लक्षण है। स्वस्थ छोटे सेगमेंट में ऐसी प्रविष्टियाँ लंबे समय तक स्थिर रहती हैं।
साथी अलगाव और ब्रिज नीति ठीक इसी स्थिति के लिए मौजूद हैं। रूट किया गया डिज़ाइन आमतौर पर बेहतर उत्तर है जब सेवा केवल IP हो और उपकरणों के पास एक-दूसरे के फ्रेम देखने का कोई कारण न हो।
प्रमाणपत्र सत्यापन वहीं रखें जहाँ सेवा है
अनुप्रयोग का TLS उस प्रश्न का उत्तर देता है जो सुरंग नहीं दे सकती: क्या यह वही सेवा है जहाँ मैं पहुँचना चाहता था। ब्राउज़र होस्टनाम को प्रमाणपत्र के विरुद्ध जाँचता है, और यही जाँच श्रृंखला का एकमात्र भाग है जो साथी के बजाय पोर्टल का नाम लेता है।
यह तय करने से पहले कि चेतावनी केवल दिखावटी है, देखें कि सर्वर क्या प्रस्तुत करता है। openssl s_client -connect portal.example.internal:443 -servername portal.example.internal श्रृंखला और विषय के वैकल्पिक नाम प्रिंट करता है। यदि आपके द्वारा टाइप किया गया नाम उस सूची में नहीं है, तो चेतावनी सही है और प्रमाणपत्र ही वह चीज़ है जिसे ठीक करना है। उपयोगकर्ताओं को इसे पार करना सिखाना एक काम करने वाले नियंत्रण को सजावट में बदल देता है।
OpenVPN ब्रिजिंग गाइड Ethernet मॉडल और उसके आसपास के नीति विकल्पों का वर्णन करता है, और यह इस बात का सही संदर्भ है कि सेगमेंट को क्या अनुमति देनी चाहिए। ब्रिज नियम ढीला करने से पहले इसे पढ़ें, क्योंकि यह जो मॉडल बताता है वही ऊपर के हर जाँच की धारणा है।
तय करें कि क्या उन साथियों को सेगमेंट साझा करना चाहिए
सबसे सस्ता उपाय आमतौर पर दूसरी परत साझा करना बंद करना है जब आवश्यकता केवल IP पहुँच हो। रूट किया गया VPN हर क्लाइंट को उसका अपना पता देता है, साझा ब्रॉडकास्ट डोमेन हटाता है और साथियों के बीच ट्रैफ़िक को डिफ़ॉल्ट के बजाय नीति निर्णय बनाता है। तब पोर्टल के पास सुरक्षित करने के लिए एक पता होता है और कोई पड़ोसी नहीं जो उस पर दावा कर सके।
यदि सेगमेंट रहना ही है, तो सर्वर-साइड सेटिंग जाँचें जो क्लाइंट को एक-दूसरे तक पहुँचने देती है: grep -n client-to-client /etc/openvpn/server.conf। इसके अक्षम होने पर क्लाइंट ट्रैफ़िक सर्वर से होकर गुजरता है और वहीं फ़िल्टर किया जा सकता है। इसके सक्षम होने पर साथी सीधे ब्रिज से फ्रेम का आदान-प्रदान करते हैं, और आपके फ़िल्टरिंग बिंदु ब्रिज और होस्ट फ़ायरवॉल हैं।
लिख लें कि हर होस्ट वास्तव में किन सुरक्षाओं पर निर्भर है: सुरंग प्रमाणीकरण, सेगमेंट अलगाव या अनुप्रयोग TLS। जो होस्ट तीनों पर निर्भर है वह ठीक है। जो होस्ट पहले पर निर्भर है और मानता है कि बाकी दो उसके साथ आ गए, वही अंततः गलत सामग्री परोसता है।