Skip to main content

Verwenden von WireGuard zum Erstellen einer Netzwerküberlagerung

Sie können ein Überlagerungsnetzwerk zwischen Ihrem Runner und einem Dienst in Ihrem privaten Netzwerk erstellen.

Verwenden von WireGuard zum Erstellen einer Netzwerküberlagerung

Wenn du keine separate Infrastruktur für ein API-Gateway verwalten möchtest, kannst du ein Überlagerungsnetzwerk zwischen deinem Runner und einem Dienst in deinem privaten Netzwerk erstellen, indem du WireGuard an beiden Stellen ausführst.

Dieser Ansatz bringt verschiedene Nachteile mit sich:

  • Um das auf Ihrem privaten Dienst ausgeführte WireGuard zu erreichen, benötigen Sie eine bekannte IP-Adresse und einen Port, auf die Ihr Workflow verweisen kann: Das können entweder eine öffentliche IP-Adresse und ein Port sein, eine Portzuordnung auf einem Netzwerkgateway oder ein Dienst, der DNS dynamisch aktualisiert.
  • WireGuard führt das NAT-Traversal nicht standardmäßig aus, sodass Sie einen Weg finden müssen, diesen Dienst bereitzustellen.
  • Es handelt sich um eine 1:1-Verbindung. Wenn Sie Hochverfügbarkeit oder hohen Durchsatz benötigen, müssen Sie dies also auf WireGuard aufbauen.
  • Sie müssen sowohl für den Runner als auch für Ihren privaten Dienst Schlüssel generieren und sicher speichern. WireGuard verwendet UDP, sodass Ihr Netzwerk UDP-Datenverkehr unterstützen muss.

Es gibt auch einige Vorteile, da Sie WireGuard auf einem vorhandenen Server ausführen können, sodass Sie keine separate Infrastruktur verwalten müssen, und die Unterstützung durch Runner, die von GitHub gehostet werden, ist gut.

Beispiel: Konfigurieren von WireGuard

In diesem Beispielworkflow wird WireGuard so konfiguriert, dass eine Verbindung mit einem privaten Dienst hergestellt wird.

In diesem Beispiel weist die im privaten Netzwerk ausgeführte WireGuard-Instanz diese Konfiguration auf:

  • Überlagerungsnetzwerk-IP-Adresse 192.168.1.1
  • Öffentliche IP-Adresse und Port 1.2.3.4:56789
  • Öffentlicher Schlüssel examplepubkey1234...

Die WireGuard-Instanz im GitHub Actions-Runner weist diese Konfiguration auf:

  • Überlagerungsnetzwerk-IP-Adresse 192.168.1.2
  • Der private Schlüssel wird als GitHub Actions-Geheimnis unter WIREGUARD_PRIVATE_KEY gespeichert.
name: WireGuard example

on:
  workflow_dispatch:

jobs:
  wireguard_example:
    runs-on: ubuntu-latest
    steps:
      - run: sudo apt install wireguard

      - run: echo "${{ secrets.WIREGUARD_PRIVATE_KEY }}" > privatekey

      - run: sudo ip link add dev wg0 type wireguard

      - run: sudo ip address add dev wg0 192.168.1.2 peer 192.168.1.1

      - run: sudo wg set wg0 listen-port 48123 private-key privatekey peer examplepubkey1234... allowed-ips 0.0.0.0/0 endpoint 1.2.3.4:56789

      - run: sudo ip link set up dev wg0

      - run: curl -vvv http://192.168.1.1

Weitere Informationen zum sicheren Speichern von Schlüsseln finden Sie im WireGuard-Schnellstart sowie unter Verwenden von Geheimnissen in GitHub-Aktionen.

Verwenden von Tailscale zum Erstellen einer Netzwerküberlagerung

Tailscale ist ein kommerzielles Produkt, das auf WireGuard basiert. Diese Option ähnelt WireGuard sehr, mit der Ausnahme, dass Tailscale eher ein vollständiges Produkt als eine Open Source-Komponente ist.

Die Nachteile sind ähnlich wie bei WireGuard: Es handelt sich um eine 1:1-Verbindung, sodass möglicherweise zusätzlicher Arbeitsaufwand entsteht, um für Hochverfügbarkeit oder hohen Durchsatz zu sorgen. Sie müssen weiterhin Schlüssel generieren und sicher speichern. Das Protokoll ist weiterhin UDP, sodass Ihr Netzwerk UDP-Datenverkehr unterstützen muss.

Es gibt jedoch einige Vorteile gegenüber WireGuard: NAT-Traversal ist integriert, sodass Sie keinen Port im öffentlichen Internet verfügbar machen müssen. Diese Option führt bei weitem am schnellsten zur Einsatzbereitschaft, da Tailscale einen GitHub Actions-Workflow mit einem einzigen Schritt zum Herstellen der Verbindung mit dem Überlagerungsnetzwerk bietet.

Weitere Informationen zum sicheren Speichern von Schlüsseln finden Sie unter Tailscale GitHub Action sowie Verwenden von Geheimnissen in GitHub-Aktionen.