Pont TAP virtuel dans pfSense : trois endroits où une trame peut mourir

Vous désactivez une règle sur l'interface LAN, la trame disparaît toujours, et la conclusion est que pfSense ignore son propre pare-feu. Ce qui s'est généralement produit, c'est qu'un autre propriétaire a pris la décision : le pont lui-même, l'interface membre ou le commutateur virtuel en dehors de l'invité. Chacun a son propre contrôle et son propre journal.

Les trois frontières ci-dessous méritent d'être séparées avant de changer un réglage, car désactiver l'une ne compense pas l'autre.

Une trame, trois propriétaires de politique

Une trame d'un client TAP entre par le périphérique de tunnel, traverse le pont pfSense, sort par un membre LAN, puis passe par un commutateur virtuel avant d'atteindre quoi que ce soit. À l'intérieur de l'invité, le filtrage peut se produire sur le pont ou sur les interfaces membres, et celle qui est active est un choix de configuration et non une propriété fixe. En dehors de l'invité, l'hyperviseur décide si cet adaptateur virtuel peut transmettre des trames avec une MAC source qu'il ne possède pas. Une chute à l'un de ces points est identique du point de vue du client.

Écrivez le chemin prévu avant d'enquêter : membre de tunnel, pont, membre LAN, commutateur virtuel, destination. Demandez ensuite quel propriétaire sur ce chemin aurait vu la trame.

Quel contrôle de pfSense filtre

pfSense documente deux sysctl pour cela, un pour le filtrage sur les membres du pont et un pour le filtrage sur le pont lui-même, et au moins l'un des deux doit rester activé. Le filtrage au niveau du pont s'applique au trafic qui arrive par les membres du pont, il est donc entrant en orientation et non symétrique. Lisez les règles sur l'interface qui filtre réellement, car une règle placée sur un membre sans rôle de filtrage ne fait absolument rien. La documentation sur le filtrage du pont précise la propriété.

Une interface membre sans adresse IP n'a pas de macro d'adresse ou de sous-réseau propre, donc une règle écrite contre cette macro peut décrire autre chose que le LAN voulu. Utilisez des objets réseau attribués volontairement plutôt que des macros de commodité.

Un fragment n'est pas une trame

Les trames Ethernet transportent des paquets IP, et un paquet IP peut être un fragment d'un datagramme plus grand, donc les deux mots ne sont pas interchangeables. Il y a aussi un paquet interne à l'intérieur du tunnel et un paquet de transport externe à l'extérieur, et une défaillance peut appartenir à l'un ou à l'autre. Un petit ping exerce un chemin à travers cette pile et ne prouve rien sur un transfert important. Comparez l'échange qui échoue à deux frontières adjacentes et lisez la raison de la chute avant d'accuser une règle.

Si les fragments disparaissent, la réponse est une correction ciblée ou une enquête sur la taille des paquets, pas une décision de désactiver le filtrage entièrement.

L'hyperviseur a sa propre décision d'admission

Un invité qui pont le trafic pour d'autres machines émet des trames dont les adresses MAC source ne sont pas celles de son propre adaptateur, et beaucoup de commutateurs virtuels traitent cela comme de l'usurpation sauf si le groupe de ports l'autorise. Autoriser cette transmission et autoriser l'adaptateur à recevoir chaque trame sont des contrôles distincts, et activer les deux partout est un changement bien plus important que ce que le problème exige. Déterminez quelles trames le pont doit recevoir et doit émettre, puis n'accordez que ce comportement à la frontière qui en est propriétaire. Conservez l'accès à la console avant de modifier un pont géré à distance.

Rétablir la connectivité est la moitié du test ; l'autre moitié consiste à confirmer qu'un flux qui doit rester bloqué l'est toujours.

Notez quel propriétaire a filtré, quel contrôle a changé et quels deux flux vous avez vérifiés. Cette note empêche l'incident suivant de commencer avec la même supposition que pfSense s'ignore lui-même.