Zapora hotspota blokuje DHCP przed dzierżawą

Nowy telefon łączy się z twoim hotspotem, nie pokazuje adresu i nigdy go nie dostaje. Punkt dostępowy jest w porządku, demon DHCP działa, a reguła zapory, którą napisałeś, wygląda na spójną z planem adresów. W rzeczywistości wymaga ona, aby klient już miał adres, o który prosi. Pierwszy pakiet DHCP nie ma żadnego adresu, więc reguła nigdy nie zadziała.

Obserwuj, jak klient się łączy

Prześledź jedno skojarzenie od strony klienta. Radio się kojarzy, klient wysyła odkrywanie DHCP, serwer oferuje, klient żąda, serwer potwierdza, i dopiero wtedy klient ma adres użyteczny do czegokolwiek innego.

Wszystko przed tym końcowym potwierdzeniem dzieje się, gdy klient nie może używać bramy do zwykłego ruchu. To jest okno, o którym reguła podsieci zapomina.

Co naprawdę zawiera pierwszy pakiet

RFC 2131 określa, że rozgłoszenia DHCP klienta przed uzyskaniem adresu używają zerowego adresu źródłowego. Komunikaty od klienta do serwera idą na port UDP 67, a od serwera do klienta na port UDP 68. Dlatego odkrywanie przychodzi z 0.0.0.0 jako źródłem, a reguła wymagająca źródła w twojej podsieci klientów po prostu do niego nie pasuje.

To nie jest błędna konfiguracja po stronie klienta. To protokół działający zgodnie z projektem, w jedynym oknie, w którym może.

Która ścieżka faktycznie to obsługuje

Jeśli punkt dostępowy sam przydziela dzierżawy, jest to lokalna rozmowa z usługą, a w lokalnej ścieżce filtrowanej po IP dotyczy polityki wejścia i wyjścia. Ruch klienta przekazywany przez VPN to inna decyzja, a NAT dla tego ruchu to jeszcze coś innego. Mieszanie tych trzech to sposób, w jaki wąski wyjątek staje się szeroki.

Gdzie pakiet jest obsługiwany, zależy od demona i używanej rodziny zapory. Implementacje z surowymi gniazdami, układy mostkowe i wcześniejsze haki filtrowania mogą go przenieść lub zablokować zupełnie gdzie indziej. Potwierdź powiązanie interfejsu demona i aktywne haki, zanim dodasz reguły.

Ogólny przepis na wejście i wyjście skopiowany z forum nie jest dowodem, że twoja implementacja przechodzi przez te łańcuchy w ten sam sposób.

Odpowiedź nie zawsze jest rozgłoszeniem

Wyjątek zezwalający tylko na odpowiedzi rozgłoszeniowe też jest błędny. Miejsce docelowe odpowiedzi DHCP zależy od stanu klienta i pól komunikatu, a protokół określa zarówno przypadek rozgłoszenia, jak i unicastu. Jeśli twój serwer odpowiada unicastem na adres, który ma właśnie przydzielić, reguła tylko dla rozgłoszeń blokuje krok kończący pracę. Napisz regułę pod wymianę, którą skonfigurowany serwer faktycznie wykonuje.

Późniejsze odnowienia dzierżawy powtarzają wymianę w innym stanie, więc zostaw dla nich miejsce, a nie tylko dla pierwszego połączenia.

Napraw wąsko, potem sprawdź resztę

Zachowaj istniejącą politykę, znajdź brakujące zezwolenie DHCP i ogranicz je do interfejsu zwróconego do klienta, protokołu i dwóch portów. Udowodnij, że żądanie dociera do usługi, a następnie udowodnij, że usługa odpowiada. To dwie różne obserwacje, a konfiguracja usługi lub puli nadal może być błędna za doskonałym filtrowaniem.

Czyszczenie tabeli nie jest krokiem konfiguracji DHCP. W iptables flush usuwa reguły z wybranego łańcucha lub tabeli, a czyszczenie tabeli NAT nie tworzy reguły tłumaczenia. Ustawianie szerokich polityk ACCEPT usuwa ochronę niezwiązaną z dzierżawą, dlatego żadne z nich nie należy do wielokrotnego użytku poprawki hotspota.

Gdy klient ma dzierżawę, sprawdź DNS, przekazywanie i wyjście VPN jako osobne zadania. Dzierżawa ustanawia lokalne adresowanie i nic więcej.