તમારા હોટસ્પોટનું ફાયરવોલ લીઝ પહેલાં 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 નિકાસને અલગ કાર્યો તરીકે તપાસો. લીઝ ફક્ત સ્થાનિક સરનામાંકન સ્થાપે છે અને તેનાથી આગળ કંઈ નહીં.