WireGuard: zwei halbe Routen gegen 0.0.0.0/0 in wg-quick

Zwei /1-Präfixe decken genau dieselben IPv4-Adressen ab wie ein einziges /0, und diese Gleichheit gilt nur innerhalb der Liste erlaubter Präfixe des Peers. Sie endet in dem Moment, in dem das Einrichtungswerkzeug entscheidet, wie geroutet wird, denn Linux wg-quick behandelt ein Standardpräfix als Sonderfall und nicht als Arithmetik. Der Sonderzweig installiert eine eigene Tabelle, zwei Policy-Regeln, eine Socket-Mark und Einstellungen für den Rückweg, die ein Paar halber Routen nie erhält. Wenn ein Proxy oder ein Browser nach der Änderung nicht mehr funktioniert, sind die Präfixe also der uninteressanteste Teil der Änderung.

Die Präfixliste ist nicht die ganze Konfiguration

AllowedIPs erledigt zwei Aufgaben gleichzeitig, und nur eine davon betrifft die Abdeckung. Für WireGuard selbst ist die Liste Kryptoschlüssel-Routing: Sie entscheidet, welche Ziele zu einem Peer verschlüsselt werden und welche Quelladressen dieser Peer verwenden darf. Für wg-quick dient dieselbe Liste zugleich als Routenspezifikation, und die erzeugte Route hängt davon ab, welchen Zweig die Liste zufällig trifft. Identische Abdeckung bei zwei verschiedenen Listenformen sagt daher nichts über einen identischen Hostzustand aus.

Die Standardkonfiguration nimmt Ihnen diese Entscheidung ab, denn Table ist standardmäßig automatisch, und das Werkzeug wählt aus, wo die Routen landen. Ein anderer Netzwerkmanager, ein Distributions-Wrapper oder ein eigener Table-Wert ändert das Ergebnis erneut, weshalb ein für einen Host geschriebener Ratschlag beim nächsten falsch aussehen kann.

Was der Standardzweig über eine Route hinaus hinzufügt

Ein Eintrag /0 schickt wg-quick in seinen Standardrouten-Pfad: Eine separate Routing-Tabelle erhält die Default-Route, eine Policy-Regel leitet unmarkierten Verkehr dorthin, eine zweite Regel hält spezifischere Routen der Haupttabelle autoritativ, und die Schnittstelle erhält eine Firewall-Mark auf ihrem eigenen Socket. Diese Mark ist der Schleifenschutz. Die verschlüsselten Datagramme, die den Tunnelverkehr tragen, verlassen den Host mit gesetzter Mark, damit die Regel, die alles andere in den Tunnel lenkt, nicht die eigenen Transportpakete des Tunnels verschluckt.

Ein Paar von Einträgen /1 nimmt stattdessen den gewöhnlichen Routenpfad. Zwei Routen landen in der konfigurierten Tabelle, und nichts der umgebenden Maschinerie erscheint, nicht weil sie unnötig wäre, sondern weil dieser Codepfad nie betreten wurde.

Wo die beiden Anordnungen auseinanderlaufen

Die Abweichung zeigt sich zuerst als Rekursion. Liegen die halben Routen in der Haupttabelle, fällt die eigene Transportadresse des Peers in ein Tunnelpräfix, sodass das Paket, das den Tunnel tragen soll, auf eine Route trifft, die in den Tunnel zeigt. Etwas muss es ausnehmen: eine Host-Route für den aktuellen Endpunkt, eine von Hand gesetzte Mark oder eine schnittstellenspezifische Regel. Eine Host-Route funktioniert, bis sich die Endpunktadresse ändert, was bei DNS-basierten Endpunkten, Roaming-Clients und Konfigurationen mit mehreren Peers passiert.

Zweitens ändert alles, was über Marks nachdenkt, sein Verhalten. Ein transparenter Proxy, der Verbindungen lokal umleitet, erzeugt neue Sockets, deren Marks und Quellen sich vom ursprünglichen Client-Flow unterscheiden, und die vom Standardzweig erzeugten Policy-Regeln waren Teil dessen, was diese Flows sortierte. Die eigene ausgehende Verbindung des Proxys zu lesen ist eine andere Übung, als zu testen, ob das ursprüngliche Ziel erreichbar ist.

Lesen Sie Regeln und Marks, bevor Sie ändern

Erfassen Sie den aktuellen Zustand, solange der Tunnel gesund ist, dann erneut nach der Änderung, und vergleichen Sie die beiden Ausgaben, statt aus der Konfigurationsdatei zu schließen. Nehmen Sie die Policy-Regeln, jede Tabelle, die Mark der Schnittstelle und die erfassten Endpunkte auf.

ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints

Wenn die erste Ausgabezeile die Regel für unmarkierten Verkehr verloren hat und die eigene Tabelle leer ist, läuft der Standardzweig nicht, und keine Präfix-Arithmetik stellt seine Wirkungen wieder her. Eine Mark von null auf einer Schnittstelle, die zuvor eine trug, ist dasselbe Signal, sichtbar in einem einzigen Wert.

Üben Sie den Tunnelverlust, bevor Sie ausliefern

Wenn das Halbrouten-Layout die bewusste Wahl ist, muss es die fehlenden Teile ausdrücklich liefern: einen Endpunktpfad, der Adressänderungen übersteht, das beabsichtigte Verhalten beim Ausfall des Tunnels und die entsprechende Behandlung für IPv6. Schreiben Sie das als Anforderungen auf, statt es während einer Störung zu entdecken. Üben Sie dann den Ausfall, denn ein voller Tunnel, der still auf den physischen Uplink zurückfällt, ist schlimmer als einer, der aufhört zu funktionieren.

sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1

Die Routensuche sollte den Endpunkt über die physische Schnittstelle auflösen, ohne den Tunnel zu durchqueren, und das Herunterfahren der Schnittstelle sollte den Host in dem Zustand hinterlassen, den das Design versprochen hat. Ein Proxy, der nach dem Austausch funktioniert, beweist, dass der erzeugte Hostzustand wichtig war; er beweist nicht, dass Schleifenvermeidung und Verhalten im heruntergefahrenen Zustand die Änderung überlebt haben.