Firewallul hotspotului tău blochează DHCP înainte de închiriere

Un telefon nou se conectează la hotspotul tău, nu afișează nicio adresă și nu primește niciodată una. Punctul de acces este în regulă, demonul DHCP rulează, iar regula de firewall pe care ai scris-o pare coerentă cu planul de adrese. Ce face de fapt este să ceară ca clientul să aibă deja adresa pe care o solicită. Primul pachet DHCP nu are deloc adresă, așa că regula nu se activează niciodată.

Urmărește cum se conectează un client

Urmărește o asociere din partea clientului. Radioul se asociază, clientul trimite o descoperire DHCP, serverul oferă, clientul cere, serverul confirmă, și abia apoi clientul are o adresă utilizabilă pentru orice altceva.

Tot ce se întâmplă înainte de acea confirmare finală are loc în timp ce clientul nu poate folosi poarta de acces pentru trafic obișnuit. Aceasta este fereastra pe care regula de subrețea o uită.

Ce conține de fapt primul pachet

RFC 2131 specifică faptul că difuzările DHCP ale unui client înainte de a obține o adresă folosesc o adresă sursă zero. Mesajele de la client la server merg la portul UDP 67, iar cele de la server la client la portul UDP 68. De aceea descoperirea sosește cu 0.0.0.0 ca sursă, iar o regulă care cere o sursă în interiorul subrețelei tale de clienți pur și simplu nu se potrivește cu ea.

Nu este o configurare greșită din partea clientului. Este protocolul funcționând așa cum a fost proiectat, în singura fereastră în care poate.

Ce cale se ocupă de fapt de asta

Dacă punctul de acces însuși oferă închirieri, aceasta este o conversație de serviciu locală, iar pe o cale locală filtrată după IP ține de politica de intrare și ieșire. Traficul clientului redirecționat prin VPN este o altă decizie, iar NAT-ul pentru acel trafic este din nou altceva. Confundarea celor trei este modul în care o excepție îngustă devine largă.

Unde este tratat pachetul depinde de demon și de familia de firewall folosită. Implementările cu socketuri brute, aranjamentele de punte și cârligele de filtrare anterioare îl pot muta sau bloca cu totul altundeva. Confirmă legarea interfeței demonului și cârligele active înainte de a adăuga reguli.

O rețetă generică de intrare și ieșire copiată de pe un forum nu este dovada că implementarea ta parcurge acele lanțuri în același fel.

Răspunsul nu este întotdeauna o difuzare

O excepție care permite doar răspunsuri de difuzare este și ea greșită. Destinația răspunsului DHCP depinde de starea clientului și de câmpurile mesajului, iar protocolul specifică atât cazul de difuzare, cât și cel unicast. Dacă serverul tău răspunde prin unicast la o adresă pe care urmează să o aloce, o regulă doar pentru difuzare blochează pasul care termină treaba. Scrie regula în funcție de schimbul pe care serverul configurat îl efectuează de fapt.

Reînnoirile ulterioare ale închirierii repetă schimbul într-o altă stare, așa că lasă loc pentru ele și nu doar pentru prima conectare.

Corectează îngust, apoi verifică restul

Păstrează politica existentă, găsește permisiunea DHCP lipsă și limiteaz-o la interfața orientată spre client, la protocol și la cele două porturi. Demonstrează că cererea ajunge la serviciu, apoi demonstrează că serviciul răspunde. Sunt două observații diferite, iar configurația serviciului sau a grupului de adrese poate fi încă greșită în spatele unei filtrări perfecte.

Golirea unui tabel nu este un pas de configurare DHCP. În iptables, flush șterge regulile din lanțul sau tabelul selectat, iar golirea tabelului NAT nu creează o regulă de traducere. Setarea unor politici ACCEPT largi elimină protecția care nu are legătură cu închirierea, motiv pentru care niciuna dintre ele nu își are locul într-o corectură reutilizabilă pentru hotspot.

Odată ce clientul are o închiriere, verifică DNS, redirecționarea și ieșirea prin VPN ca sarcini separate. O închiriere stabilește adresarea locală și nimic mai mult.