DNS-gespeistes nftables-Set zu WireGuard: Wie die Übergabe funktioniert
Eine DNS-Antwort kann ein nftables-Set speisen, aber ein Set routet nichts. Verfolgen Sie die vier Übergaben und die drei Lebensdauern, die entscheiden, ob die Lenkung funktioniert.
Namen werden zu Adressen aufgelöst, und diese Adressen können in einem Firewall-Set landen, das später das Routing beeinflusst, was namensbasierte Lenkung ohne Proxy möglich macht. Der Haken ist, dass vier Komponenten korrekt übergeben müssen: der Resolver, das Set, der Klassifizierer, der einen neuen Flow markiert, und der Peer, der ihn trägt. Jede Übergabe scheitert anders, und jede hält ihre eigene Zeit.
Behandeln Sie das Design als Kette statt als Konfiguration. Die Frage bei jedem Schritt ist, welche Komponente die Entscheidung besitzt und was passiert, wenn ihre Eingabe fehlt.
Was die DNS-Antwort kann und was nicht
dnsmasq kann Adressen aus Antworten in ein nftables-Set kopieren, was eine Speisung und keine Routingentscheidung ist. Diese Option, dokumentiert im dnsmasq-Handbuch, nennt Familie, Tabelle und Set, und ihre führende 4# wählt nur A-Einträge, weshalb v6-Ziele eine eigene Regelung brauchen. Das Set muss bereits existieren, weil der Resolver Elemente zu etwas hinzufügt, das der Firewall-Eigentümer angelegt hat. Nichts in diesem Schritt wählt eine Schnittstelle, eine Tabelle oder einen Peer.
Der Client muss diesen Resolver auch für den Namen verwenden. Eine Anwendung mit eigenem verschlüsseltem DNS oder eine zwischengespeicherte Antwort von vor der Richtlinie verbindet sich, ohne überhaupt einen Eintrag im Set zu erzeugen.
Das Set ist eine Eingabe, keine Route
Ein Element in einem Set ist eine Übereinstimmungsbedingung. Etwas muss es ansehen, entscheiden, dass dieses Paket einen neuen Flow beginnt, und die Richtlinie anwenden, die den Flow durch den Tunnel schickt. Unter Linux bedeutet das normalerweise einen routingfähigen Ausgabepfad, der eine Markierung setzen kann, eine Regel, die markierte Pakete in eine eigene Tabelle schickt, und eine Route in dieser Tabelle, die auf das WireGuard-Gerät zeigt. Die bloße Mitgliedschaft installiert nichts davon.
nft add set inet vpn_select office_v4 { type ipv4_addr\; }
ip rule add fwmark 0x40 table 200
ip route add default dev wg0 table 200
wg show wg0 allowed-ips
Der Peer wendet eine zweite Abdeckungsprüfung an, die oft vergessen wird. WireGuard verschlüsselt ein Paket nur für einen Peer, dessen erlaubte Adressen das Ziel enthalten, daher reicht eine Richtlinienroute in die Schnittstelle nicht, wenn die Liste des Peers dieses Präfix ausschließt. Halten Sie die Liste unter der Kontrolle des Routing-Eigentümers, statt sich darauf zu verlassen, welche Routen der Manager zufällig anlegt.
Markierungen, Tabellen und Peer-Abdeckung
Markierungen sind ein gemeinsamer Namensraum, also müssen Wert und Maske mit allem anderen abgestimmt werden, das sie nutzt. Eine Regel, die markierten Verkehr in eine eigene Tabelle schickt, braucht ein definiertes Ergebnis, wenn diese Tabelle keine passende Route hat, denn eine unbeantwortete Suche kann zur nächsten Regel weiterlaufen und das Paket über die physische Schnittstelle hinausschicken. Eine Blackhole-Standardroute innerhalb der eigenen Tabelle verwandelt diese stille Flucht in einen sichtbaren Verlust. Was das Design weiterhin nicht kann, ist das Schließen bei Ausfall für ein Ziel, das nie ins Set gelangt ist.
Die eigenen Außenpakete des Tunnels müssen dem Klassifizierer entkommen. WireGuard-Werkzeuge bieten genau dafür eine Socket-Markierung, und ihre Verwendung verhindert, dass die Kapselung zurück in die Schnittstelle geroutet wird, die sie aufbaut.
Testen Sie jede Lebensdauer einzeln
Drei Speicher altern nach drei Zeitplänen: der Resolver-Cache, die Set-Elemente und die verfolgte Verbindung. Testen Sie sie in dieser Reihenfolge und beobachten Sie, ob sich jeder bewegt, wenn er soll. Die folgenden Befehle lesen Resolver, Set, Verbindungstabelle und Richtlinienregeln, ohne etwas zu ändern.
dig +short office.example
nft list set inet vpn_select office_v4
conntrack -L -d 10.60.8.15
ip rule show
Eine frische Abfrage, die ein Element hinzufügt, beweist, dass die Speisung funktioniert, während ein veraltetes Element, das seine Antwort überlebt, eine Lebensdauer-Abweichung ist, die festgehalten werden sollte. Eine neue Verbindung in der Verbindungstabelle mit der erwarteten Markierung zeigt, dass der Klassifizierer lief, und eine alte Verbindung, die ihre ursprüngliche Markierung behält, ist korrektes Verhalten und kein Fehler. Die Regelliste beantwortet, ob die Richtliniensuche überhaupt existiert, was eine andere Frage ist als die, ob sie gepasst hat. Lesen Sie die vier Ausgaben in dieser Reihenfolge, und die fehlerhafte Übergabe verrät sich selbst.
Wo die Anforderung lautet, dass ein bestimmter Name immer einen Pfad nutzt, kann ein DNS-gespeistes Set das nicht beweisen, weil geteilte Adressen auch andere Namen tragen. Ein Proxy oder ein Mechanismus auf Anwendungsebene ist das Werkzeug für diese Garantie.