VPN वापरकर्त्यांना सबनेटऐवजी एका सेवेचा प्रवेश द्या
अरुंद मार्ग हे अधिकृतता धोरण नाही। अंमलबजावणी कुठे आहे, सेवा कोणता स्रोत पाहते आणि ॲपच्या भूमिका कशा वेगळ्या राहतात हे ठरवा।
एका कंत्राटदाराला एक अंतर्गत वेब ॲप्लिकेशन हवे आणि दुसरे काहीही नाही, आणि सोपे उत्तर म्हणजे त्याला सर्व्हर सबनेटमध्ये एक बोगदा देणे। तो ते स्कॅन करेपर्यंत हे चालते। अरुंद रचनेला अधिक विचार लागतो, कारण पोहोच, मार्गनिर्देशन आणि ॲप्लिकेशन परवानगी या तीन स्वतंत्र नियंत्रणे आहेत ज्यांनी एकमताने राहिले पाहिजे।
आवश्यकता सबनेट म्हणून नाही, सेवा म्हणून लिहा
गंतव्य होस्ट, प्रोटोकॉल आणि पोर्टपासून सुरुवात करा, नंतर तिथे पोहोचायच्या वापरकर्ता किंवा उपकरण गटाचा समावेश करा। खाजगी DNS झोन फक्त ॲप्लिकेशन नाव सोडवत असेल तर समाविष्ट करा, आणि ओळख पुरवठादार फक्त साइन-इन प्रवाहाला आवश्यक असेल तर समाविष्ट करा। बाकी सर्व अशी अवलंबित्व आहे जी तुम्ही अजून समर्थित केलेली नाही।
सबनेट हा नेटवर्क टीमचा अंमलबजावणी तपशील आहे, तर सेवा म्हणजे व्यवसायाने मागितलेली गोष्ट आणि पुनरावलोकन करून बंद करता येणारे एकक।
अवलंबित्वांची यादी तीन बाबींपेक्षा जास्त झाल्यास, ॲप्लिकेशनला स्वतःची रचना चर्चा आवश्यक असण्याची शक्यता आहे।
अरुंद मार्गाने जा, पण अंमलबजावणी दुसरीकडे करा
अरुंद मार्ग किंवा निवडक बोगद्याला कोणते पॅकेट न्यायचे ते सांगतो; हे अधिकृतता धोरण नाही। गेटवे फिल्टर, गंतव्य होस्टचा फायरवॉल आणि ॲप्लिकेशनचे स्वतःचे परवानगी मॉडेल ही प्रवेश ठरवली जाणारी ठिकाणे आहेत। एका पत्त्याला व्यापणारा मार्ग चांगली सुरुवात आहे, आणि तो दृढनिश्चयी वापरकर्त्याला थांबवणारे नियंत्रण नाही। हेच विभाजन तुम्हाला बोगदा पुन्हा रचनाकार न करता फिल्टर बदलू देते।
उलटपक्षी, कठोर फिल्टरसह रुंद मार्ग कायदेशीर असू शकतो, पण संबंधित सर्वांना दोनपैकी कोण अंमलबजावणी करतो हे माहीत असेल तरच।
अंमलबजावणी बिंदू स्पष्टपणे दस्तऐवजीत करा, नाहीतर पुढील बदल तो अपघाताने हलवेल।
सेवा प्रत्यक्षात कोणता स्रोत पाहते ते तपासा
गंतव्य क्लायंटच्या पूलचा पत्ता किंवा गेटवेचा पत्ता पाहते, तुम्ही भाषांतर करता की नाही यावर अवलंबून। होस्टचे फायरवॉल नियम आणि लॉग खऱ्या स्रोताशी जुळले पाहिजेत। अनेक वापरकर्ते भाषांतरित स्रोत सामायिक करत असल्यास, त्या होस्टवरील कोणताही प्रति-वापरकर्ता नियम त्यांना वेगळे करू शकत नाही, आणि ही रचना मर्यादा आहे, बग नाही।
भाषांतर जाणीवपूर्वक निवडा: ते मार्गनिर्देशन सोपे करते आणि स्रोताची ओळख नष्ट करते, जे ऑडिट आणि प्रति-वापरकर्ता नियमांसाठी महत्त्वाचे आहे।
दोनपैकी कोणते निवडले ते त्यावर अवलंबून असलेल्या नियमाच्या शेजारी लिहा।
ॲप्लिकेशन अधिकृतता ऐच्छिक नाही
पोर्टपर्यंत पोहोचल्याने भूमिका मिळत नाही। ॲप्लिकेशनला अजूनही स्वतःचे लॉगिन आणि स्वतःच्या परवानग्या आवश्यक आहेत, कारण नेटवर्क स्तर वापरकर्ता कोणत्या नोंदी संपादित करू शकतो हे व्यक्त करू शकत नाही। अंतर्गत सबनेटमधील प्रत्येक विनंतीवर विश्वास ठेवणारी सेवा अरुंद बोगद्याचे एका तडकाफडकी झालेल्या ओळखपत्रासाठी पूर्ण प्रवेशात रूपांतर करते। बोगदा कोण सॉकेट उघडू शकतो हे ठरवतो, आणि ॲप्लिकेशन त्याच्याशी काय करता येईल हे ठरवते।
इथेच अरुंद रचना दुप्पट फळ देते, कारण कमी पोहोचण्यायोग्य होस्ट म्हणजे ॲप्लिकेशन-स्तरीय चूक दुरुपयोग करता येण्याची कमी ठिकाणे।
नेटवर्क नियम आणि ॲप्लिकेशन भूमिका वेगळ्या प्रणालींमध्ये ठेवा, आणि त्या वेगळ्या बंद करा।
परवानगी दिलेला आणि नाकारलेला दोन्ही मार्ग सिद्ध करा
अधिकृत वापरकर्ता म्हणून जोडा आणि एक निरुपद्रवी प्रातिनिधिक क्रिया करा, नंतर पोहोचू नये अशा गंतव्याचा प्रयत्न करा। फक्त पहिला अर्धा भाग तपासणारी रचना तपासलेली नाही, आणि नकार चाचणीच रचना सिद्ध करते। प्रत्येक नियम बदलानंतर नवीन सत्र तपासा, आणि विनंत्या येत असतील पण उत्तरे नसतील तर परतीचा मार्ग पहा।
स्वीकृती चाचणी उत्तीर्ण व्हावी म्हणून फॉरवर्डिंग फिल्टर बंद करू नका, कारण त्यामुळे तपासली जाणारी गोष्टच बदलते।
वापरकर्त्याला सेवेची गरज नसल्यास, दूरस्थ ओळख आणि ॲप्लिकेशन भूमिका त्यांच्या संबंधित प्रणालींमध्ये बंद करा, आणि दोन्ही नोंदवा। strongSwan फॉरवर्डिंग मार्गदर्शक मार्गाची गेटवे बाजू व्यापते।