वर्चुअल pfSense TAP ब्रिज: तीन जगहें जहाँ फ़्रेम मर सकता है
ब्रिज, उसके सदस्य और वर्चुअल स्विच अलग-अलग निर्णय लेते हैं। ऐसा नियंत्रण बंद करने से पहले पता करें कि किस मालिक ने फ़िल्टर किया जो कभी पथ में ही नहीं था।
आप LAN इंटरफ़ेस पर नियम बंद करते हैं, फ़्रेम फिर भी गायब हो जाता है, और निष्कर्ष यह निकलता है कि pfSense अपने ही फ़ायरवॉल को अनदेखा कर रहा है। आमतौर पर हुआ यह है कि किसी दूसरे मालिक ने निर्णय लिया: ब्रिज खुद, सदस्य इंटरफ़ेस, या गेस्ट के बाहर का वर्चुअल स्विच। हर एक का अपना नियंत्रण और अपना लॉग है।
नीचे दी गई तीन सीमाओं को कोई सेटिंग बदलने से पहले अलग करना उचित है, क्योंकि एक को बंद करना दूसरे की भरपाई नहीं कर सकता।
एक फ़्रेम, तीन नीति-मालिक
TAP क्लाइंट का फ़्रेम टनल डिवाइस से प्रवेश करता है, pfSense ब्रिज पार करता है, LAN सदस्य से बाहर निकलता है, और फिर किसी भी चीज़ तक पहुँचने से पहले वर्चुअल स्विच से गुज़रता है। गेस्ट के अंदर फ़िल्टरिंग ब्रिज पर या सदस्य इंटरफ़ेस पर हो सकती है, और कौन सा सक्रिय है यह स्थिर गुण नहीं बल्कि कॉन्फ़िगरेशन का चुनाव है। गेस्ट के बाहर हाइपरवाइज़र तय करता है कि वह वर्चुअल अडैप्टर ऐसे स्रोत MAC के साथ फ़्रेम भेज सकता है या नहीं जो उसका नहीं है। उनमें से किसी भी बिंदु पर ड्रॉप क्लाइंट की ओर से एक जैसा दिखता है।
जाँच से पहले इच्छित पथ लिख लें: टनल सदस्य, ब्रिज, LAN सदस्य, वर्चुअल स्विच, गंतव्य। फिर पूछें कि उस पथ पर कौन सा मालिक फ़्रेम देख पाता।
कौन सा pfSense नियंत्रण फ़िल्टर कर रहा है
pfSense इसके लिए दो sysctl दस्तावेज़ करता है, एक ब्रिज सदस्यों पर फ़िल्टरिंग के लिए और एक ब्रिज पर ही फ़िल्टरिंग के लिए, और इनमें से कम से कम एक सक्रिय रहना चाहिए। ब्रिज-स्तरीय फ़िल्टरिंग ब्रिज सदस्यों से आने वाले ट्रैफ़िक पर लागू होती है, इसलिए यह दिशा की दृष्टि से आवक है, सममित नहीं। जो इंटरफ़ेस वास्तव में फ़िल्टर कर रहा है उस पर नियम पढ़ें, क्योंकि फ़िल्टर भूमिका के बिना सदस्य पर लिखा नियम कुछ भी नहीं करता। ब्रिज फ़िल्टरिंग का दस्तावेज़ मालिकाना स्पष्ट करता है।
IP पता रहित सदस्य इंटरफ़ेस का अपना पता या सबनेट मैक्रो नहीं होता, इसलिए उस मैक्रो के विरुद्ध लिखा नियम आपके इच्छित LAN के अलावा कुछ और बता सकता है। सुविधा वाले मैक्रो के बजाय जानबूझकर सौंपे गए नेटवर्क ऑब्जेक्ट उपयोग करें।
फ़्रैगमेंट फ़्रेम नहीं है
ईथरनेट फ़्रेम IP पैकेट ले जाते हैं, और एक IP पैकेट बड़े डेटाग्राम का फ़्रैगमेंट हो सकता है, इसलिए दोनों शब्द एक-दूसरे के बदले नहीं हैं। टनल के अंदर एक आंतरिक पैकेट और उसके बाहर एक बाहरी परिवहन पैकेट भी होता है, और विफलता किसी की भी हो सकती है। छोटा ping उस स्टैक से होकर एक पथ जाँचता है और बड़े ट्रांसफ़र के बारे में कुछ साबित नहीं करता। दो निकटवर्ती सीमाओं पर विफल अदला-बदली की तुलना करें और किसी नियम को दोष देने से पहले ड्रॉप का कारण पढ़ें।
यदि फ़्रैगमेंट गायब होते हैं, तो उत्तर सीमित सुधार या पैकेट आकार की जाँच है, फ़िल्टरिंग पूरी तरह बंद करने का निर्णय नहीं।
हाइपरवाइज़र का अपना प्रवेश-निर्णय है
दूसरी मशीनों के लिए ट्रैफ़िक ब्रिज करने वाला गेस्ट ऐसे फ़्रेम भेजता है जिनके स्रोत MAC पते उसके अपने अडैप्टर के नहीं होते, और कई वर्चुअल स्विच पोर्ट समूह अनुमति न दे तो इसे स्पूफ़िंग मानते हैं। उस ट्रांसमिशन की अनुमति देना और अडैप्टर को हर फ़्रेम प्राप्त करने की अनुमति देना अलग नियंत्रण हैं, और दोनों को हर जगह सक्षम करना समस्या की आवश्यकता से कहीं बड़ा बदलाव है। तय करें कि ब्रिज को कौन से फ़्रेम प्राप्त करने हैं और कौन से भेजने हैं, फिर केवल वही व्यवहार उस सीमा पर दें जो उसका मालिक है। दूर से प्रबंधित ब्रिज बदलने से पहले कंसोल पहुँच रखें।
कनेक्टिविटी बहाल करना परीक्षण का आधा है; दूसरा आधा यह पुष्टि करना है कि जो प्रवाह अवरुद्ध रहना चाहिए वह अभी भी अवरुद्ध है।
दर्ज करें कि किस मालिक ने फ़िल्टर किया, कौन सा नियंत्रण बदला और किन दो प्रवाहों को आपने सत्यापित किया। वह रिकॉर्ड अगली घटना को इसी अनुमान से शुरू होने से रोकता है कि pfSense खुद को अनदेखा कर रहा है।