ستاسو د هټسپاټ فایر وال د اجارې مخکې DHCP بندوي
د پیرودونکي فرعي شبکه قاعده هیڅکله د DHCP لومړنۍ غوښتنې سره سمون نه خوري، ځکه هغه غوښتنه له 0.0.0.0 څخه راځي. پرځای یې محلي لاره اجازه کړئ.
نوی تلیفون ستاسو هټسپاټ ته ورګډیږي، هېڅ پته نه ښیې او هیڅکله نه ترلاسه کوي. د لاسرسي نقطه سمه ده، 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 وتل د جلا دندو په توګه وګورئ. اجاره یوازې محلي پته ورکونه ټاکي او نه څه نور.