आधी VLAN गेटवे, नंतर VPN एक्झिटचा निर्णय

दोन VLANना वेगवेगळे VPN एक्झिट लागतात, आणि पहिला प्रश्न कोणते धोरण लिहायचे हा नाही तर कोणते उपकरण डीफॉल्ट गेटवेला उत्तर देते हा आहे. जर स्विच VLANमध्ये राउट करत असेल, तर फायरवॉल नियम असा मार्ग वर्णन करू शकतो ज्यातून पॅकेट कधीही जात नाहीत. एक्झिट धोरणाला स्पर्श करण्यापूर्वी टोपोलॉजी चाला.

पहिली पायरी: प्रत्येक VLAN वापरत असलेला गेटवे शोधा

प्रत्येक क्लायंटला त्याचा गेटवे विचारा, आणि स्विचला विचारा की कोणते इंटरफेस VLAN आहे. डीफॉल्ट गेटवे सबनेट सोडणाऱ्या ट्रॅफिकसाठी पहिला राउटिंग निर्णय ठरवतो, म्हणून कोणते उपकरण धोरण लागू करू शकते हेही ठरवतो.

ip route show default
show ip interface brief

दोन सुसंगत लेआउट सामान्य आहेत. एकतर फायरवॉल VLAN इंटरफेस ठेवते आणि त्यांच्यामध्ये राउट करते; किंवा मल्टिलेयर स्विच ते ठेवते आणि स्थानिक पातळीवर राउट करते, फक्त बाह्य गंतव्ये फायरवॉलकडे पाठवते. दोन्ही काम करतात, आणि ते धोरण वेगवेगळ्या ठिकाणी ठेवतात.

जाणूनबुजून एक निवडा, कारण मिश्र लेआउट हाच नियम चुकीच्या उपकरणावर पोहोचण्याचा मार्ग आहे.

दुसरी पायरी: स्थानिक धोरण कुठे राहते ते ठरवा

जर स्विच कर्मचारी आणि लॅबमध्ये राउट करत असेल, तर फायरवॉल नियम अशा देवघेवीची तपासणी करू शकत नाही जी कधीही फायरवॉलपर्यंत पोहोचत नाही. स्थानिक धोरण स्विचच्या स्वतःच्या प्रवेश नियंत्रणांमध्ये राहिले पाहिजे, किंवा ट्रॅफिक जाणूनबुजून तपासणी बिंदूतून वळवले पाहिजे.

उलट्या निवडीचीही किंमत आहे. प्रत्येक VLANसाठी फायरवॉलला गेटवे करणे स्थानिक पातळीवर राउट होणारे ट्रॅफिक त्या उपकरणाच्या क्षमता आणि उपलब्धता योजनेत आणते, त्यामुळे फायरवॉल रीबूट VLANमधील खंड होतो. स्विच स्टेटलेस किंवा फायरवॉल संथ आहेत असे गृहीत धरण्याऐवजी प्रत्यक्ष हार्डवेअरचे मूल्यांकन करा. तुम्ही रीबूट करत असलेले उपकरण दोन व्यस्त सबनेटमधील मार्गही नसेल तेव्हा क्षमता नियोजन सोपे होते.

महत्त्वाचे हे आहे की निवडलेले धोरण पॅकेट प्रत्यक्षात ज्या मार्गाने जातात त्या मार्गावर आहे का.

तिसरी पायरी: दोन्ही उपकरणांना एक ट्रान्झिट द्या

जेव्हा स्विच राउट करतो, तेव्हा एकच ट्रान्झिट सबनेट टोपोलॉजी वाचनीय ठेवते, दोन्ही बॉक्स प्रतिस्पर्धी राउटर म्हणून प्रत्येक क्लायंट VLANवर लटकवण्याऐवजी. स्विच क्लायंट सबनेट ठेवते आणि फायरवॉल बाहेरची बाजू ठेवते.

# on the switch
ip route 0.0.0.0/0 10.255.0.2
# on the firewall
ip route add 10.20.10.0/24 via 10.255.0.1
ip route add 10.20.20.0/24 via 10.255.0.1

स्विच बाह्य गंतव्ये फायरवॉलच्या ट्रान्झिट पत्त्यावर पाठवते, आणि फायरवॉलकडे स्विचमधून दोन्ही क्लायंट प्रीफिक्सपर्यंत परतीचे मार्ग आहेत. स्थलांतरादरम्यान व्यवस्थापन प्रवेश, DHCP गेटवे सेटिंग्ज आणि VLAN सदस्यत्व अभंग ठेवा, कारण ती तीनच स्वच्छ बदल कन्सोल केबलसह दुपारीत बदलतात.

ट्रान्झिट रचना पुढील फायरवॉल बदलीला रीवायरिंग प्रकल्पाऐवजी राउटिंग बदल बनवते.

चौथी पायरी: येणाऱ्या स्रोतावरून एक्झिट निवडा

सामान्य राउटिंग आणि मध्ये स्रोत भाषांतर नसल्यास, फायरवॉलला ट्रान्झिट इंटरफेसवर मूळ कर्मचारी किंवा लॅब पत्ता मिळतो. दोन्ही VLAN एका लिंकवरून येतात, आणि त्यांची IP ओळख ते टिकवते.

त्या स्रोत पत्त्या आणि प्रत्यक्ष इनग्रेस मार्गावरील इच्छित गंतव्यांचा वापर करून VPN निवड व्यक्त करा. OPNsenseचे नियम दस्तऐवज सिस्टम राउटिंगचे अनुसरण करणारी डीफॉल्ट गेटवे सेटिंग आणि धोरण-आधारित राउटिंगला बोलावणारा स्पष्ट गेटवे यात फरक करते. निवड पॅकेट कुठून आले यावर अवलंबून असेल तेव्हा स्पष्ट स्वरूप वापरा. सामान्य डीफॉल्ट मार्गाला स्रोताकडे पाहण्याचे कोणतेही कारण नाही.

स्थानिक गंतव्ये अतिशय रुंद एक्झिट नियमाबाहेर ठेवा, आणि तुम्ही चालवत असलेल्या आवृत्तीसाठी समर्थित गेटवे मॉडेल तपासा.

पाचवी पायरी: दोन्ही मार्ग सिद्ध करा

निकाल दोन वाक्यांत लिहा: मंजूर गंतव्यांकडील कर्मचाऱ्यांचे ट्रॅफिक एक्झिट A मधून बाहेर पडते, आणि मंजूर गंतव्यांकडील लॅबचे ट्रॅफिक एक्झिट B मधून बाहेर पडते. परतीचे मार्ग, भाषांतर नियम आणि एखादा एक्झिट बंद असताना इच्छित वर्तन जोडा.

traceroute -n 198.51.100.10

नंतर स्थानिक आंतर-VLAN सेवा स्वतंत्रपणे तपासा, कारण ती त्याच रचनेत वेगळा निर्णय वापरून पाहते.

प्रत्येक VLANमधून नवीन प्रवाह, कार्यरत स्थानिक सेवा आणि दस्तऐवजीकृत अपयश-मार्ग एकत्रितपणे रचना सिद्ध करतात; एक यशस्वी ping त्या क्षणी एक मार्ग होता एवढेच सिद्ध करते.