Firewall vášho hotspotu blokuje DHCP pred prenájmom

Nový telefón sa pripojí k vášmu hotspotu, nezobrazí adresu a nikdy ju nedostane. Prístupový bod je v poriadku, démon DHCP beží a pravidlo firewallu, ktoré ste napísali, vyzerá v súlade s plánom adries. V skutočnosti však vyžaduje, aby klient už mal adresu, o ktorú žiada. Prvý paket DHCP nemá vôbec žiadnu adresu, takže pravidlo nikdy nezasiahne.

Sledujte, ako sa klient pripája

Sledujte jedno pridruženie zo strany klienta. Rádio sa pridruží, klient odošle zisťovanie DHCP, server ponúkne, klient požiada, server potvrdí, a až potom má klient adresu použiteľnú na čokoľvek iné.

Všetko pred týmto konečným potvrdením sa deje, kým klient nemôže používať bránu na bežnú prevádzku. To je okno, na ktoré pravidlo podsiete zabúda.

Čo prvý paket skutočne obsahuje

RFC 2131 stanovuje, že vysielania DHCP klienta pred získaním adresy používajú nulovú zdrojovú adresu. Správy od klienta k serveru idú na port UDP 67 a správy od servera ku klientovi na port UDP 68. Zisťovanie preto prichádza so zdrojom 0.0.0.0 a pravidlo vyžadujúce zdroj v rámci vašej klientskej podsiete mu jednoducho nezodpovedá.

To nie je chybná konfigurácia na strane klienta. To protokol funguje tak, ako bol navrhnutý, v jedinom okne, kde to ide.

Ktorá cesta to skutočne obsluhuje

Ak pridelenie zabezpečuje samotný prístupový bod, ide o miestny rozhovor so službou a v miestnej ceste filtrovanej podľa IP sa týka zásad vstupu a výstupu. Preposielaná klientska prevádzka cez VPN je iné rozhodnutie a NAT pre túto prevádzku je zase iný. Zámena týchto troch vecí je spôsob, akým sa úzka výnimka stane širokou.

Kde sa paket spracuje, závisí od démona a použitej rodiny firewallu. Implementácie so surovými socketmi, mostné usporiadania a skoršie háčiky filtrovania ho môžu presunúť alebo zablokovať úplne inde. Pred pridaním pravidiel potvrďte väzbu rozhrania démona a aktívne háčiky.

Všeobecný recept na vstup a výstup skopírovaný z fóra nie je dôkazom, že vaša implementácia prechádza tými istými reťazcami rovnako.

Odpoveď nie je vždy vysielanie

Výnimka, ktorá povoľuje iba vysielané odpovede, je tiež chybná. Cieľ odpovede DHCP závisí od stavu klienta a polí správy a protokol stanovuje vysielací aj jednosmerný prípad. Ak váš server odpovedá jednosmerne na adresu, ktorú sa chystá prideliť, pravidlo iba pre vysielanie zablokuje krok, ktorý prácu dokončí. Napíšte pravidlo podľa výmeny, ktorú konfigurovaný server skutočne vykonáva.

Neskoršie obnovenia prenájmu opakujú výmenu v inom stave, preto na ne nechajte priestor, nielen na prvé pripojenie.

Opravujte úzko, potom skontrolujte zvyšok

Zachovajte existujúce zásady, nájdite chýbajúce povolenie DHCP a obmedzte ho na rozhranie obrátené ku klientovi, protokol a dva porty. Dokážte, že požiadavka dorazí k službe, a potom dokážte, že služba odpovedá. Sú to dve rôzne pozorovania a konfigurácia služby alebo fondu adries môže byť aj za dokonalým filtrovaním stále nesprávna.

Vyprázdnenie tabuľky nie je krok konfigurácie DHCP. V iptables flush maže pravidlá z vybraného reťazca alebo tabuľky a vyprázdnenie tabuľky NAT nevytvára pravidlo prekladu. Nastavenie širokých zásad ACCEPT odstraňuje ochranu nesúvisiacu s prenájmom, a preto ani jedno z toho nepatrí do opakovane použiteľnej opravy hotspotu.

Keď klient získa prenájom, skontrolujte DNS, preposielanie a výstup cez VPN ako samostatné úlohy. Prenájom zavádza miestne adresovanie a nič viac.