आपके हॉटस्पॉट का फ़ायरवॉल लीज़ से पहले 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 निकास को अलग-अलग कार्यों के रूप में जाँचें। लीज़ केवल स्थानीय पता-निर्धारण स्थापित करती है, उससे आगे कुछ नहीं।