Downstream-Clients hinter einem Upstream-VPN: Route oder NAT?

Ein Gateway betreibt WireGuard für deine eigenen Geräte und einen OpenVPN-Client zu einem fremden Netz. Die Weiterleitung zwischen den beiden inneren Schnittstellen funktioniert, und man kommt leicht zu dem Schluss, das Downstream-Subnetz sei nun Teil des Upstream-Dienstes. Ist es nicht. Eine vom Client gezogene Route sagt deinem Gateway, wohin es Anfragen senden soll; sie sagt nichts darüber, wie das entfernte Netz Verkehr an Geräte zurückgibt, von denen es nie gehört hat. Wähle ein Rückwegmodell, das der Upstream tatsächlich unterstützt, bevor du eine einzige Regel hinzufügst.

Entscheide dich für das Rückwegmodell, bevor du das Routing anfasst

In dieser Anleitung verwenden Downstream-Clients 10.90.0.0/24, die dem Gateway zugewiesene Upstream-Tunneladresse ist 10.80.0.6, und die freigegebene entfernte Ressource ist 172.20.0.30. Zwei Modelle passen zu dieser Form: die Downstream-Quelle erhalten und die Gegenseite dazu bringen, sie zu routen, oder die Quelle auf die eigene Tunneladresse des Gateways zu übersetzen. Alles nach dieser Entscheidung ist mechanisch, und die Entscheidung selbst braucht den Eigentümer des Dienstes. Die eine Zeile oben ist eine Routing-Vereinbarung mit der Gegenseite; die andere ist eine lokale Richtlinienänderung, die du allein vornehmen kannst. Die beiden zu verwechseln macht aus einer Änderung von zehn Minuten eine Verhandlung.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Wähle eine Zeile und bleib dabei. Die Zeilen sind Alternativen, keine Schritte, und ihre Vermischung ergibt ein Design, das bei der Prüfung niemand erklären kann.

Geroutete Quellerhaltung

Die Gegenseite empfängt eine Anfrage von einer Downstream-Adresse, braucht also eine unterstützte Route und Peer-Ownership für dieses Subnetz sowie die Berechtigung, sie anzunehmen. Das sind entfernte Einstellungen, und keine lokale Linux-Route erzeugt sie. Fordere sie ausdrücklich und schriftlich an, mit dem Präfix und dem Tunnel-Peer, der es tragen wird, und erwarte, dass die Antwort davon abhängt, ob der Dienst Site-to-Site-Vereinbarungen überhaupt unterstützt.

Lautet die Antwort ja, ist die lokale Konfiguration klein: Weiterleitung aktiviert, die allowed-ips des WireGuard-Peers, die den Downstream-Bereich abdecken, und eine Firewall-Richtlinie, die die Überquerung in beide Richtungen erlaubt.

Bewusste Quellübersetzung

Wenn der Dienst Verkehr nur an die verbundene Client-Adresse zurückgibt, übersetze die Quelle ausgehend auf diese Adresse und behalte den conntrack-Zustand, der sie für Antworten umkehrt. Beschränke die Regel auf die vorgesehenen Downstream-Quellen, die vorgesehenen entfernten Ziele und die Upstream-Schnittstelle. Eine Regel, die alles übersetzt, was jede Schnittstelle verlässt, ist eine viel größere Richtlinie als diese Anforderung, und sie wird dich später überraschen.

IPv6 braucht ein eigenes Design; eine IPv4-Masquerade-Zeile zu kopieren ist keine Architektur. Teste den übersetzten Pfad mit einer neuen Verbindung statt einer zwischengespeicherten.

Der lokale Datenpfad muss trotzdem funktionieren

Die Übersetzung beseitigt die lokale Arbeit nicht: Das Gateway braucht weiterhin eine Route zu Downstream-Zielen, die korrekte Quell-Ownership des WireGuard-Peers, aktivierte Weiterleitung und eine enge Firewall-Richtlinie zwischen den Schnittstellen. Eine Anfrage, die auf dem Gateway selbst entsteht, übt keine dieser Berechtigungen aus, weshalb Tests auf dem Gateway bestehen und Downstream-Geräte trotzdem scheitern.

Teste von einem echten Downstream-Gerät, nicht vom Gateway. Die Quelladresse ist der ganze Sinn der Übung.

Eine Quelle bedeutet eine Sitzungsidentität

Der entfernte Dienst sieht die authentifizierte Sitzung des Gateways und seine übersetzte Adresse, nicht eine unabhängige Authentifizierung für jedes Downstream-Gerät. Halte Berechtigungen pro Gerät und Anwendungsidentitäten explizit und bestätige mit dem Eigentümer des Dienstes, dass ein Gateway, das für mehrere Geräte handelt, überhaupt zulässig ist. Übersetzung ist kein Weg, eine Registrierungspflicht pro Gerät zu umgehen; verlangt der Dienst, dass sich jedes Gerät registriert, nutze dieses Modell oder verhandle eine Site-to-Site-Vereinbarung.

Schreibe diese Bestätigung im Runbook neben die Regel, denn die nächste Prüfung wird fragen, ob das Design genehmigt oder nur bequem war.

Definiere den getrennten Zustand und teste dann drei Anfragen

Entscheide, was passiert, wenn der Upstream-Tunnel ausfällt. Autorisierter entfernter Verkehr sollte nicht still einem gewöhnlichen WAN-Fallback folgen, wo das verboten ist, daher sollte die Firewall-Richtlinie, die die Überquerung erlaubt, auch geschlossen fehlschlagen. Teste dann drei Fälle von einem echten Downstream-Gerät: eine erlaubte Anfrage, die funktioniert, eine nicht erlaubte Anfrage, die scheitert, und ein Upstream-Ausfall, der die erlaubte stoppt.

Halte das Zurückrollen in einer Zeile pro Regel fest, damit die Änderung rückgängig gemacht werden kann, ohne die Absicht zu rekonstruieren.