Hotspotens brandvägg blockerar DHCP före arrendet

En ny telefon ansluter till din hotspot, visar ingen adress och får aldrig någon. Åtkomstpunkten är i ordning, DHCP-demonen kör, och brandväggsregeln du skrev ser ut att stämma med adressplanen. Vad den faktiskt gör är att kräva att klienten redan har den adress den frågar efter. Det första DHCP-paketet har ingen adress alls, så regeln utlöses aldrig.

Se hur en klient ansluter

Följ en associering från klientsidan. Radion associerar, klienten skickar en DHCP-upptäckt, servern erbjuder, klienten begär, servern bekräftar, och först då har klienten en adress som går att använda till något annat.

Allt före den slutliga bekräftelsen sker medan klienten inte kan använda gatewayen för vanlig trafik. Det är fönstret som nätregeln glömmer.

Vad det första paketet faktiskt innehåller

RFC 2131 anger att en klients DHCP-utsändningar innan den får en adress använder källadressen noll. Meddelanden från klient till server går till UDP-port 67, och från server till klient till UDP-port 68. Upptäckten anländer därför med 0.0.0.0 som källa, och en regel som kräver en källa inom ditt klientnät matchar den helt enkelt inte.

Det är inte felkonfiguration på klientsidan. Det är protokollet som fungerar som det är designat, i det enda fönster där det kan.

Vilken väg som faktiskt hanterar det

Om åtkomstpunkten själv delar ut arrenden är detta ett lokalt tjänstesamtal, och på en IP-filtrerad lokal väg handlar det om in- och utpolicy. Vidarebefordrad klienttrafik genom VPN är ett annat beslut, och NAT för den trafiken är återigen något annat. Att blanda de tre är hur ett smalt undantag blir brett.

Var paketet hanteras beror på demonen och den brandväggsfamilj som används. Rå-socket-implementationer, broar och tidigare filtreringskrokar kan flytta eller blockera det helt någon annanstans. Bekräfta demonens gränssnittsbindning och de aktiva krokarna innan du lägger till regler.

Ett generiskt recept för in- och utdata kopierat från ett forum är inte bevis för att din implementation går genom samma kedjor på samma sätt.

Svaret är inte alltid en utsändning

Ett undantag som bara tillåter utsända svar är också fel. DHCP-svarets destination beror på klientens tillstånd och meddelandets fält, och protokollet anger både utsändnings- och unicast-fallet. Om din server svarar med unicast till en adress den är på väg att tilldela, blockerar en regel enbart för utsändning steget som gör jobbet klart. Skriv regeln mot det utbyte som den konfigurerade servern faktiskt utför.

Senare förnyelser av arrendet upprepar utbytet i ett annat tillstånd, så lämna plats för dem och inte bara för den första anslutningen.

Rätta smalt och kontrollera sedan resten

Behåll den befintliga policyn, hitta det saknade DHCP-tillståndet och begränsa det till gränssnittet mot klienten, protokollet och de två portarna. Bevisa att förfrågan når tjänsten och bevisa sedan att tjänsten svarar. Det är två olika observationer, och tjänste- eller poolkonfiguration kan fortfarande vara fel bakom perfekt filtrering.

Att tömma en tabell är inte ett DHCP-konfigurationssteg. I iptables raderar flush regler från den valda kedjan eller tabellen, och tömning av NAT-tabellen skapar ingen översättningsregel. Breda ACCEPT-policyer tar bort skydd som inte har med utdelning att göra, och därför hör inget av dem hemma i en återanvändbar hotspot-rättelse.

När klienten har ett arrende, kontrollera DNS, vidarebefordran och VPN-utgång som separata uppgifter. Ett arrende etablerar lokal adressering och inget därutöver.