TP-Link Omada als Standort mit WireGuard anbinden

Was ein Standort ist

Einen Omada-Router legen Sie als Standort an, nicht als Gerät. Der Unterschied ist nicht formal: Bei einem Standort tragen Sie das Netz dahinter ein — etwa 192.168.0.0/24 — und damit wird alles in diesem Netz erreichbar. Der Server, der Drucker, die Anlage im Keller. Ohne diese Angabe erreichen Sie nur den Router selbst.

Der Router braucht keine öffentliche IPv4-Adresse. Er ruft von sich aus hinaus; an DS-Lite- und Mobilfunkanschlüssen funktioniert das genauso.

Getestet mit dem ER605 im Omada-Controller. Der ER7206 und die übrigen Omada-Router bedienen sich gleich; einzelne Felder heißen je nach Fassung etwas anders.

Was Sie brauchen

Omada importiert keine .conf-Datei — Sie tragen die Werte von Hand ein. Vier Angaben brauchen Sie dafür, und die stehen alle im Kundenbereich unter Fernzugriff beim jeweiligen Kunden:

• Adresse im Tunnel — steht in der Tabelle bei der Gegenstelle
• Erreichbare Netze — die Zeile im Aufklapper bei der Gegenstelle
• Öffentlicher Schlüssel der Gegenstelle und Anschluss — unter „Angaben für Geräte, die von Hand eingerichtet werden“
• Gegenstelle: vermittlung.idodns.de

Einrichten

Die Reihenfolge ist nicht beliebig: Den Schlüssel erzeugt der Router, die Tunneladresse vergeben wir. Beides braucht die andere Seite — deshalb wird der Router zweimal angefasst.

1. Im Omada-Controller die WireGuard-Verbindung anlegen

   Konfiguration → VPN → WireGuard VPN → Erstellen. Lassen Sie Lokale IP-Adresse zunächst stehen, wie Omada sie vorschlägt — sie wird in Schritt 3 korrigiert. Setzen Sie den Abhörport auf 51820 und speichern Sie.

   Beim Speichern erzeugt der Router sein Schlüsselpaar und zeigt den öffentlichen Schlüssel an — 44 Zeichen. Den kopieren Sie jetzt. Der geheime Teil bleibt im Router und wird uns nie gezeigt.

2. Im Kundenbereich die Gegenstelle anlegen

   Fernzugriff → Kunde auswählen → Art: Standort → unter „Netz hinter diesem Standort“ das Büronetz eintragen, genau so, wie der Omada-Router es vergibt → den kopierten öffentlichen Schlüssel einfügen.

   Danach stehen in der Liste die beiden Angaben, die der Router noch braucht: die Adresse im Tunnel und die erreichbaren Netze.

   Der Schlüssel lässt sich später nicht ändern. Erzeugt der Router ihn neu — etwa nach einem Zurücksetzen —, legen Sie die Gegenstelle neu an; das dauert eine Minute.

3. Zurück im Omada: die Verbindung fertigstellen

   Lokale IP-Adresse

   „Adresse im Tunnel“ aus dem Kundenbereich, z. B. 10.80.7.2

   Lokale Netzwerke

   das Büronetz, ab Werk „Default“

   Jetzt wird der Vorschlag bei Lokale IP-Adresse überschrieben — mit der Adresse, die im Kundenbereich bei dieser Gegenstelle steht. Unter Lokale Netzwerke geben Sie das Netz frei, das der Router in den Tunnel reichen soll; nur was dort ausgewählt ist, wird erreichbar.

4. In derselben Verbindung die Gegenstelle (Peer) eintragen

   Öffentlicher Schlüssel

   der Schlüssel der Gegenstelle aus dem Kundenbereich

   Zugelassene Adressen

   die „Erreichbaren Netze“ aus dem Kundenbereich, z. B. 10.80.7.0/24, 10.80.9.0/24

   Endpunkt

   vermittlung.idodns.de:51820

   Erhaltungsintervall

   25

   Der öffentliche Schlüssel ist hier der unsere — nicht der, den der Router in Schritt 1 selbst erzeugt hat. Bei den zugelassenen Adressen steht das eigene Büronetz nicht dabei: Der Router sitzt darin und würde seinen eigenen Verkehr in den Tunnel schicken. Und ohne das Erhaltungsintervall bricht die Verbindung an Anschlüssen mit Adressumsetzung beim Anbieter nach kurzer Zeit ab.

   Nimmt Ihre Omada-Fassung im Feld Endpunkt nur eine IP-Adresse an, tragen Sie die Adresse ein, auf die vermittlung.idodns.de zeigt. Sie dürfen das gefahrlos tun: Diese Adresse ist fest und bleibt auch dann bestehen, wenn wir den Vermittlungsserver ersetzen.

5. Prüfen, dass die Verbindung steht

   Im Omada wird die Verbindung nach spätestens einer halben Minute grün. Im Kundenbereich wechselt die Gegenstelle im selben Takt auf „Verbunden“.

Namen und Zertifikate

Zu jedem Kundennetz gehören Namen für die Geräte im Netz und ein Zertifikat dazu, damit der Browser keine Warnung zeigt. Für den Omada-Router selbst gilt das nicht — und zwar aus einem Grund, der sich nicht umgehen lässt.

Ein Zertifikat wirkt nur, wenn das Gerät es auch benutzt. Ein Router, den der Omada-Controller übernommen hat, gibt seine Oberfläche an den Controller ab und bietet keine Stelle, an der sich eines einspielen ließe. Er zeigt weiter sein eigenes, selbst unterschriebenes — der Browser meldet ERR_CERT_AUTHORITY_INVALID. Das ist kein Fehler in Ihrem Aufbau, sondern eine Grenze von TP-Link.

Die Oberfläche rufen Sie ohnehin über den Controller auf, und der bringt sein eigenes gültiges Zertifikat mit. Ein Name für den Router bleibt trotzdem nützlich — nur eben ohne https://, etwa zum Anpingen.

Für alles hinter dem Router gilt das Übliche: NAS, Proxmox, Home Assistant, ein Server mit nginx — überall lassen sich die beiden Dateien hinterlegen, und dann ist der Browser still. Wollen Sie auch die Omada-Oberfläche unter Ihrem eigenen Namen ohne Warnung, führt der Weg über einen eigenen Controller im Kundennetz (Software-Controller oder OC200); der nimmt ein Zertifikat entgegen. Der Cloud-Controller von TP-Link nicht.

Wenn es nicht klappt

Wie es weitergeht

Sobald die Gegenstelle im Kundenbereich auf „Verbunden“ steht, ist das ganze Büronetz hinter dem Omada-Router erreichbar — vom Laptop aus per Datei, vom Telefon aus per QR-Code. Beides legen Sie als eigene Gegenstelle desselben Kunden an.

Für die Geräte hinter dem Router lohnt sich der Name mit Zertifikat: ein Windows-Server ohne Warnung im Remotedesktop, ein QNAP-NAS, das sein Zertifikat selbst abholt. Und wenn der Kunde lieber im Browser bedient werden will, ohne dass auf seinem Rechner etwas läuft: Fernwartung im Browser.