Votre pare-feu de hotspot bloque DHCP avant le bail

Un nouveau téléphone rejoint votre hotspot, n’affiche aucune adresse et n’en obtient jamais. Le point d’accès est en bon état, le démon DHCP tourne, et la règle de pare-feu que vous avez écrite semble cohérente avec le plan d’adressage. En réalité, elle exige que le client possède déjà l’adresse qu’il demande. Le premier paquet DHCP n’a aucune adresse, donc la règle ne se déclenche jamais.

Observez l’arrivée d’un client

Suivez une association du côté du client. La radio s’associe, le client envoie une découverte DHCP, le serveur propose, le client demande, le serveur accuse réception, et c’est seulement alors que le client dispose d’une adresse utilisable pour autre chose.

Tout ce qui précède cet accusé de réception final se produit pendant que le client ne peut pas utiliser la passerelle pour le trafic ordinaire. C’est précisément la fenêtre que la règle de sous-réseau oublie.

Ce que contient réellement le premier paquet

RFC 2131 spécifie que les diffusions DHCP d’un client avant l’obtention d’une adresse utilisent une adresse source nulle. Les messages du client vers le serveur vont au port UDP 67, et ceux du serveur vers le client au port UDP 68. La découverte arrive donc avec 0.0.0.0 comme source, et une règle exigeant une source à l’intérieur de votre sous-réseau client ne correspond tout simplement pas.

Ce n’est pas une mauvaise configuration de la part du client. C’est le protocole qui fonctionne comme prévu, dans la seule fenêtre où il le peut.

Quel chemin le traite réellement

Si le point d’accès assure lui-même les baux, il s’agit d’une conversation de service locale, et sur un chemin local filtré par IP, cela concerne la politique d’entrée et de sortie. Le trafic client transféré par le VPN est une autre décision, et le NAT pour ce trafic en est encore une autre. Confondre les trois, c’est ainsi qu’une exception étroite devient large.

L’endroit où le paquet est traité dépend du démon et de la famille de pare-feu utilisée. Les implémentations à sockets bruts, les montages en pont et les crochets de filtrage antérieurs peuvent le déplacer ou le bloquer complètement ailleurs. Confirmez le rattachement d’interface du démon et les crochets actifs avant d’ajouter des règles.

Une recette générique d’entrée et de sortie copiée d’un forum ne prouve pas que votre implémentation traverse ces chaînes de la même manière.

La réponse n’est pas toujours une diffusion

Une exception qui n’autorise que les réponses en diffusion est également fausse. La destination de la réponse DHCP dépend de l’état du client et des champs du message, et le protocole prévoit aussi bien le cas de la diffusion que celui de l’unicast. Si votre serveur répond en unicast à une adresse qu’il est sur le point d’attribuer, une règle limitée à la diffusion bloque l’étape qui termine le travail. Écrivez la règle en fonction de l’échange que le serveur configuré effectue réellement.

Les renouvellements ultérieurs du bail répètent l’échange dans un autre état, alors laissez-leur de la place et pas seulement à la première connexion.

Corrigez étroitement, puis vérifiez le reste

Conservez la politique existante, trouvez l’autorisation DHCP manquante et limitez-la à l’interface côté client, au protocole et aux deux ports. Prouvez que la requête atteint le service, puis prouvez que le service répond. Ce sont deux observations distinctes, et la configuration du service ou du pool peut encore être erronée derrière un filtrage parfait.

Vider une table n’est pas une étape de configuration DHCP. Dans iptables, flush supprime les règles de la chaîne ou de la table sélectionnée, et vider la table NAT ne crée pas de règle de traduction. Définir de larges politiques ACCEPT supprime une protection sans rapport avec le bail, c’est pourquoi ni l’une ni l’autre n’a sa place dans un correctif de hotspot réutilisable.

Une fois que le client détient un bail, vérifiez DNS, transfert et sortie VPN comme des tâches distinctes. Un bail établit l’adressage local et rien de plus.