पहिले VLAN गेटवे, त्यसपछि VPN निकासको निर्णय

पूर्वनिर्धारित गेटवे भएको यन्त्रले निकास नीति कहाँ लागू हुन सक्छ भन्ने निर्धारण गर्छ। दुवै VLAN एकै ट्रान्जिटबाट पठाउनुहोस् र स्रोतअनुसार निकास छान्नुहोस्।

दुई 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 ले त्यो क्षणमा एउटा मार्ग थियो भन्ने मात्र प्रमाणित गर्छ।

सम्बन्धित लेखहरू