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'जुड़ने वाला नकारात्मक मामला एक खोज है, संयोग नहीं, और नियम ठीक होने तक उसका स्थान मैट्रिक्स में विफल कोशिका के रूप में है। परीक्षण कमांड तालिका के पास रखें ताकि अगला समीक्षक तर्क दोबारा बनाने के बजाय उन्हें फिर चलाए।
पूरी हुई तालिका उस गेटवे से अधिक टिकती है जिसके लिए वह लिखी गई थी। नियम फ़र्मवेयर और विक्रेता के साथ बदलते हैं, जबकि वह पंक्ति जो कहती है कि ठेकेदार एक प्रोजेक्ट सेवा तक पहुँचता है, उस काम के बदलने तक सच रहती है।