Quell-NAT verbirgt Client-Adressen vor einer späteren Firewall

Eine für Mitarbeiter- und Lab-Clients geschriebene Regel landet auf der neuen Edge-Firewall und passt still auf alles oder nichts. Die Ursache liegt weiter oben: Ein Gateway hat die Client-Adressen bereits umgeschrieben, sodass die Regel eine Transitadresse statt zweier Gruppen sieht. Ein zusätzliches Gerät stellt keine Information wieder her, die der Pfad entfernt hat. Finden Sie die letzte Stelle, an der die Unterscheidung noch existiert, bevor Sie die Richtlinie schreiben.

Warum die Edge-Regel eine einzige Adresse sieht

Many-to-one-Übersetzung ordnet jedes interne Adress- und Port-Tupel einer gemeinsamen externen Adresse mit zugewiesenem Port zu. Gespräche bleiben für den Übersetzer über diese Portbindungen unterscheidbar, doch ein nachgelagertes Gerät, das einen einfachen Quellpräfix-Abgleich durchführt, sieht nur die gemeinsame Adresse. Das genügt, um zwei Gruppen an der Regel identisch zu machen. Die Pakete kommen weiterhin an; die Gruppierung nicht.

Prüfen Sie, was die Schnittstelle der Firewall tatsächlich beobachtet, nicht was das Diagramm verspricht. Beides weicht öfter voneinander ab, als irgendjemand erwartet.

Die letzte durchsetzbare Identität finden

Beginnen Sie am Durchsetzungspunkt und gehen Sie rückwärts, bis das ursprüngliche Präfix erscheint. Zwei Befehle lokalisieren meist die Grenze.

iptables -t nat -L POSTROUTING -n -v
conntrack -L -s 10.90.0.2 | head

Die NAT-Tabelle zeigt, welcher Verkehr übersetzt wird und durch welche Regel, während die conntrack-Auflistung ursprüngliche und übersetzte Tupel für aktive Flows zeigt. Wo die vorgelagerte Firewall immer nur die übersetzte Adresse sieht, können gruppenbezogene Quellregeln dort nicht funktionieren, egal wie sie geschrieben sind. Gehen Sie den Pfad vorwärts oder rückwärts, bis Sie ein Gerät erreichen, auf dem die beiden Client-Präfixe unterscheidbar bleiben. Notieren Sie die Quelle bei jedem Hop, statt einem Innen- oder Außen-Label zu vertrauen.

Drei Platzierungen und was jede kostet

Die Richtlinie kann auf dem übersetzenden Gateway liegen, wo die ursprünglichen Quellen noch sichtbar sind. Sie kann auf der vorgelagerten Firewall liegen, wenn der Transit geroutet statt übersetzt wird, was Rückrouten und das Entfernen der Quellumsetzung bedeutet. Oder sie kann auf Identität statt auf Adressen durchgesetzt werden, über eine authentifizierte Kontrolle, die Benutzer oder Gerät kennt. Jede Wahl hat einen Eigentümer und einen Fehlermodus, und nur die ersten beiden halten die Regel rein auf Quelladressen bezogen.

Welche Sie auch wählen, dokumentieren Sie die Regel zusammen mit der Adresse, auf die sie passt. Eine Regel, deren Adressannahme sich still geändert hat, ist schlimmer als keine Regel, weil sie weiter auf Verkehr passt und dabei etwas völlig anderes schützt.

Abnahme: ein erlaubter und ein abgelehnter Client

Testen Sie mit einem Client-Paar, je einem aus jeder Gruppe, und erfassen Sie, wie jeder am Durchsetzungspunkt ankommt. Behalten Sie beide Tupel neben dem Regelergebnis, damit der Nachweis zeigt, dass die Unterscheidung überlebt hat, und nicht, dass eine weitere Firewall existiert. Wiederholen Sie den Test nach einer NAT- oder Routing-Änderung, denn die vorgelegte Adresse ist der Teil, der still bricht. Halten Sie Authentifizierung überall bereit, wo Menschen unterschieden werden müssen, da eine Quelladresse eine Richtlinieneingabe und kein Identitätsnachweis ist.

Schreiben Sie Durchsetzungspunkt, beobachtete Quelle und Regel ins Ticket. Sonst fügt der nächste Ingenieur eine zweite Firewall und dieselbe Regel hinzu.