firewalld श्रोता नियम र फर्वार्डिङ नीति: प्रत्येकले के गर्छ
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 स्रोतले कुन निजी सेवासम्म पुग्न सक्छ भन्ने व्यक्त गर्ने उपयुक्त ठाउँ त्यही हो।
अनुमति दिइएका स्रोतहरू स्पष्ट रूपमा परिभाषित गर्नुहोस् र बाँकी सबै अस्वीकृतिमा पर्न दिनुहोस्। बाह्य सेवाको अनुमति त्यो नीति होइन, जोनको मिलान जस्तो देखिए पनि।
इन्टरफेसमा भरोसा गर्नु किन गलत छोटो बाटो हो
टनेल इन्टरफेसलाई लक्ष्यले सबै स्वीकार गर्ने जोनमा राख्नुले होस्टले खुलाउने हरेक सेवामा सबै डिक्रिप्ट गरिएको ट्राफिक जान दिन्छ, तपाईंले समीक्षा नगरेका सेवाहरू पनि। चलिरहेको मेसिनमा विश्वसनीय जोनलाई सीमित बनाउन पुनः लक्षित गर्नु अझ नराम्रो हो, किनभने अन्य इन्टरफेस र स्रोत दायराहरू पहिले नै यसको अर्थमा निर्भर हुन सक्छन् र तपाईंले सम्पादन गर्दा व्यवहार बदलिनेछ। साँघुरो नीति चाहिए एक बनाउनुहोस्; साझा जोन पुनः प्रयोग नगर्नुहोस्।
टनेलको जोन तोकाइलाई त्यो कन्फिगरेसनको स्वामित्व भएको जुनसुकै कम्पोनेन्टमार्फत स्थिर राख्नुहोस्। पुनः सुरु गर्दा तोकाइ गुम्नुले फायरवाल नियमको समस्या जस्तो देखिने तर वास्तवमा दिगोपनको समस्या भएको असफलता ल्याउँछ।
तीन कुरा प्रमाणित गर्नुहोस्, जसमा एक अस्वीकृति पनि
बाह्य जडान बाहिरबाट परीक्षण गर्नुहोस्, जोडिएको क्लाइन्टबाट एक अधिकृत आन्तरिक सेवा परीक्षण गर्नुहोस्, र अगम्य रहनुपर्ने एक सेवा परीक्षण गर्नुहोस्। तेस्रो परीक्षणले नै नीतिलाई दुष्प्रभावबाट अलग गर्छ, र सबै काम गरिरहेको जस्तो देखिने हुनाले मानिसहरूले त्यही छोड्छन्। अस्वीकृत सेवाले जवाफ दिन्छ भने, तपाईंले सेवा होइन जोनलाई अनुमति दिनुभएको छ।
सर्भरको टिप्पणीमा जोन, पोर्ट, यातायात र नीति वस्तु रेकर्ड गर्नुहोस्। अन्यथा यो होस्टमा अर्को परिवर्तन त्यही अनुमानबाट सुरु हुनेछ।