Jūsų hotspot ugniasienė blokuoja DHCP prieš nuomą

Naujas telefonas prisijungia prie jūsų hotspot, nerodo adreso ir niekada jo negauna. Prieigos taškas veikia, DHCP tarnyba veikia, o jūsų parašyta ugniasienės taisyklė atrodo suderinta su adresų planu. Tačiau iš tikrųjų ji reikalauja, kad klientas jau turėtų adresą, kurio prašo. Pirmame DHCP pakete adreso visai nėra, todėl taisyklė niekada nesuveikia.

Stebėkite, kaip prisijungia klientas

Sekite vieną susiejimą iš kliento pusės. Radijo sąsaja susiejama, klientas siunčia DHCP aptikimą, serveris siūlo, klientas prašo, serveris patvirtina, ir tik tada klientas turi adresą, tinkamą kam nors kitam.

Viskas prieš tą galutinį patvirtinimą vyksta tada, kai klientas negali naudoti šliuzo įprastam srautui. Būtent šį langą potinklio taisyklė pamiršta.

Ką pirmasis paketas iš tikrųjų turi

RFC 2131 nustato, kad kliento DHCP transliacijos prieš gaunant adresą naudoja nulinį šaltinio adresą. Pranešimai iš kliento į serverį eina į UDP 67 prievadą, o iš serverio į klientą – į UDP 68 prievadą. Todėl aptikimas ateina su 0.0.0.0 kaip šaltiniu, o taisyklė, reikalaujanti šaltinio jūsų kliento potinklyje, jam tiesiog netinka.

Tai ne kliento pusės klaidinga konfigūracija. Tai protokolas, veikiantis taip, kaip suprojektuotas, vieninteliame lange, kuriame gali.

Kuris kelias tai iš tikrųjų apdoroja

Jei prieigos taškas pats teikia nuomą, tai vietinė paslaugos kalba, o IP filtruojamame vietiniame kelyje tai susiję su įvesties ir išvesties politika. VPN perduodamas kliento srautas yra kitas sprendimas, o NAT tam srautui – dar kitas. Šių trijų painiojimas ir paverčia siaurą išimtį plačia.

Kur paketas apdorojamas, priklauso nuo tarnybos ir naudojamos ugniasienės šeimos. Žalio lizdo realizacijos, tiltų išdėstymai ir ankstesni filtravimo kabliai gali jį perkelti arba užblokuoti visai kitur. Prieš pridėdami taisykles patvirtinkite tarnybos sąsajos susiejimą ir aktyvius kablius.

Bendras įvesties ir išvesties receptas, nukopijuotas iš forumo, nėra įrodymas, kad jūsų realizacija praeina tas grandines taip pat.

Atsakymas ne visada yra transliacija

Išimtis, leidžianti tik transliacijos atsakymus, taip pat neteisinga. DHCP atsakymo paskirties vieta priklauso nuo kliento būsenos ir pranešimo laukų, o protokolas numato ir transliacijos, ir vieno adresato atvejus. Jei jūsų serveris atsako vienu adresu į adresą, kurį ketina skirti, taisyklė, skirta tik transliacijai, blokuoja žingsnį, kuris užbaigia darbą. Rašykite taisyklę pagal mainus, kuriuos konfigūruotas serveris iš tikrųjų atlieka.

Vėlesni nuomos atnaujinimai kartoja mainus kitoje būsenoje, todėl palikite jiems vietos, o ne tik pirmam prisijungimui.

Taisykite siaurai, tada patikrinkite likusią dalį

Išlaikykite esamą politiką, raskite trūkstamą DHCP leidimą ir apribokite jį į klientą atsukta sąsaja, protokolu ir dviem prievadais. Įrodykite, kad užklausa pasiekia paslaugą, tada įrodykite, kad paslauga atsako. Tai du skirtingi stebėjimai, o paslaugos ar adresų fondo konfigūracija vis tiek gali būti neteisinga už tobulo filtravimo.

Lentelės išvalymas nėra DHCP konfigūracijos žingsnis. iptables flush ištrina taisykles iš pasirinktos grandinės ar lentelės, o NAT lentelės išvalymas nesukuria vertimo taisyklės. Plačių ACCEPT politikų nustatymas pašalina su nuoma nesusijusią apsaugą, todėl nė viena iš jų nepriklauso daugkartinio naudojimo hotspot pataisai.

Kai klientas turi nuomą, patikrinkite DNS, persiuntimą ir VPN išėjimą kaip atskiras užduotis. Nuoma nustato vietinį adresavimą ir nieko daugiau.