Warum eine OpenVPN-Client-Blockregel nie die FORWARD-Kette trifft

Zwei Clients auf demselben OpenVPN-Server können sich erreichen, obwohl du eine DROP-Regel für ihren Pool hinzugefügt hast. Die Regel steht in der FORWARD-Kette, der Verkehr fließt offensichtlich, und der Zähler dieser Regel bleibt bei null. Die naheliegende Schlussfolgerung ist, dass die Firewall kaputt ist. Häufiger hat das Paket die Kette überhaupt nie betreten.

Es gibt zwei Wege, die ein Peer-Paket durch einen OpenVPN-Server nehmen kann, und sie werden von der Konfiguration bestimmt, nicht von der Firewall. Zu wissen, welcher Weg benutzt wird, sagt dir, ob eine Host-Regel überhaupt am richtigen Ort steht.

Zwei Wege, die ein Peer-Paket nehmen kann

Ist die Option für internes Weiterleiten deaktiviert, kommt ein Paket von Client A an der Tunnelschnittstelle an, dessen Ziel innerhalb der zugewiesenen Adresse von Client B liegt. Die Routentabelle des Servers schickt es über dieselbe Tunnelschnittstelle wieder hinaus, weil der Server die Route zur Adresse von B besitzt. Das ist ein Hin-und-zurück-Fluss durch den Host, und der IPv4-Weiterleitungspfad bewertet ihn.

Ist die Option für internes Weiterleiten aktiviert, ordnet der Serverprozess das Paket einem verbundenen Client zu und schreibt es direkt an diesen Client zurück. Das Paket wird im Daemon behandelt und gelangt nie wieder in das Tunnelgerät, sodass der Weiterleitungspfad des Hosts vollständig übersprungen wird. Das Handbuch zu OpenVPN 2.6 beschreibt diese Option als internes Client-zu-Client-Weiterleiten, und genau deshalb kann eine Firewall-Regel auf dem Host sie nicht sehen.

Eine dritte Variante gibt es in Installationen, die den Datenkanal an ein Kernelmodul auslagern. Die Weiterleitungsentscheidung und die Verschlüsselung verlassen den Userspace, und ob netfilter den Fluss sieht, hängt davon ab, wie der Auslagerungspfad gebaut ist. Nimm niemals an, dass sich ein altes Regelset auf einem ausgelagerten Server genauso verhält wie auf einem im Userspace. Bestätige den Modus aus der laufenden Konfiguration, nicht aus der Paketversion.

Wenn der Zähler sich nie bewegt

Ein Nullzähler bedeutet, dass das Paket diese Regel an dieser Stelle nicht getroffen hat, und dafür gibt es mehrere Gründe. Der erste ist die obige Umgehung: Der Verkehr hat die Kette nie erreicht. Der zweite ist eine Abweichung bei Schnittstelle, Richtung, Quelle oder Ziel, was häufig vorkommt, wenn der Pool umnummeriert wurde und die Regel noch das alte Präfix nennt.

Der dritte ist die Position. Eine Regel weiter oben in der Kette kann den Fluss annehmen, bevor dein DROP bewertet wird, und eine Regel weiter unten kann diejenige sein, die das Ergebnis tatsächlich entscheidet. Lies die Kette der Reihe nach mit sichtbaren Zählern und prüfe dann, welcher Zähler steigt, wenn du den Test wiederholst.

Führe einen kontrollierten Austausch zwischen zwei Clients durch, deren echte Adressen du aus dem Zustand des Servers selbst bestätigt hast, nicht aus einem Lease, an den du dich erinnerst. Bewegt sich der relevante Zähler weiterhin nicht, verdächtige den Pfad, bevor du die Übereinstimmung umschreibst. Bewegt er sich, aber die Verbindung gelingt weiterhin, wird der Drop später überstimmt, und die Reihenfolge ist das Problem. Diese Antwort entscheidet, ob die Reparatur eine Regeländerung oder eine Topologieänderung ist, also hole sie dir, bevor du irgendetwas bearbeitest.

Eine Grenze wählen, die filtern kann

Muss die Richtlinie in der Host-Firewall leben, bring den Verkehr dorthin, wo die Firewall ihn sehen kann. Internes Weiterleiten zu deaktivieren ist der unterstützte Weg, Peer-Verkehr durch die Tunnelschnittstelle und den Weiterleitungspfad zu zwingen, zum Preis, dass jedes Peer-Paket durch den Host-Stack geht.

Dann triff den Fluss präzise. Verkehr kommt an der Tunnelschnittstelle an und verlässt sie in beide Richtungen, sodass Regeln, die nur die physische Schnittstelle betrachten, nicht passen. Adressbasierte Regeln brauchen den aktuellen Pool, und sie müssen die Rückrichtung ebenso berücksichtigen wie die Hinrichtung.

Vielen Installationen ist besser gedient, wenn auf Client- oder Gruppenebene gefiltert wird, wo die Identität bekannt ist und die Richtlinie dem Nutzer folgt statt einer Adresse, die sich bei jeder Neuverbindung ändert. Das ist ein anderer Mechanismus als eine Host-Kette, und beide sollten ohne klaren Grund nicht vermischt werden.

Übertrage ein Regelset einer alten Topologie nicht unverändert über eine Migration. Adresspools, Schnittstellennamen und Weiterleitungsmodi beeinflussen alle, ob eine Regel passt, und eine kopierte Regel, die früher funktionierte, ist die irreführendste Art von Beweis. Beginne mit dem Fluss, den du zulassen willst, und schreibe die Regel, die dazu passt.

Isolation testen statt einer Regel zu vertrauen

Teste den verbotenen Fall und den erlaubten Fall im selben Lauf. Starte eine neue Verbindung von einem Client zum anderen und bestätige, dass sie fehlschlägt, und bestätige dann, dass eine Verbindung, die erlaubt sein sollte, weiterhin funktioniert. Wird nur das Erste getestet, sieht eine Firewall, die alles blockiert, wie ein Erfolg aus.

Wiederhole das nach dem Neuladen der Serverkonfiguration und nachdem ein Client sich neu verbunden hat, denn internes Weiterleiten und Poolzuweisungen sind Laufzeitzustand. Prüfe die Zähler in beide Richtungen, da eine Regel, die eine Richtung trifft und nicht die Antwort, teilweise Isolation erzeugt, die in einem schnellen Test schwer zu bemerken ist.

Isolation ist das beobachtete Ergebnis an der Grenze, die den Fluss tatsächlich trägt. Eine DROP-Regel irgendwo im Host ist kein Beweis; eine fehlgeschlagene Verbindung plus ein bewegter Zähler an der Regel, die sie verursacht hat, ist einer.