तुमच्या हॉटस्पॉटचा फायरवॉल लीझपूर्वी 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 निर्गम वेगवेगळी कामे म्हणून तपासा. लीझ केवळ स्थानिक पत्ता-नियुक्ती प्रस्थापित करते, त्यापुढे काही नाही.