Kein tun0? Entschlüsseltes IPsec in nftables mit meta ipsec abgleichen

Sie erwarten eine Tunnelschnittstelle, suchen sie und finden in der Firewall nichts zum Abgleichen. Das ist bei einem richtlinienbasierten Gateway normal: Der verschlüsselte Austausch kommt auf der physischen Schnittstelle an, und das entschlüsselte innere Paket, das anschließend weitergeleitet wird, wird ebenfalls so beobachtet, als käme es auf derselben Schnittstelle an. Es gibt kein tun0, weil nichts eines erzeugt hat.

Die innere Anfrage ist weiterhin ein eigenes Paket mit eigener Quelle, eigenem Ziel und eigenem Dienst, und der Kernel weiß, aus welcher Sicherheitsassoziation es stammt. Genau dieses Wissen kann eine Firewallregel abgleichen.

Zwei Pakete, eine Schnittstelle

Stellen Sie sich die eingehende Richtung vor. Ein ESP- oder UDP-gekapseltes Paket kommt an, der Kernel findet die passende Richtlinie, entschlüsselt es und übergibt das Klartextpaket an den Weiterleitungspfad. Eine Regel, die nur auf den Schnittstellennamen schaut, kann dieses Paket nicht von irgendeinem anderen Verkehr unterscheiden, der auf derselben Leitung ankommt.

Was es unterscheidet, ist der eingehende Sicherheitspfadkontext, der am Paket hängt. nftables legt ihn als meta ipsec exists offen, was wahr ist, wenn das Paket über einen IPsec-Sicherheitspfad ankam. Kombinieren Sie ihn mit dem Client-Pool, dem Ziel und dem Dienst, und die Regel wird spezifisch genug, um sicher zu sein.

Den Kontext wegzulassen ist der übliche Fehler, und es ist ein Sicherheitsfehler und kein kosmetischer. Eine Regel, die alles aus dem Client-Pool akzeptiert, akzeptiert ebenso bereitwillig ein gefälschtes Paket aus dem lokalen Netz, denn die Quelladresse ist für sich genommen kein Beweis für irgendetwas. Der Sicherheitspfadkontext ist der billigste Weg, die Quelle bedeutsam zu machen. Schreiben Sie die Regel von Anfang an damit, statt sie nach einem Audit zu ergänzen.

Schreiben Sie die Weiterleitungsregel

Nehmen Sie einen authentifizierten IPv4-Fernzugriffsdienst mit Clients in 10.90.0.0/24 und einem genehmigten Ziel unter 203.0.113.40 an. Ein Regelfragment für diesen Datenfluss sieht so aus.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Die Adressen und die Schnittstelle sind Beispiele zum Ersetzen. Setzen Sie das geprüfte Äquivalent in die Weiterleitungsrichtlinie vor die Regel, die den Datenfluss sonst verwerfen würde, und leeren Sie kein bestehendes Regelset, um es zu installieren; ein Gateway ist kein Reinraum-Experiment.

Der Ausdruck oifname ist es wert, beibehalten zu werden. Er dokumentiert die Ausgangsentscheidung und verhindert, dass die Regel in einer Richtung passt, die Sie nicht beabsichtigt haben, was bei einem Gateway mit mehreren Wegen ins Internet zählt. Auf einer Testbox mit einem einzigen Uplink wirkt der Ausdruck überflüssig, und genau deshalb wird er entfernt, bevor die Box einen zweiten Uplink bekommt.

Berechtigungen für den äußeren Austausch sind getrennt. Der Eingangspfad des Gateways braucht die IKE- und ESP- oder UDP-Kapselungsports, die er tatsächlich nutzt, und diese Berechtigungen erlauben nichts für das entschlüsselte Paket innen. Beides zu vermischen ist der Weg, auf dem ein funktionierender Tunnel bei einer Firewall landet, die alles weiterleitet.

Eingehender Kontext ist kein ausgehender Kontext

Dieselbe Ausdrucksfamilie deckt die andere Richtung mit rt ipsec ab, das die ausgehende Sicherheitsassoziation beschreibt, die ein Paket verwenden wird. Es beantwortet eine andere Frage: nicht, woher dieses Paket kam, sondern ob es auf seinem nächsten Abschnitt geschützt sein wird.

Dieser Unterschied zählt bei einem Gateway, das einen Tunnel beendet und zugleich in einen anderen weiterleitet. Ein Paket kann entschlüsselt ankommen und dennoch verschlüsselt abgehen müssen, und eine nur für den eingehenden Kontext geschriebene Akzeptanz sagt nichts über die ausgehende Anforderung aus. Wenn die Richtlinie diesen Schutz verlangt, sollte das Regelset ihn ausdrücken, statt anzunehmen, dass das Routing das schon erledigt.

Halten Sie die beiden Fragen in getrennten Regeln, damit ein Leser sieht, welche durchgesetzt wird. Eine einzige clevere Regel, die beides prüft, ist schwerer zu prüfen und viel schwerer zu debuggen, wenn eine ihrer Hälften nicht mehr passt. Zwei Regeln mit Zählern sagen Ihnen außerdem, welche Anforderung fehlschlägt, was eine kombinierte Regel nie leisten wird.

NAT ist keine Firewallentscheidung

Verkehr ins Internet aus einem privaten Client-Pool braucht normalerweise Quellübersetzung, damit die Antwort zurückfindet. Aber Verkehr, der für eine andere ausgehende IPsec-Richtlinie ausgewählt wurde, muss seine erforderliche Ausnahme behalten, und jede private Quelle zu maskieren, ohne an die nächste Schutzentscheidung zu denken, bricht das.

Eine Akzeptanz innerhalb einer NAT-Kette ist ebenso wenig eine allgemeine Erlaubnis. NAT und Filterung haben unterschiedliche Aufgaben, und eine NAT-Kette untersucht nicht jedes spätere Paket eines bestehenden Datenflusses, und genau deshalb erzeugt das Verlassen auf sie in Sicherheitsfragen Regeln, die im Test zu funktionieren scheinen und unter Last versagen.

Das Umgekehrte gilt auch und überrascht Leute: Eine Akzeptanz irgendwo in einer Filter-Basiskette hat kein Gewicht gegen ein späteres Verwerfen in einer anderen anwendbaren Kette. Reihenfolge und Kettenumfang entscheiden das Ergebnis, nicht das Vorhandensein einer Akzeptanz in der Datei.

Prüfen Sie den genauen inneren Dienst

Testen Sie das konkrete Ziel und den Port, den Sie genehmigt haben, von einem echten Client aus, und bestätigen Sie, dass die Antwort zurückkommt. Testen Sie dann etwas, das Sie nicht genehmigt haben, und prüfen Sie, dass es nicht durchgeht, denn eine zu breite Regel besteht den ersten Test ebenso gut wie eine korrekte. Eine Anfrage, die den Client nie verlässt, ist ebenfalls kein Firewall-Ergebnis, also lesen Sie die Zähler, um zu sehen, ob das Paket überhaupt bewertet wurde. Zwei Tests und eine Zählerablesung sagen Ihnen mehr als ein ganzer Nachmittag mit dem Lesen des Regelsets.

Die nftables-Referenz dokumentiert meta ipsec, rt ipsec und die richtungsspezifischen Ausdrücke, und dort prüfen Sie die Syntax gegen Ihre installierte Version. Und halten Sie den Umfang ausdrücklich fest: Dies ist ein IPv4-Beispiel, es sagt nichts über IPv6 aus, und es macht beliebige öffentliche Portweiterleitung nicht zu einem Teil des VPN-Dienstes.