VPN देखि VLAN पहुँच: नियमभन्दा पहिले म्याट्रिक्स बनाउनुहोस्
एकातर्फ भूमिकाहरू, अर्कोतर्फ सेवाहरू। पाँच जाँचले अस्पष्ट VPN-देखि-VLAN पहुँच डिजाइनलाई फायरवाल मालिकले लागू गर्न सक्ने तालिकामा बदल्छन्।
फायरवाल सिन्ट्याक्सबाट होइन, म्याट्रिक्सबाट सुरु गर्नुहोस्। एकातर्फ भूमिका र अर्कोतर्फ सेवा भएको तालिका अनुप्रयोग मालिकले समीक्षा गर्न सक्छ, सुरक्षा मालिकले छलफल गर्न सक्छ र गेटवे जसको हातमा छ उसले लागू गर्न सक्छ। कसैले नमानेका नियमहरू डिबग गर्नुभन्दा त्यो समीक्षा सस्तो हुन्छ।
त्यो लेख्न एक घण्टा लगाउँदा पछि एक हप्ताको नियम-पुरातत्व बचत हुन्छ। डिजाइनले को कुन सेवासम्म पुग्छ भन्ने कुरा गर्छ, र पुनःक्रमांकनपछि टिक्ने भाग त्यही हो।
चरण 1: नेटवर्कभन्दा पहिले भूमिकाको नाम राख्नुहोस्
स्विचबाट होइन, मानिसबाट सुरु गर्नुहोस्। टाढाबाट जोडिने प्रत्येक समूह र त्यो समूहले के गर्छ भन्ने एक वाक्य लेख्नुहोस्, जस्तै स्टक स्तर पढ्ने गोदाम कर्मचारी वा एउटा एकीकरण हेर्ने ठेकेदार। यदि दुई समूहले एउटै पहुँच पाउने भए, यो उद्देश्यका लागि ती एउटै भूमिका हुन्।
भूमिका संगठनात्मक चार्टकै कारण मात्र छ भने यहीँ रोक्नुहोस्। आफ्नै छुट्टै सेवा-आवश्यकता नभएको भूमिका एउटै किसिमका कोषहरूको पङ्क्ति बन्छ, र एउटै किसिमका पङ्क्तिले पछि सुविधाका लागि पूरै सबनेट दिन कसैलाई प्रेरित गर्छ। मानिसहरूले के गर्छन् त्यसका आधारमा विभाजन गर्नुहोस्, उनीहरूको खर्चमा कसले हस्ताक्षर गर्छ त्यसका आधारमा होइन। सानो कार्यालयका लागि छ भूमिका सामान्यतया धेरै हुन्छन् र तीन प्रायः ठीक हुन्छन्।
चरण 2: प्रत्येक कोषलाई सेवा-कथन बनाउनुहोस्
«अनुप्रयोग» लेखिएको कोष जाँच्न सकिँदैन। «कर्मचारी पूलबाट 443 मा ERP होस्टमा HTTPS» लेखिएको कोष जाँच्न सकिन्छ। प्रत्येक नेटवर्क नामलाई गन्तव्य, प्रोटोकल र पोर्टले बदल्नुहोस्, त्यसपछि सेवा जसबिना चल्दैन त्यो निर्भरता थप्नुहोस्, जस्तै आन्तरिक रिजोल्भर वा पहिचान प्रदायक।
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
दिशा स्तम्भले सबैभन्दा महँगा गल्ती समात्छ। कर्मचारीलाई अनुप्रयोग खोल्ने अनुमतिको अर्थ अनुप्रयोग सर्भरहरूले कर्मचारीका ल्यापटपतर्फ फर्केर जडान खोल्न सक्ने अनुमति होइन, र पहिलो दिशा अनुमति दिने अवस्थायुक्त नियम प्रायः दोस्रोलाई पनि अनुमति दिने रूपमा पढिन्छ।
चरण 3: पहिचान कहाँ नीति बन्छ त्यो निर्णय गर्नुहोस्
कसैले प्रमाणित सत्रलाई गेटवेले लागू गर्न सक्ने भूमिकामा बदल्नुपर्छ। समर्थित विकल्पहरूमा प्रमाणीकरण ब्याकएन्डले दिने समूह नीति, विश्वसनीय सत्र विशेषताहरू, वा प्रत्येक भूमिकाका लागि छुट्टै ठेगाना पूल समावेश छन्। तीनवटै काम गर्छन्; क्लाइन्टले पठाउने लेबल काम गर्दैन। फोरम पोस्टले वर्णन गर्ने होइन, तपाईंको गेटवेले कागजात गर्ने विधि छान्नुहोस्।
VLANकै देखिने मात्र ठेगाना दिनु अर्को पोशाकमा त्यही उत्तर-नहुनु हो। OpenVPN फायरवाल नियमबारे Netgate मार्गदर्शिका ले यो विभाजन स्पष्ट पार्छ: सुरुङ उठ्न दिनु भनेको त्यसबाट ट्राफिक जान दिनुभन्दा फरक निर्णय हो।
तपाईंले कुन विधि छान्नुभयो र त्यो कहाँ कन्फिगर छ लेख्नुहोस्। भूमिका बदलिँदा त्यो टिप्पणी एउटा सम्पादन र तीन इन्टरफेसमा खोजीबीचको फरक हो। यसले लेखापरीक्षकलाई पहिले कहाँ हेर्ने भनेर पनि बताउँछ।
चरण 4: गन्तव्यले देख्ने स्रोत ठेगानामा ध्यान दिनुहोस्
सीमामा फर्वार्डिङ नीति वास्तविक स्रोतसँग मिल्नुपर्छ। गेटवेले VPN क्लाइन्टहरूलाई आफ्नै ठेगानामा अनुवाद गर्छ भने, तलको प्रत्येक फायरवालले एउटै स्रोत देख्छ र भूमिकाअनुसार निर्णय गर्ने क्षमता गुमाउँछ। यदि क्लाइन्टको ठेगाना जोगाउँछ भने, त्यो पूलका लागि फर्कने बाटो हुनुपर्छ।
अन्तिम नियम लेख्नुअघि दुवै दिशा जाँच्नुहोस्, त्यसपछि प्रत्येक कोषको छेउमा अवलोकित स्रोत लेख्नुहोस्। त्यही जाँच दुई फरक भूमिकाबाट चलाएर नतिजा तुलना गर्नुहोस्। दुवैले गेटवेको ठेगाना देखाए भने भूमिकाको भेद पहिले नै गुमिसकेको छ। गेटवेले स्रोत-अनुवाद गरिरहँदा जोगाइएका ठेगाना मान्ने म्याट्रिक्स पहिलो तल्लो ACLमा असफल हुन्छ।
चरण 5: जारी गर्नुअघि प्रत्येक कोष जाँच्नुहोस्
अनुमति दिइएको प्रत्येक कोषलाई एउटा प्रतिनिधि कार्यमा र अस्वीकृत प्रत्येक कोषलाई नकारात्मक घटनामा बदल्नुहोस्। दुवैलाई वास्तविक भूमिकाको क्लाइन्टबाट चलाउनुहोस्, गेटवे कन्सोलबाट होइन, किनकि कन्सोलले तपाईंले जाँचिरहेको बाटो छल्छ।
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'जोडिने नकारात्मक घटना एउटा खोज हो, संयोग होइन, र नियम सुधार्नुअघि त्यसको स्थान म्याट्रिक्समा असफल कोष हो। परीक्षण आदेश तालिकाको छेउमा राख्नुहोस्, अर्को समीक्षकले तर्क फेरि नबनाई ती फेरि चलाउन्।
पूरा भएको तालिका जुन गेटवेका लागि लेखियो त्यसभन्दा लामो समय टिक्छ। नियम फर्मवेयर र विक्रेतासँग बदलिन्छन्, तर ठेकेदार एउटा परियोजना सेवासम्म पुग्छ भन्ने पङ्क्ति त्यो काम नबदलुन्जेल साँचो रहन्छ।