Ein flexibles Router-/VPN-Backbone mit VyOS aufbauen, von Grund auf bis zur VPS-Edition

Warum VyOS

VyOS ist ein Open-Source-Netzwerkbetriebssystem auf Debian-Basis, das Enterprise-Routing, Firewalling und VPN-Funktionen auf handelsüblicher Hardware bietet. Es gibt Ihnen die Flexibilität, die klassische Hardware-Appliances oft einschränken, und erlaubt es, Ihren Router wie jede andere versionierte, reproduzierbare Komponente Ihrer Infrastruktur zu behandeln.

Was wir bauen

Ein komplettes Routing-System, das Folgendes umfasst:

Eine VyOS-Instanz zu Hause, selbst wenn sie hinter NAT oder CGNAT sitzt.
Eine VyOS-Instanz auf einem VPS mit echter öffentlicher IP.
Einen Tunnel zwischen beiden über WireGuard.
Mehrere interne Subnetze hinter dem Heimrouter.
Routing vom VPS zu allen internen Subnetzen.
Die Option, später auf dynamisches Routing zu erweitern.

Das Ergebnis ist ein stabiler, vorhersehbarer Pfad zwischen Ihrer Cloud-Umgebung und Ihrem Homelab, ohne auf unzuverlässiges Portforwarding angewiesen zu sein oder unnötige Angriffsflächen offenzulegen.

Adressierung und Design

Ein praktisches Design sieht so aus:

Interne Heimnetzwerke unter 10.42.0.0/16
Einzelne Subnetze wie 10.42.0.0/24 und 10.42.1.0/24
Ein Point-to-Point-WireGuard-Tunnel wie 172.24.32.0/31
Eine öffentliche IP auf dem VPS plus welches Gateway der Provider auch zuweist
Standardroute auf dem Heimrouter über das lokale WAN
Standardroute auf dem VPS über das Rechenzentrums-Gateway

Die Topologie ist bewusst einfach gehalten. Der Tunnel wird zum Backbone, und der VPS fungiert als von außen erreichbarer Kontrollpunkt.

Konfiguration des Heimrouters (VyOS hinter NAT)

set interfaces ethernet eth0 address '10.21.21.10/24'
set interfaces ethernet eth0 description 'WAN'

set interfaces ethernet eth1 address '10.42.0.1/24'
set interfaces ethernet eth1 description 'LAB1'

set interfaces ethernet eth2 address '10.42.1.1/24'
set interfaces ethernet eth2 description 'LAB2'

set nat source rule 10 description 'Outgoing NAT'
set nat source rule 10 outbound-interface 'eth0'
set nat source rule 10 source address '10.42.0.0/16'
set nat source rule 10 translation address 'masquerade'

set interfaces wireguard wg0 address '172.24.32.1/31'
set interfaces wireguard wg0 description 'home-to-vps'
set interfaces wireguard wg0 peer VPS allowed-ips '172.24.32.0/31,10.42.0.0/16'
set interfaces wireguard wg0 peer VPS persistent-keepalive '15'
set interfaces wireguard wg0 peer VPS port '8765'
set interfaces wireguard wg0 peer VPS pubkey '<VPS_PUBLIC_KEY>'
set interfaces wireguard wg0 private-key '<HOME_PRIVATE_KEY>'

set protocols static route 0.0.0.0/0 next-hop '10.21.21.1'

set system host-name 'vyos-home-edge'
set service ssh port '22'

commit
save

Konfiguration des VPS-Routers (VyOS mit öffentlicher IP)

set interfaces ethernet eth0 address '<VPS_PUBLIC_IP>/23'

set interfaces wireguard wg0 address '172.24.32.0/31'
set interfaces wireguard wg0 description 'vps-to-home'
set interfaces wireguard wg0 peer Home allowed-ips '172.24.32.0/31,10.42.0.0/16'
set interfaces wireguard wg0 peer Home pubkey '<HOME_PUBLIC_KEY>'
set interfaces wireguard wg0 port '8765'

set protocols static route 0.0.0.0/0 next-hop '<VPS_PROVIDER_GATEWAY>'

set system host-name 'vyos-vps'
set service ssh port '22'

commit
save

Sobald beide Seiten konfiguriert sind und der WireGuard-Handshake erfolgreich ist, haben Sie ein funktionierendes privates Backbone zwischen Ihrem Homelab und der Cloud.

WireGuard-Schlüssel mit den eingebauten PKI-Befehlen erzeugen

Sie können Schlüsselpaare direkt mit dem Befehl generate pki wireguard key-pair erstellen. Diese Methode liefert privaten und öffentlichen Schlüssel in einem Schritt und erspart Ihnen unnötiges manuelles Piping oder Zwischendateien, wie Sie sie bei etwas wie wg genkey bräuchten

Der Befehl lässt sich im operativen Modus ausführen.

generate pki wireguard key-pair

Eine typische Ausgabe sieht so aus:

Private key: 0NLc86fck3qtkBA133fh6K8sGckgQzHR2rBypr+LgHk=
Public key:  H6iVTlr44l6Z+DaGKD3aYr7QZXjG1rpdUYhbm2NjnQQ=

Sie fügen den privaten Schlüssel direkt in die Interface-Konfiguration ein.

set interfaces wireguard wg0 private-key '0NLc86fck3qtkBA133fh6K8sGckgQzHR2rBypr+LgHk='

Der öffentliche Schlüssel wird an den Peer-Router weitergegeben, und die Übertragung ist unbedenklich, da er keine sensiblen Informationen preisgibt.

DHCP-Serverkonfiguration für interne Subnetze

Im Vergleich zu älteren VyOS-Versionen bringt 1.5 ein deutlich überarbeitetes DHCP-Servicemodell mit, das sich von der alten ISC-DHCP-Implementierung löst und auf ein Kea-basiertes Backend umstellt. Die Konfigurationsstruktur ist übersichtlicher und erlaubt Optionen pro Subnetz ohne unnötige Wiederholung. Bedient Ihr Heimrouter mehrere interne Netzwerke, kann jedes VLAN oder jede physische Schnittstelle einen eigenen DHCP-Pool mit unabhängigen Lease-Bereichen, DNS-Einstellungen und Gateway-Zuweisungen betreiben.

Das folgende Beispiel legt DHCP-Pools für zwei interne Netzwerke an, 10.42.0.0/24 und 10.42.1.0/24, passend zur vorherigen Topologie. Jeder Pool definiert das Standardgateway, DNS-Server und einen dynamischen Adressbereich. VyOS bindet einen DHCP-Pool automatisch an die Schnittstelle, die das passende Netzwerk enthält.

# Enable the DHCP service
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 default-router '10.42.0.1'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 dns-server '10.42.0.1'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 lease '86400'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 range 1 start '10.42.0.100'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 range 1 stop '10.42.0.200'

set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 default-router '10.42.1.1'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 dns-server '10.42.1.1'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 lease '86400'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 range 1 start '10.42.1.100'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 range 1 stop '10.42.1.200'

commit
save

Wenn Sie zusätzliche DHCP-Optionen wie NTP-Server, PXE-Boot-Parameter oder Domain-Search-Listen benötigen, erlaubt VyOS 1.5 diese auf Subnetzebene. Zum Beispiel:

set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 ntp-server '10.42.0.1'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 domain-name 'lab.internal'

Ebenso lassen sich statische Reservierungen konfigurieren, sodass bestimmte MAC-Adressen deterministische IP-Zuweisungen erhalten. Das ist nützlich für Server, Hypervisoren oder eingebettete Geräte, die eine konsistente Adressierung benötigen.

set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 static-mapping web01 ip-address '10.42.0.10'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 static-mapping web01 mac-address 'aa:bb:cc:dd:ee:ff'

VyOS konfiguriert Kea beim Commit automatisch neu, und Leases werden in den üblichen Statusdateien unter /run/kea erfasst. Für größere Netzwerke können Sie Kea an ein Datenbank-Backend anbinden, doch für die meisten Heim- oder Laborumgebungen reicht die eingebaute Konfiguration aus und ist zuverlässig.

Dynamisches Routing zwischen Zuhause und VPS

Statische Routen funktionieren gut für kleine oder feste Netzwerke, werden aber mit wachsender Umgebung zur Wartungslast. Wenn Sie vorhaben, weitere Subnetze, zusätzliche Tunnelendpunkte oder Multi-Site-Konnektivität einzuführen, lässt dynamisches Routing Router automatisch Erreichbarkeitsinformationen austauschen. VyOS 1.5 unterstützt mehrere dynamische Routing-Protokolle mit FRR als Backend. In dieser Topologie sind BGP und OSPF die beiden relevantesten Optionen.

Dynamisches Routing ersetzt weder Ihren WireGuard-Tunnel noch die Point-to-Point-Adressierung. Es automatisiert lediglich, was Sie zuvor manuell definiert haben. Der Tunnel trägt weiterhin den Traffic, aber Präfixe werden nun gelernt statt statisch konfiguriert.

BGP für den Präfix-Austausch nutzen

BGP eignet sich gut für Situationen, in denen Sie mehrere Routing-Domänen kontrollieren oder Netzwerke über geografisch getrennte Standorte verteilt sind. Ein Heimrouter, der Lab-Subnetze bei einem VPS-Router bekannt macht, passt sauber in dieses Modell. BGP ist zudem transportunabhängig, sodass der Betrieb über WireGuard problemlos funktioniert.

Das folgende Beispiel verwendet private autonome Systemnummern. Jeder Router nutzt ein Loopback als BGP-Router-ID. Der Heimrouter originiert die internen Subnetze unter 10.42.0.0/16, und der VPS lernt diese automatisch.

Konfiguration des Heimrouters

set interfaces loopback lo address '10.255.255.1/32'

set protocols bgp 65010 neighbor 172.24.32.0 remote-as '65020'
set protocols bgp 65010 neighbor 172.24.32.0 update-source 'wg0'

set protocols bgp 65010 network '10.42.0.0/24'
set protocols bgp 65010 network '10.42.1.0/24'

set protocols bgp 65010 parameters router-id '10.255.255.1'

commit
save

Konfiguration des VPS-Routers

set interfaces loopback lo address '10.255.255.2/32'

set protocols bgp 65020 neighbor 172.24.32.1 remote-as '65010'
set protocols bgp 65020 neighbor 172.24.32.1 update-source 'wg0'

set protocols bgp 65020 parameters router-id '10.255.255.2'

commit
save

Nach dem Commit trägt jeder Router gelernte Präfixe in seine Routing-Tabelle ein. Jedes neue Subnetz auf der Heimseite lässt sich einfach bekannt machen, indem Sie eine weitere network-Anweisung in BGP hinzufügen, ohne die VPS-Konfiguration anzufassen.

Routenfilterung und künftige Erweiterung

Auch in privaten Routing-Domänen ist es gute Praxis, zu kontrollieren, welche Präfixe ausgetauscht werden. VyOS unterstützt Route Maps, Prefix Lists und Communities zum Filtern oder Markieren von Routen. Für eine Topologie mit zwei Standorten ist Filterung optional, doch sobald weitere Router oder Zwischen-Hops hinzukommen, sorgen diese Werkzeuge für Stabilität und Kontrolle.

Prefix Lists können beispielsweise verhindern, dass interne Bereiche, die Sie nicht über den Tunnel offenlegen möchten, versehentlich bekannt gemacht werden.

OSPF für einfachere Umgebungen mit mehreren Subnetzen nutzen

Nehmen beide Router an einer einzigen gemeinsamen Routing-Domäne teil und wünschen Sie automatische Neighbor Discovery, ist OSPF die einfachere Alternative. OSPF verlangt, dass Schnittstellen auf Layer 3 erreichbar sind, was beim WireGuard-Link-Netzwerk der Fall ist. OSPF eignet sich gut für Laborumgebungen, in denen Einfachheit wichtiger ist als eine strikte Routing-Policy.

OSPF-Konfiguration des Heimrouters

set protocols ospf parameters router-id '10.255.255.1'

set protocols ospf area 0 network '172.24.32.0/31'
set protocols ospf area 0 network '10.42.0.0/24'
set protocols ospf area 0 network '10.42.1.0/24'

commit
save

OSPF-Konfiguration des VPS-Routers

set protocols ospf parameters router-id '10.255.255.2'

set protocols ospf area 0 network '172.24.32.0/31'

commit
save

OSPF entdeckt Nachbarn über den WireGuard-Link und tauscht LSAs aus, die jedes interne Subnetz beschreiben. Jedes neue Netzwerk am Heimrouter wird integriert, indem Sie es einfach der OSPF-Area-Konfiguration hinzufügen.

Entscheidung zwischen BGP und OSPF

Beide Protokolle ermöglichen dynamisches Routing, lösen aber leicht unterschiedliche betriebliche Anforderungen.

BGP bietet präzise Kontrolle darüber, was Sie bekannt machen und akzeptieren, was wichtig wird, sobald das Netzwerk über zwei Standorte hinauswächst.
OSPF bietet unkompliziertes Link-State-Routing innerhalb einer gemeinsamen Domäne und benötigt oft weniger Erstkonfiguration.
BGP ist vorzuziehen, wenn Ihr VPS als zentraler Aggregationspunkt für mehrere entfernte Standorte fungiert.
OSPF ist ideal, wenn Sie automatische Erkennung mit minimalem Policy-Aufwand wollen.

Diese Optionen bleiben mit der zugrunde liegenden WireGuard-Topologie kompatibel, und beide Ansätze machen statische Routen pro Subnetz auf dem VPS überflüssig. Falls gewünscht, kann ich Beispiele für Route Maps, Prefix Lists oder den gleichzeitigen Betrieb beider Protokolle in segmentierten VRFs ergänzen.

Statisches Routing, der einfache Ansatz

Wenn Sie Vorhersehbarkeit bevorzugen und keine häufigen Änderungen an internen Subnetzen erwarten, sind statische Routen die einfachste Methode.

set protocols static route 10.42.0.0/24 next-hop 172.24.32.1
set protocols static route 10.42.1.0/24 next-hop 172.24.32.1
commit
save

Damit weiß der VPS, wohin der Traffic für jedes interne Netzwerk geschickt werden muss.

Dynamisches Routing für größere Topologien

Wenn Sie vorhaben, mehrere Router hinzuzufügen oder die Architektur zu skalieren, wird dynamisches Routing wie BGP nützlich. VyOS kann Subnetze von Ihrem Heimrouter bis zum VPS bekannt machen und macht manuelle Route-Ergänzungen überflüssig. Für das einfache Setup ist das nicht erforderlich, wird aber wertvoll, sobald Ihre Topologie wächst.

Warum diese Architektur gut funktioniert

Dieses Modell bietet mehrere Vorteile:

Es umgeht CGNAT und unzuverlässiges Portforwarding durch einen stabilen Tunnel.
Der gesamte ausgehende Traffic kann optional über den VPS laufen, wodurch sich Filterung oder Monitoring zentralisieren lässt.
Es unterstützt sauber mehrere isolierte Heimsubnetze.
VyOS gibt Ihnen volle Kontrolle, ohne Sie an proprietäre Hardware zu binden.
Sie können in dynamisches Routing, VRRP, zusätzliche VPN-Endpunkte oder Multi-Site-Konnektivität hineinwachsen, ohne die Grundlage neu zu entwerfen.

Zu beachtende Einschränkungen

Statische Routen müssen manuell aktualisiert werden, sobald neue Subnetze hinzukommen.
WireGuard funktioniert in diesem Muster am besten, wenn Verbindungen von der Heimseite ausgehen, da der VPS einen festen öffentlichen Endpunkt hat.
Die Sicherheit ist in dieser Anleitung bewusst minimal gehalten. In der Produktion sollten Sie Firewall-Richtlinien hinzufügen, den Verwaltungszugriff einschränken und Dienste auditieren.
Private Netzwerke durchqueren nie das öffentliche Internet, daher muss der Tunnel für funktionierendes Routing immer aktiv sein.

Mögliche nächste Schritte

Sie können dieses Tutorial zu einem vollständigeren Infrastruktur-Rückgrat ausbauen. Naheliegende Erweiterungen sind unter anderem:

BGP für die automatische Subnetz-Bekanntmachung einführen.
Firewall-Gruppen, richtlinienbasiertes Routing und Segmentierung hinzufügen.
Unterstützung für „Road Warrior“-WireGuard-Clients, was eine Mesh-VPN-Steuerungsebene erheblich erleichtert.
Cloud init nutzen, um VyOS-Images programmatisch auszurollen.
Redundanz mit VRRP hinzufügen.

Fazit

Durch die Kombination von VyOS auf einem Heimrouter mit VyOS auf einem öffentlichen VPS und deren Verbindung über einen Tunnel erhalten Sie ein flexibles Backbone, das unabhängig von NAT, ISP-Einschränkungen oder Laborkomplexität funktioniert. Dieses Muster skaliert, lässt sich leicht automatisieren und gibt Ihnen volle Kontrolle darüber, wie Ihre internen und externen Netzwerke kommunizieren.