पहले 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 केवल यह साबित करता है कि उस पल एक रास्ता मौजूद था।