firewalld श्रोता नियम बनाम फ़ॉरवर्डिंग नीति: प्रत्येक क्या करता है

जो VPN जुड़ता है पर कहीं नहीं पहुँचता, उसे आमतौर पर फ़ायरवॉल की समस्या बताया जाता है, और लोग जो समाधान अपनाते हैं वह टनल इंटरफ़ेस को एक विश्वसनीय ज़ोन में रखना है। यह उस अर्थ में काम करता है कि ट्रैफ़िक बहना शुरू हो जाता है, पर यह इच्छित सेवा से कहीं अधिक की भी अनुमति देता है। यहाँ दो नीतियाँ अलग हैं: एक बाहरी ट्रांसपोर्ट को सुनते हुए सॉकेट तक अनुमति देती है, और दूसरी डिक्रिप्ट किए गए ट्रैफ़िक को किसी विशिष्ट संसाधन तक पहुँचने का अधिकार देती है। इन्हें एक सेटिंग मानना ही संकीर्ण अनुमति को व्यापक बना देता है। दोनों अलग-अलग जगहों पर तय होते हैं, इसलिए यह गलती करना इतना आसान है।

दो नीतियाँ, एक टनल

बाहरी नीति एक सरल प्रश्न का उत्तर देती है: क्या इस स्रोत से आने वाला पैकेट इस होस्ट पर UDP 1194 तक पहुँच सकता है? भीतरी नीति दूसरे प्रश्न का उत्तर देती है: क्या उस टनल के पीछे का प्रमाणित क्लाइंट इस गंतव्य तक, इस प्रोटोकॉल से, इस पोर्ट पर पहुँच सकता है? पहली सॉकेट के बारे में है, दूसरी पथ के बारे में, और firewalld इन्हें अलग-अलग ऑब्जेक्ट से मॉडल करता है क्योंकि ये अलग-अलग बिंदुओं पर तय होते हैं। एक इस होस्ट पर सॉकेट का गुण है, दूसरा उससे गुज़रने वाले पथ का।

व्यावहारिक परिणाम यह है कि काम करता हुआ टनल दूसरी नीति के बारे में कुछ नहीं बताता, और सही दूसरी नीति पहली को अनावश्यक नहीं बनाती।

वास्तविक बाहरी श्रोता को अनुमति दें

मान लेने के बजाय पहले जाँचें कि पहले से क्या आवंटित है। सक्रिय ज़ोन पढ़ें, उस ज़ोन की सूची बनाएँ जो वास्तव में इनग्रेस ले जाता है, और स्थापित सेवा परिभाषा जाँचें, क्योंकि सेवा का नाम पोर्ट के एक समूह का वर्णन करता है और इस बारे में कुछ नहीं कहता कि इस सर्वर का श्रोता उससे मेल खाता है या नहीं।

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

यदि श्रोता वास्तव में उस ज़ोन पर UDP 1194 है, तो ठीक उसी पोर्ट और ट्रांसपोर्ट को खोलें, फिर परीक्षण के बाद उसी विशिष्ट नियम को स्थायी करें। स्रोत-आधारित आवंटन भी जाँचें, क्योंकि किसी स्रोत श्रेणी से बंधा ज़ोन इंटरफ़ेस ज़ोन के देखने से पहले ही ट्रैफ़िक पकड़ सकता है।

डिक्रिप्ट किए गए गंतव्य को अलग से अधिकृत करें

VPN सर्वर पर ही चल रही किसी सेवा से कनेक्शन स्थानीय-इनपुट नीति है। LAN पर किसी अन्य होस्ट को फ़ॉरवर्ड किया गया कनेक्शन फ़ॉरवर्डिंग नीति चाहता है, कर्नेल में सक्षम फ़ॉरवर्डिंग और एक उत्तर पथ — ये तीन अलग-अलग आवश्यकताएँ हैं जिन्हें लोग अक्सर एक में मिला देते हैं। आधुनिक firewalld नीति ऑब्जेक्ट इनग्रेस ज़ोन और एग्रेस ज़ोन के बीच निर्देशित ट्रैफ़िक का वर्णन करते हैं, और यही सही जगह है यह बताने की कि कौन से VPN स्रोत किन निजी सेवाओं तक पहुँच सकते हैं।

अनुमत स्रोतों को स्पष्ट रूप से परिभाषित करें और बाकी सब को अस्वीकृति में गिरने दें। बाहरी सेवा के लिए अनुमति वह नीति नहीं है, चाहे ज़ोन का ढाँचा कैसा भी दिखे।

इंटरफ़ेस पर भरोसा करना गलत शॉर्टकट क्यों है

टनल इंटरफ़ेस को ऐसे ज़ोन में रखना जिसका लक्ष्य सब कुछ स्वीकार करता है, होस्ट द्वारा उजागर हर सेवा तक सारा डिक्रिप्ट किया गया ट्रैफ़िक अनुमत कर देता है, उन सेवाओं सहित जिनकी आपने समीक्षा नहीं की। चालू मशीन पर विश्वसनीय ज़ोन को प्रतिबंधात्मक बनाने के लिए पुनः लक्षित करना और भी बुरा है, क्योंकि अन्य इंटरफ़ेस और स्रोत श्रेणियाँ पहले से उसके अर्थ पर निर्भर हो सकती हैं और संपादित करने पर व्यवहार बदल देंगी। यदि संकीर्ण नीति चाहिए तो एक बनाएँ; साझा ज़ोन का पुनः उपयोग न करें।

टनल का ज़ोन आवंटन भी जो भी घटक उस कॉन्फ़िगरेशन का स्वामी हो, उसके माध्यम से स्थिर रखें। पुनः आरंभ पर आवंटन खोने से ऐसी विफलता होती है जो फ़ायरवॉल नियम की समस्या जैसी दिखती है और वास्तव में दृढ़ता की समस्या है।

तीन चीज़ें सत्यापित करें, जिनमें एक अस्वीकृति भी

बाहरी कनेक्शन को बाहर से परखें, जुड़े हुए क्लाइंट से एक अधिकृत भीतरी सेवा परखें, और ऐसी सेवा परखें जो अगम्य रहनी चाहिए। तीसरा परीक्षण ही नीति को दुष्प्रभाव से अलग करता है, और लोग इसे ही छोड़ देते हैं क्योंकि सब कुछ काम करता दिखता है। यदि अस्वीकृत सेवा उत्तर देती है, तो आपने सेवा नहीं, ज़ोन की अनुमति दी है।

सर्वर के नोट्स में ज़ोन, पोर्ट, ट्रांसपोर्ट और नीति ऑब्जेक्ट दर्ज करें। अन्यथा इस होस्ट पर अगला बदलाव उसी अनुमान से शुरू होगा।