Ihre Hotspot-Firewall blockiert DHCP vor der Lease

Ein neues Telefon verbindet sich mit Ihrem Hotspot, zeigt keine Adresse an und bekommt nie eine. Der Access Point ist in Ordnung, der DHCP-Daemon läuft, und die Firewall-Regel, die Sie geschrieben haben, sieht zum Adressplan passend aus. Tatsächlich verlangt sie, dass der Client die Adresse, die er anfragt, bereits besitzt. Das erste DHCP-Paket hat gar keine Adresse, also greift die Regel nie.

Sehen Sie zu, wie ein Client beitritt

Verfolgen Sie eine Assoziation aus Sicht des Clients. Das Funkmodul assoziiert, der Client sendet eine DHCP-Discovery, der Server bietet an, der Client fordert an, der Server bestätigt, und erst dann hat der Client eine Adresse, die für irgendetwas anderes nutzbar ist.

Alles vor dieser letzten Bestätigung geschieht, während der Client das Gateway nicht für normalen Verkehr nutzen kann. Genau dieses Fenster vergisst die Subnetz-Regel.

Was das erste Paket tatsächlich enthält

RFC 2131 legt fest, dass DHCP-Broadcasts eines Clients vor dem Erhalt einer Adresse die Quelladresse null verwenden. Nachrichten vom Client zum Server gehen an UDP-Port 67, Nachrichten vom Server zum Client an UDP-Port 68. Die Discovery kommt also mit 0.0.0.0 als Quelle an, und eine Regel, die eine Quelle innerhalb Ihres Client-Subnetzes verlangt, greift darauf schlicht nicht.

Das ist keine Fehlkonfiguration auf Seiten des Clients. Es ist das Protokoll, das so arbeitet, wie es entworfen wurde, im einzigen Fenster, in dem es das kann.

Welcher Pfad es tatsächlich behandelt

Wenn der Access Point selbst Leases vergibt, ist das ein lokales Dienstgespräch, und in einem IP-gefilterten lokalen Pfad betrifft es die Eingangs- und Ausgangsrichtlinie. Weitergeleiteter Client-Verkehr durch das VPN ist eine andere Entscheidung, und NAT für diesen Verkehr ist wieder etwas anderes. Diese drei zu vermischen, ist der Weg, auf dem aus einer engen Ausnahme eine breite wird.

Wo das Paket behandelt wird, hängt vom Daemon und der verwendeten Firewall-Familie ab. Raw-Socket-Implementierungen, Bridge-Anordnungen und frühere Filter-Hooks können es ganz woanders hin verschieben oder blockieren. Bestätigen Sie die Interface-Bindung des Daemons und die aktiven Hooks, bevor Sie Regeln hinzufügen.

Ein allgemeines Rezept für Ein- und Ausgabe aus einem Forum ist kein Beleg dafür, dass Ihre Implementierung dieselben Ketten auf dieselbe Weise durchläuft.

Die Antwort ist nicht immer ein Broadcast

Auch eine Ausnahme, die nur Broadcast-Antworten erlaubt, ist falsch. Das Ziel der DHCP-Antwort hängt vom Zustand des Clients und den Feldern der Nachricht ab, und das Protokoll sieht sowohl Broadcast- als auch Unicast-Fälle vor. Wenn Ihr Server per Unicast an eine Adresse antwortet, die er gerade zuweisen will, blockiert eine reine Broadcast-Regel den Schritt, der die Aufgabe abschließt. Schreiben Sie die Regel auf den Austausch bezogen, den der konfigurierte Server tatsächlich ausführt.

Spätere Lease-Erneuerungen wiederholen den Austausch in einem anderen Zustand, also lassen Sie Raum dafür und nicht nur für den ersten Beitritt.

Eng korrigieren, dann den Rest prüfen

Behalten Sie die bestehende Richtlinie, finden Sie die fehlende DHCP-Freigabe und begrenzen Sie sie auf das clientseitige Interface, das Protokoll und die beiden Ports. Beweisen Sie, dass die Anfrage den Dienst erreicht, und beweisen Sie dann, dass der Dienst antwortet. Das sind zwei verschiedene Beobachtungen, und die Dienst- oder Pool-Konfiguration kann hinter perfekter Filterung immer noch falsch sein.

Eine Tabelle zu leeren ist kein DHCP-Konfigurationsschritt. In iptables löscht flush Regeln aus der gewählten Kette oder Tabelle, und das Leeren der NAT-Tabelle erzeugt keine Übersetzungsregel. Breite ACCEPT-Richtlinien entfernen Schutz, der nichts mit der Lease-Vergabe zu tun hat, weshalb keines von beiden in eine wiederverwendbare Hotspot-Korrektur gehört.

Sobald der Client eine Lease hat, prüfen Sie DNS, Weiterleitung und VPN-Ausgang als getrennte Aufgaben. Eine Lease stellt lokale Adressierung her und nichts darüber hinaus.