El tallafoc del teu punt d’accés bloqueja DHCP abans de la concessió

Un telèfon nou s’uneix al teu punt d’accés, no mostra cap adreça i no n’obté mai cap. El punt d’accés està bé, el dimoni DHCP s’executa i la regla de tallafoc que has escrit sembla coherent amb el pla d’adreces. El que fa en realitat és exigir que el client ja tingui l’adreça que demana. El primer paquet DHCP no té cap adreça, així que la regla no s’activa mai.

Observa com s’uneix un client

Segueix una associació des del costat del client. La ràdio s’associa, el client envia un descobriment DHCP, el servidor ofereix, el client sol·licita, el servidor confirma i només llavors el client té una adreça utilitzable per a qualsevol altra cosa.

Tot el que passa abans d’aquesta confirmació final passa mentre el client no pot utilitzar la passarel·la per al trànsit ordinari. Aquesta és la finestra que la regla de subxarxa oblida.

Què conté realment el primer paquet

RFC 2131 especifica que les difusions DHCP d’un client abans d’obtenir una adreça utilitzen una adreça d’origen zero. Els missatges de client a servidor van al port UDP 67, i els de servidor a client al port UDP 68. Per tant, el descobriment arriba amb 0.0.0.0 com a origen, i una regla que exigeixi un origen dins de la teva subxarxa de clients simplement no hi coincideix.

Això no és una configuració incorrecta per part del client. És el protocol funcionant tal com està dissenyat, en l’única finestra on pot fer-ho.

Quin camí ho gestiona realment

Si el mateix punt d’accés serveix concessions, això és una conversa de servei local i, en un camí local filtrat per IP, afecta la política d’entrada i sortida. El trànsit de client reenviat per la VPN és una decisió diferent, i el NAT per a aquest trànsit ho és encara més. Confondre les tres coses és com una excepció estreta es converteix en àmplia.

On es gestiona el paquet depèn del dimoni i de la família de tallafoc en ús. Les implementacions amb sòcols en brut, els ponts i els ganxos de filtratge anteriors poden moure’l o bloquejar-lo en un lloc completament diferent. Confirma l’enllaç d’interfície del dimoni i els ganxos actius abans d’afegir regles.

Una recepta genèrica d’entrada/sortida copiada d’un fòrum no és prova que la teva implementació travessi aquestes cadenes de la mateixa manera.

La resposta no sempre és una difusió

Una excepció que només permet respostes de difusió també és incorrecta. La destinació de la resposta DHCP depèn de l’estat del client i dels camps del missatge, i el protocol especifica tant el cas de difusió com el d’unicast. Si el teu servidor respon per unicast a una adreça que està a punt d’assignar, una regla només de difusió bloqueja el pas que acaba la feina. Escriu la regla segons l’intercanvi que fa realment el servidor configurat.

Les renovacions posteriors de la concessió repeteixen l’intercanvi en un estat diferent, així que deixa espai per a elles i no només per a la primera unió.

Corregeix de manera estreta i després revisa la resta

Mantén la política existent, troba el permís DHCP que falta i limita’l a la interfície orientada al client, al protocol i als dos ports. Demostra que la petició arriba al servei i després demostra que el servei respon. Són dues observacions diferents, i la configuració del servei o del conjunt d’adreces encara pot ser incorrecta darrere d’un filtratge perfecte.

Buidar una taula no és un pas de configuració de DHCP. A iptables, flush elimina regles de la cadena o taula seleccionada, i buidar la taula NAT no crea cap regla de traducció. Establir polítiques ACCEPT àmplies elimina protecció no relacionada amb la concessió, i per això cap de les dues coses no pertany a una correcció reutilitzable per a un punt d’accés.

Un cop el client té una concessió, comprova DNS, reenviament i sortida de la VPN com a tasques separades. Una concessió estableix l’adreçament local i res més enllà.