Via hotspot-fajroŝirmilo blokas DHCP antaŭ la luo

Nova telefono aliĝas al via hotspot, montras neniun adreson kaj neniam ricevas unu. La alirpunkto estas en ordo, la DHCP-demonio funkcias, kaj la fajroŝirmila regulo, kiun vi skribis, aspektas kongrua kun la adresplano. Kion ĝi fakte faras, estas postuli, ke la kliento jam havu la adreson, kiun ĝi petas. La unua DHCP-paketo tute ne havas adreson, do la regulo neniam ekagas.

Rigardu klienton aliĝi

Sekvu unu asociiĝon el la flanko de la kliento. La radio asociiĝas, la kliento sendas DHCP-malkovron, la servilo proponas, la kliento petas, la servilo konfirmas, kaj nur tiam la kliento havas adreson uzeblan por io ajn alia.

Ĉio antaŭ tiu fina konfirmo okazas dum la kliento ne povas uzi la enirejon por ordinara trafiko. Tiu estas la fenestro, kiun la subreta regulo forgesas.

Kion la unua paketo fakte enhavas

RFC 2131 difinas, ke DHCP-dissendoj de kliento antaŭ ol ĝi akiras adreson uzas fontadreson nulo. Mesaĝoj de kliento al servilo iras al UDP-pordo 67, kaj mesaĝoj de servilo al kliento al UDP-pordo 68. La malkovro do alvenas kun 0.0.0.0 kiel fonto, kaj regulo postulanta fonton ene de via klienta subreto simple ne kongruas kun ĝi.

Tio ne estas misagordo ĉe la kliento. Tio estas la protokolo funkcianta tiel, kiel ĝi estis desegnita, en la sola fenestro, kie ĝi povas.

Kiu vojo fakte traktas ĝin

Se la alirpunkto mem servas luojn, tio estas loka serva interparolo, kaj en IP-filtrita loka vojo ĝi koncernas enigan kaj eligan politikon. Plusendita klienta trafiko tra la VPN estas alia decido, kaj NAT por tiu trafiko estas denove alia. Konfuzi la tri estas la maniero, kiel mallarĝa escepto fariĝas larĝa.

Kie la paketo estas traktata dependas de la demonio kaj de la fajroŝirmila familio uzata. Krudaj soketaj realigoj, pontaj aranĝoj kaj pli fruaj filtradaj hokoj povas movi aŭ bloki ĝin tute aliloke. Konfirmu la interfacan ligon de la demonio kaj la aktivajn hokojn antaŭ ol aldoni regulojn.

Ĝenerala eniga/eliga recepto kopiita el forumo ne estas pruvo, ke via realigo trairas tiujn ĉenojn same.

La respondo ne ĉiam estas dissendo

Escepto, kiu permesas nur dissendajn respondojn, ankaŭ estas malĝusta. La celo de DHCP-respondo dependas de la stato de la kliento kaj de la kampoj de la mesaĝo, kaj la protokolo specifas kaj dissendan kaj unuadresan kazojn. Se via servilo respondas unuadrese al adreso, kiun ĝi baldaŭ atribuos, regulo nur por dissendo blokas la paŝon, kiu finas la taskon. Skribu la regulon laŭ la interŝanĝo, kiun la agordita servilo fakte plenumas.

Postaj luaj renovigoj ripetas la interŝanĝon en alia stato, do lasu lokon por ili, ne nur por la unua aliĝo.

Riparu mallarĝe, poste kontrolu la reston

Konservu la ekzistantan politikon, trovu la mankan DHCP-permeson kaj limigu ĝin al la interfaco turnita al la kliento, al la protokolo kaj al la du pordoj. Pruvu, ke la peto atingas la servon, poste pruvu, ke la servo respondas. Tiuj estas du malsamaj observoj, kaj serva aŭ grupa agordo ankoraŭ povas esti malĝusta malantaŭ perfekta filtrado.

Malplenigi tabelon ne estas paŝo de DHCP-agordo. En iptables flush forigas regulojn el la elektita ĉeno aŭ tabelo, kaj malplenigi la NAT-tabelon ne kreas tradukan regulon. Starigi larĝajn ACCEPT-politikojn forigas protekton ne ligitan al luado, kaj tial nek unu nek la alia apartenas al reuzebla hotspot-ripareto.

Post kiam la kliento havas luon, kontrolu DNS, plusendadon kaj VPN-eliron kiel apartajn taskojn. Luo starigas lokan adresadon kaj nenion pli.