Mae firewall eich hotspot yn blocio DHCP cyn y les

Mae ffôn newydd yn ymuno â’ch hotspot, yn dangos dim cyfeiriad ac yn byth yn cael un. Mae’r pwynt mynediad yn iawn, mae’r daemon DHCP yn rhedeg, ac mae’r rheol firewall a ysgrifennwyd gennych yn edrych yn gyson â’r cynllun cyfeiriadau. Yr hyn y mae’n ei wneud mewn gwirionedd yw mynnu bod y cleient eisoes yn dal y cyfeiriad y mae’n gofyn amdano. Nid oes gan y pecyn DHCP cyntaf unrhyw gyfeiriad o gwbl, felly ni fydd y rheol byth yn tanio.

Gwyliwch glient yn ymuno

Dilynwch un cysylltiad o ochr y cleient. Mae’r radio yn cysylltu, mae’r cleient yn anfon darganfyddiad DHCP, mae’r gweinydd yn cynnig, mae’r cleient yn gofyn, mae’r gweinydd yn cydnabod, a dim ond wedyn y mae gan y cleient gyfeiriad y gellir ei ddefnyddio ar gyfer unrhyw beth arall.

Mae popeth cyn y cydnabyddiad terfynol hwnnw yn digwydd tra na all y cleient ddefnyddio’r porth ar gyfer traffig cyffredin. Dyna’r ffenestr y mae’r rheol is-rwydwaith yn ei hanghofio.

Beth sydd mewn gwirionedd yn y pecyn cyntaf

Mae RFC 2131 yn nodi bod darllediadau DHCP cleient cyn iddo gael cyfeiriad yn defnyddio cyfeiriad ffynhonnell sero. Mae negeseuon cleient-i-weinydd yn mynd i borth UDP 67, a negeseuon gweinydd-i-gleient yn mynd i borth UDP 68. Felly daw’r darganfyddiad gyda 0.0.0.0 fel ei ffynhonnell, ac nid yw rheol sy’n mynnu ffynhonnell o fewn eich is-rwydwaith cleient yn cyfateb iddo o gwbl.

Nid camgyflunio ar ran y cleient yw hyn. Y protocol yn gweithio fel y’i cynlluniwyd yw hyn, yn yr unig ffenestr lle y gall.

Pa lwybr sy’n ei drin mewn gwirionedd

Os y pwynt mynediad ei hun sy’n gwasanaethu lesau, mae hwn yn sgwrs gwasanaeth lleol, ac mewn llwybr lleol a hidlir gan IP mae’n ymwneud â pholisi mewnbwn ac allbwn. Mae traffig cleient a anfonir ymlaen drwy’r VPN yn benderfyniad gwahanol, ac mae NAT ar gyfer y traffig hwnnw’n wahanol eto. Cymysgu’r tri yw sut y mae eithriad cul yn dod yn un eang.

Mae lle y caiff y pecyn ei drin yn dibynnu ar y daemon a’r teulu firewall a ddefnyddir. Gall gweithrediadau soced crai, trefniadau pont a bachau hidlo cynharach ei symud neu ei rwystro yn hollol ryfedd. Cadarnhewch rwymiad rhyngwyneb y daemon a’r bachau sydd ar waith cyn ychwanegu rheolau.

Nid yw rysáit fewnbwn/allbwn gyffredin a gopïwyd o fforwm yn dystiolaeth bod eich gweithrediad yn tramwyo’r cadwyni hynny yr un ffordd.

Nid yw’r ateb bob amser yn ddarllediad

Mae eithriad sy’n caniatáu atebion darlledu yn unig hefyd yn anghywir. Mae cyrchfan ateb DHCP yn dibynnu ar gyflwr y cleient a meysydd y neges, ac mae’r protocol yn nodi’r ddau achos, darlledu ac uncast. Os yw eich gweinydd yn ateb yn uncast i gyfeiriad y mae ar fin ei neilltuo, mae rheol darlledu yn unig yn blocio’r cam sy’n gorffen y gwaith. Ysgrifennwch y rheol yn erbyn y gyfnewidfa y mae’r gweinydd cyfluniedig yn ei chyflawni mewn gwirionedd.

Mae adnewyddiadau les diweddarach yn ailadrodd y gyfnewidfa mewn cyflwr gwahanol, felly gadewch le iddynt, nid yn unig ar gyfer yr ymuniad cyntaf.

Trwsiwch yn gul, yna gwiriwch y gweddill

Cadwch y polisi presennol, darganfyddwch y caniatâd DHCP coll, a’i gwmpasu i’r rhyngwyneb sy’n wynebu’r cleient, y protocol a’r ddau borth. Profwch fod y cais yn cyrraedd y gwasanaeth, yna profwch fod y gwasanaeth yn ateb. Mae’r rhain yn ddau arsylwad gwahanol, a gall cyfluniad gwasanaeth neu gronfa fod yn anghywir o hyd y tu ôl i hidlo perffaith.

Nid yw fflysio tabl yn gam cyfluniad DHCP. Yn iptables, mae flush yn dileu rheolau o’r gadwyn neu’r tabl a ddewiswyd, ac nid yw fflysio’r tabl NAT yn creu rheol cyfieithu. Mae gosod polisïau ACCEPT eang yn dileu amddiffyniad nad yw’n gysylltiedig â lesio, a dyna pam nad yw’r naill na’r llall yn perthyn mewn trwsio hotspot ailddefnyddiadwy.

Unwaith y bydd y cleient yn dal les, gwiriwch DNS, anfon ymlaen ac allanfa VPN fel tasgau ar wahân. Mae les yn sefydlu cyfeirio lleol a dim byd y tu hwnt i hynny.