तपाईंको हटस्पटको फायरवालले लिज अघि DHCP लाई रोक्छ

नयाँ फोन तपाईंको हटस्पटमा जोडिन्छ, कुनै ठेगाना देखाउँदैन र कहिल्यै पाउँदैन। पहुँच बिन्दु ठीक छ, DHCP डेमन चलिरहेको छ, र तपाईंले लेख्नुभएको फायरवाल नियम ठेगाना योजनासँग मिल्दो देखिन्छ। तर वास्तवमा यसले क्लाइन्टसँग पहिले नै त्यही ठेगाना हुनुपर्ने माग गर्छ जुन उसले मागिरहेको छ। पहिलो DHCP प्याकेटमा कुनै ठेगाना नै हुँदैन, त्यसैले नियम कहिल्यै लागू हुँदैन।

क्लाइन्ट जोडिने कुरा हेर्नुहोस्

क्लाइन्टको तर्फबाट एउटा सङ्गठन पछ्याउनुहोस्। रेडियो जोडिन्छ, क्लाइन्टले DHCP खोज पठाउँछ, सर्भरले प्रस्ताव दिन्छ, क्लाइन्टले अनुरोध गर्छ, सर्भरले पुष्टि गर्छ, र त्यसपछि मात्र क्लाइन्टसँग अरू केहीका लागि प्रयोगयोग्य ठेगाना हुन्छ।

त्यो अन्तिम पुष्टि अघिको सबै कुरा तब हुन्छ जब क्लाइन्टले सामान्य ट्राफिकका लागि गेटवे प्रयोग गर्न सक्दैन। सबनेट नियमले बिर्सने झ्याल त्यही हो।

पहिलो प्याकेटमा वास्तवमा के हुन्छ

RFC 2131 ले ठेगाना प्राप्त गर्नुअघि क्लाइन्टका DHCP प्रसारणहरू शून्य स्रोत ठेगाना प्रयोग गर्छन् भनी निर्धारित गर्छ। क्लाइन्टबाट सर्भरतर्फका सन्देशहरू UDP पोर्ट 67 मा, र सर्भरबाट क्लाइन्टतर्फका सन्देशहरू UDP पोर्ट 68 मा जान्छन्। त्यसैले खोज 0.0.0.0 स्रोत लिएर आउँछ, र तपाईंको क्लाइन्ट सबनेटभित्र स्रोत माग्ने नियम त्यससँग सजिलै मिल्दैन।

यो क्लाइन्टको तर्फबाट गलत कन्फिगरेसन होइन। यो प्रोटोकल हो, जसरी डिजाइन गरिएको थियो त्यसरी नै काम गरिरहेको छ, त्यो सम्भव हुने एकमात्र झ्यालमा।

वास्तवमा कुन मार्गले यसलाई सम्हाल्छ

यदि पहुँच बिन्दुले आफैं लिज दिन्छ भने यो स्थानीय सेवा कुराकानी हो, र IP ले फिल्टर गरिएको स्थानीय मार्गमा यो इनपुट र आउटपुट नीतिसँग सम्बन्धित छ। VPN मार्फत अगाडि पठाइएको क्लाइन्ट ट्राफिक अर्को निर्णय हो, र त्यो ट्राफिकका लागि NAT फेरि अर्कै हो। यी तीनलाई मिसाउनु नै साँघुरो अपवाद फराकिलो बन्ने बाटो हो।

प्याकेट कहाँ सम्हालिन्छ भन्ने डेमन र प्रयोग गरिएको फायरवाल परिवारमा निर्भर गर्छ। कच्चा सकेट कार्यान्वयन, पुल व्यवस्था र पहिलेका फिल्टर हुकहरूले यसलाई पूर्ण रूपमा अन्तै सार्न वा रोक्न सक्छन्। नियम थप्नुअघि डेमनको इन्टरफेस बाइन्डिङ र सक्रिय हुकहरू पुष्टि गर्नुहोस्।

फोरमबाट प्रतिलिपि गरिएको सामान्य इनपुट/आउटपुट विधि तपाईंको कार्यान्वयनले ती शृङ्खलाहरू त्यही तरिकाले पार गर्छ भन्ने प्रमाण होइन।

जवाफ सधैं प्रसारण हुँदैन

केवल प्रसारण जवाफलाई अनुमति दिने अपवाद पनि गलत हो। DHCP जवाफको गन्तव्य क्लाइन्टको अवस्था र सन्देशका फिल्डहरूमा निर्भर हुन्छ, र प्रोटोकलले प्रसारण र एक-ठेगाना दुवै अवस्था निर्दिष्ट गर्छ। यदि तपाईंको सर्भरले दिन लागेको ठेगानामा एक-ठेगाना जवाफ दिन्छ भने, प्रसारण-मात्र नियमले काम सक्ने चरण रोक्छ। कन्फिगर गरिएको सर्भरले वास्तवमा गर्ने आदानप्रदानअनुसार नियम लेख्नुहोस्।

पछिका लिज नवीकरणहरूले फरक अवस्थामा त्यही आदानप्रदान दोहोर्याउँछन्, त्यसैले पहिलो जोडिनका लागि मात्र होइन, तिनीहरूका लागि पनि ठाउँ छोड्नुहोस्।

साँघुरो रूपमा सुधार्नुहोस्, त्यसपछि बाँकी जाँच्नुहोस्

हालको नीति राख्नुहोस्, छुटेको DHCP अनुमति खोज्नुहोस् र त्यसलाई क्लाइन्टतर्फको इन्टरफेस, प्रोटोकल र दुई पोर्टमा सीमित गर्नुहोस्। अनुरोध सेवासम्म पुग्छ भनी प्रमाणित गर्नुहोस्, त्यसपछि सेवाले जवाफ दिन्छ भनी प्रमाणित गर्नुहोस्। यी दुई फरक अवलोकन हुन्, र पूर्ण फिल्टरिङपछि पनि सेवा वा पूलको कन्फिगरेसन गलत हुन सक्छ।

तालिका फ्ल्यास गर्नु DHCP कन्फिगरेसनको चरण होइन। iptables मा flush ले छानिएको शृङ्खला वा तालिकाबाट नियम मेट्छ, र NAT तालिका फ्ल्यास गर्दा अनुवाद नियम बन्दैन। फराकिलो ACCEPT नीति राख्दा लिजसँग सम्बन्ध नभएको सुरक्षा हट्छ, त्यसैले दुवैमध्ये कुनै पनि पुन: प्रयोगयोग्य हटस्पट सुधारमा पर्दैन।

क्लाइन्टसँग लिज आएपछि DNS, फर्वार्डिङ र VPN निर्गमलाई छुट्टाछुट्टै कामका रूपमा जाँच्नुहोस्। लिजले स्थानीय ठेगाना निर्धारण मात्र स्थापना गर्छ, त्यसभन्दा बढी केही होइन।