सामायिक 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. तिन्हींवर अवलंबून असलेला होस्ट ठीक आहे। पहिल्यावर अवलंबून राहून बाकीचे दोन त्याच्याबरोबर आले असे गृहीत धरणारा होस्ट अखेरीस चुकीचा मजकूर देतो।