Firewall vašeho hotspotu blokuje DHCP před přidělením

Nový telefon se připojí k vašemu hotspotu, nezobrazí adresu a nikdy ji nedostane. Přístupový bod je v pořádku, daemon DHCP běží a pravidlo firewallu, které jste napsali, vypadá v souladu s plánem adres. Ve skutečnosti ale vyžaduje, aby klient už měl adresu, o kterou žádá. První paket DHCP nemá vůbec žádnou adresu, takže pravidlo nikdy nezasáhne.

Sledujte, jak se klient připojuje

Sledujte jedno přidružení ze strany klienta. Rádio se přidruží, klient odešle zjišťování DHCP, server nabídne, klient požádá, server potvrdí, a teprve potom má klient adresu použitelnou pro cokoli dalšího.

Vše před tímto konečným potvrzením se odehrává, zatímco klient nemůže bránu používat pro běžný provoz. To je okno, na které pravidlo podsítě zapomíná.

Co první paket skutečně obsahuje

RFC 2131 stanoví, že vysílání DHCP klienta před získáním adresy používají nulovou zdrojovou adresu. Zprávy od klienta k serveru jdou na port UDP 67 a zprávy od serveru ke klientovi na port UDP 68. Zjišťování tedy přichází se zdrojem 0.0.0.0 a pravidlo vyžadující zdroj uvnitř vaší klientské podsítě mu prostě neodpovídá.

To není chybná konfigurace na straně klienta. To protokol funguje tak, jak byl navržen, v jediném okně, kde to jde.

Která cesta to skutečně obsluhuje

Pokud přidělení zajišťuje sám přístupový bod, jde o místní rozhovor se službou a v místní cestě filtrované podle IP se týká zásad vstupu a výstupu. Předávaný klientský provoz přes VPN je jiné rozhodnutí a NAT pro tento provoz je zase jiný. Záměna těchto tří věcí je způsob, jak se úzká výjimka stane širokou.

Kde se paket zpracuje, závisí na daemonu a použité rodině firewallu. Implementace se surovými sockety, mostní uspořádání a dřívější háčky filtrování jej mohou přesunout nebo zablokovat úplně jinde. Před přidáním pravidel potvrďte vazbu rozhraní daemonu a aktivní háčky.

Obecný recept na vstup/výstup zkopírovaný z fóra není důkazem, že vaše implementace prochází stejnými řetězci stejně.

Odpověď není vždy vysílání

Výjimka, která povoluje jen vysílané odpovědi, je také chybná. Cíl odpovědi DHCP závisí na stavu klienta a polích zprávy a protokol stanoví jak vysílací, tak jednosměrový případ. Pokud váš server odpovídá jednosměrově na adresu, kterou se chystá přidělit, pravidlo jen pro vysílání zablokuje krok, který práci dokončí. Napište pravidlo podle výměny, kterou konfigurovaný server skutečně provádí.

Pozdější obnovení přidělení opakují výměnu v jiném stavu, takže pro ně nechte prostor, ne jen pro první připojení.

Opravujte úzce, pak zkontrolujte zbytek

Zachovejte stávající zásady, najděte chybějící povolení DHCP a omezte je na rozhraní obrácené ke klientovi, protokol a dva porty. Dokažte, že požadavek dorazí ke službě, a potom dokažte, že služba odpovídá. To jsou dvě různá pozorování a konfigurace služby nebo fondu adres může být i za dokonalým filtrováním stále špatná.

Vyprázdnění tabulky není krok konfigurace DHCP. V iptables flush maže pravidla z vybraného řetězce nebo tabulky a vyprázdnění tabulky NAT nevytváří pravidlo překladu. Nastavení širokých zásad ACCEPT odstraňuje ochranu nesouvisející s přidělováním, a proto ani jedno z toho do opakovaně použitelné opravy hotspotu nepatří.

Jakmile klient získá přidělení, zkontrolujte DNS, předávání a výstup přes VPN jako samostatné úkoly. Přidělení zavádí místní adresování a nic víc.