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