మీ హాట్స్పాట్ యొక్క ఫైర్వాల్ లీజుకు ముందే 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 నిర్గమనాన్ని వేర్వేరు పనులుగా తనిఖీ చేయండి. లీజు స్థానిక చిరునామా కేటాయింపును స్థాపిస్తుంది, అంతకు మించి ఏమీ లేదు.