साझा 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। तीनवटैमा भर पर्ने होस्ट ठीक छ। पहिलोमा भर पर्ने र बाँकी दुई त्यसैसँग आए भनी मान्ने होस्ट अन्ततः गलत सामग्री दिने हो।