Virtuelle pfSense-TAP-Brücke: drei Stellen, an denen ein Rahmen sterben kann
Die Brücke, ihre Mitglieder und der virtuelle Switch entscheiden jeweils getrennt. Finden Sie heraus, welcher Eigentümer gefiltert hat, bevor Sie eine Kontrolle abschalten, die nie im Pfad lag.
Sie deaktivieren eine Regel auf dem LAN-Interface, der Rahmen verschwindet weiterhin, und die Schlussfolgerung lautet, dass pfSense seine eigene Firewall ignoriert. Meistens hat ein anderer Eigentümer die Entscheidung getroffen: die Brücke selbst, das Mitglieds-Interface oder der virtuelle Switch außerhalb des Gasts. Jeder hat seine eigene Kontrolle und sein eigenes Protokoll.
Die drei Grenzen unten sollte man trennen, bevor man eine Einstellung ändert, denn das Abschalten der einen kann die andere nicht ersetzen.
Ein Rahmen, drei Richtlinieneigentümer
Ein Rahmen eines TAP-Clients kommt über das Tunnelgerät herein, überquert die pfSense-Brücke, verlässt sie über ein LAN-Mitglied und passiert dann einen virtuellen Switch, bevor er irgendetwas erreicht. Innerhalb des Gasts kann die Filterung an der Brücke oder an den Mitglieds-Interfaces stattfinden, und welche davon aktiv ist, ist eine Konfigurationsentscheidung und keine feste Eigenschaft. Außerhalb des Gasts entscheidet der Hypervisor, ob dieser virtuelle Adapter Rahmen mit einer Quell-MAC senden darf, die ihm nicht gehört. Ein Verwerfen an einer dieser Stellen sieht vom Client aus identisch aus.
Schreiben Sie den beabsichtigten Pfad vor der Untersuchung auf: Tunnelmitglied, Brücke, LAN-Mitglied, virtueller Switch, Ziel. Fragen Sie dann, welcher Eigentümer auf diesem Pfad den Rahmen gesehen hätte.
Welche pfSense-Kontrolle filtert
pfSense dokumentiert dafür zwei sysctl-Parameter, einen für die Filterung an den Brückenmitgliedern und einen für die Filterung an der Brücke selbst, und mindestens einer davon muss aktiviert bleiben. Die Filterung auf Brückenebene gilt für Verkehr, der über die Brückenmitglieder ankommt, sie ist also von der Richtung her eingehend und nicht symmetrisch. Lesen Sie die Regeln an dem Interface, das tatsächlich filtert, denn eine Regel an einem Mitglied ohne Filterrolle bewirkt überhaupt nichts. Die Dokumentation zur Brückenfilterung erläutert die Zuständigkeit.
Ein Mitglieds-Interface ohne IP-Adresse hat kein eigenes Adress- oder Subnetz-Makro, daher kann eine gegen dieses Makro geschriebene Regel etwas anderes beschreiben als das gemeinte LAN. Verwenden Sie bewusst zugewiesene Netzwerkobjekte statt praktischer Makros.
Ein Fragment ist kein Rahmen
Ethernet-Rahmen transportieren IP-Pakete, und ein IP-Paket kann ein Fragment eines größeren Datagramms sein, die beiden Wörter sind also nicht austauschbar. Es gibt außerdem ein inneres Paket innerhalb des Tunnels und ein äußeres Transportpaket außerhalb davon, und ein Fehler kann zu jedem von beiden gehören. Ein kleiner Ping prüft einen Pfad durch diesen Stapel und beweist nichts über eine große Übertragung. Vergleichen Sie den fehlschlagenden Austausch an zwei benachbarten Grenzen und lesen Sie den Verwerfungsgrund, bevor Sie eine Regel beschuldigen.
Wenn Fragmente verschwinden, ist die Antwort eine gezielte Korrektur oder eine Untersuchung der Paketgröße, nicht die Entscheidung, die Filterung ganz abzuschalten.
Der Hypervisor hat seine eigene Zulassungsentscheidung
Ein Gast, der Verkehr für andere Maschinen überbrückt, sendet Rahmen, deren Quell-MAC-Adressen nicht die seines eigenen Adapters sind, und viele virtuelle Switches behandeln das als Spoofing, sofern die Portgruppe es nicht erlaubt. Diese Übertragung zu erlauben und dem Adapter zu erlauben, jeden Rahmen zu empfangen, sind getrennte Kontrollen, und beide überall zu aktivieren ist eine viel größere Änderung, als das Problem erfordert. Ermitteln Sie, welche Rahmen die Brücke empfangen und senden muss, und gewähren Sie dann nur dieses Verhalten an der Grenze, die dafür zuständig ist. Behalten Sie den Konsolenzugang, bevor Sie eine remote verwaltete Brücke ändern.
Die Konnektivität wiederherzustellen ist die eine Hälfte des Tests; die andere Hälfte ist zu bestätigen, dass ein Fluss, der blockiert bleiben soll, es weiterhin ist.
Halten Sie fest, welcher Eigentümer gefiltert hat, welche Kontrolle geändert wurde und welche zwei Flüsse Sie geprüft haben. Dieser Eintrag verhindert, dass der nächste Vorfall mit derselben Vermutung beginnt, pfSense ignoriere sich selbst.