Im vorherigen Leitfaden haben Sie die erste virtuelle Maschine dieser Plattform erstellt und darauf ein Gastbetriebssystem installiert, nämlich ein Debian-System, das nur von innerhalb der eigenen Bridge des Proxmox-Hosts erreichbar ist. Um von außerhalb des Internets darauf zugreifen zu können, müssen Sie zunächst eine geroutete IPv4-Adresse und einen Tunnel bei Taipan bestellen, diesen Tunnel auf dem Proxmox-Host selbst terminieren und anschließend eine der Adressen an die virtuelle Maschine weiterleiten.
Bestellen Sie eine geroutete IPv4-Adresse und einen Tunnel
Die Konfiguration erfolgt über das Panel und nicht über Proxmox: Wenn Sie einen Tunneltyp aus der Dienstliste auswählen, wird der produktinterne Konfigurationsbildschirm geöffnet, der für GRE, IPsec und WireGuard einheitlich gestaltet ist.
Die fünf IP-Adressen, die in diesem Screenshot hervorgehoben sind, entsprechen genau der Anzahl, die in dieser Anleitung bestellt wird: eine für die im vorherigen Abschnitt erstellte VM und vier weitere, die verteilt werden können, sobald zusätzliche VMs vorhanden sind. Der Datenverkehr funktioniert auf die gleiche Weise – als feste Kachel statt als laufender Zähler –, und der durchgestrichene Preis daneben entspricht dem Kampagnenrabatt, der bereits auf der Preisseite zu sehen ist.
Bei dieser Aufnahme handelt es sich um den Bildschirm des GRE-Produkts, und dessen letztes Feld, „Customer endpoint IPv4“, ist GRE-spezifisch: eine feste Quelladresse, von der der Tunnel Datenverkehr erwartet. In der WireGuard-Version derselben Seite fehlt dieses Feld gänzlich, da sich ein WireGuard-Peer über ein Schlüsselpaar und nicht über eine feste Quelladresse authentifiziert; alle anderen Angaben auf der Seite – Laufzeit, Anzahl der IPv4-Adressen, Datenverkehrsstufe – bleiben unverändert.
Hinter dieser Produktauswahl stehen drei Tunnelarten, die jeweils unterschiedliche Vor- und Nachteile aufweisen:
- GRE: Das einfachste der drei Protokolle. Es gibt keinerlei Verschlüsselung, daher ist es schnell, aber es übersteht einen NAT-Hop nicht aus eigener Kraft.
- IPsec: Authentifizierung und Verschlüsselung über eine mittels IKE ausgehandelte Sitzung – die richtige Wahl, wenn der Datenverkehr selbst während der Übertragung vertraulich bleiben muss.
- WireGuard: moderne, auf Schlüsselpaaren basierende Verschlüsselung mit geringem Einrichtungsaufwand, die auch bei IP-Wechseln weiterhin funktioniert – der einfachste Einstieg für Verbindungen ohne feste öffentliche Adresse.
Dieser Proxmox-Host befindet sich hinter der Adresse, die ihm seine eigene Upstream-Verbindung gerade zuweist. Daher ist WireGuard der Tunneltyp, den diese Anleitung tatsächlich empfiehlt: Ein statisches Schlüsselpaar bleibt auch bei einer Änderung dieser Adresse erhalten, während dies beim festen Endpunkt-zu-Endpunkt-Modell von GRE nicht der Fall wäre.
Fünf Adressen decken den Bedarf dieses Leitfadens ab: eine für die im vorherigen Abschnitt erstellte VM und vier weitere, die verteilt werden sollen, sobald weitere VMs vorhanden sind. Nach Abschluss der Bestellung erhalten Sie eine echte Bestell-ID, einen Block mit fünf gerouteten IPv4-Adressen und den WireGuard-Endpunkt, an dem dieser Tunnel endet:
order: NL7R2aRA2oVbjHiL3DLfzXBd
endpoint: 195.123.189.9
routed: 195.123.189.17
195.123.189.18
195.123.189.19
195.123.189.20
195.123.189.21Wenn die Bestellung bestätigt wird, der Tunnel selbst jedoch kurzzeitig den Status „ausstehend“ anzeigt, ist das normal. Die Bereitstellung erfolgt auf dem Router, der diesen Endpunkt verwaltet, nach dessen eigenem Zeitplan. Warten Sie daher einen Moment, bevor Sie mit dem nächsten Schritt fortfahren.
Den Tunnel auf dem Proxmox-Host beenden
An einem WireGuard-Tunnel ist nichts Proxmox-spezifisch: Es handelt sich um eine reine Linux-Schnittstelle, die unabhängig davon, ob sie auf einem Hypervisor oder einem beliebigen anderen Debian-Rechner läuft, auf dieselbe Weise konfiguriert wird. Das bedeutet auch, dass jeder der unten aufgeführten Befehle genau dem entspricht, was ein Provisioning-Skript unbeaufsichtigt ausführen würde, ohne dass ein Assistent zwischen dem Panel und der Schnittstelle selbst steht.
Schlüsselpaar generieren
WireGuard authentifiziert Peers mithilfe von Schlüsselpaaren statt eines gemeinsamen Geheimnisses, sodass der erste Schritt vollständig offline erfolgt, noch bevor Taipan überhaupt ins Spiel kommt:
install -d -m 700 /etc/wireguard
sh -c 'umask 077; wg genkey | tee /etc/wireguard/taipan.key | wg pubkey > /etc/wireguard/taipan.pub'
cat /etc/wireguard/taipan.pubDieser letzte Befehl gibt die öffentliche Hälfte aus – den einzigen Teil, der diesen Host tatsächlich verlassen muss:
FIv6nJ3IE0EsMH79Hxj6wV4piku0Guj8nvyaUJ7PEic=Der private Schlüssel in /etc/wireguard/taipan.key wird niemals irgendwo eingefügt, übermittelt oder per E-Mail versendet: Nur der öffentliche Schlüssel wird an Taipan übermittelt – dieselbe Asymmetrie, die es sicher macht, ein SSH-Schlüsselpaar zu generieren, noch bevor überhaupt ein Konto existiert, mit dem es verwendet werden kann.
WireGuard-Konfiguration erstellen
Mit den weitergeleiteten Adressen und dem Endpunkt aus der Bestellung sowie Taipans eigenem öffentlichen Schlüssel und dem UDP-Port aus dem Panel, /etc/wireguard/wg0.conf enthält alles, was die Schnittstelle benötigt:
[Interface]
PrivateKey = <contents of /etc/wireguard/taipan.key>
Address = 100.64.0.2/32
Table = off
PostUp = ip rule add from 195.123.189.17/32 table 20 priority 100
PostUp = ip rule add from 195.123.189.18/32 table 20 priority 100
PostUp = ip rule add from 195.123.189.19/32 table 20 priority 100
PostUp = ip rule add from 195.123.189.20/32 table 20 priority 100
PostUp = ip rule add from 195.123.189.21/32 table 20 priority 100
PostUp = ip route add default dev %i table 20
PreDown = ip rule del from 195.123.189.17/32 table 20 priority 100
PreDown = ip rule del from 195.123.189.18/32 table 20 priority 100
PreDown = ip rule del from 195.123.189.19/32 table 20 priority 100
PreDown = ip rule del from 195.123.189.20/32 table 20 priority 100
PreDown = ip rule del from 195.123.189.21/32 table 20 priority 100
[Peer]
PublicKey = <Taipan's public key, from the panel>
Endpoint = 195.123.189.9:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25Table = off Haltestellen wg-quick ohne die Standardroute dieses Hosts zu beeinflussen, die weiterhin für alles, was nicht zu diesen fünf Adressen gehört, über den normalen Uplink geleitet werden muss. Die PostUp Stattdessen erstellen die Zeilen eine zweite Routing-Tabelle, auf die ausschließlich Datenverkehr zurückgreift, der von einer gerouteten Adresse stammt, sodass eine Antwort von 195.123.189.17 verlässt den Tunnel, während der normale ausgehende Datenverkehr vom Host davon völlig unberührt bleibt.
Warum wird im Feld „Adresse“ die IP-Adresse 100.64.0.2 anstelle einer der fünf tatsächlichen Adressen verwendet?
Da die Tunnelschnittstelle selbst keine öffentliche Identität benötigt, ist dies nur für die darüber übertragenen gerouteten Adressen erforderlich. 100.64.0.0/10 ist der gemeinsame Adressraum, der genau für diese Art von unnummerierter Punkt-zu-Punkt-Verbindung reserviert ist, sodass die Schnittstelle nummeriert wird, ohne dass eine der fünf Adressen verbraucht wird, für die dieser Leitfaden tatsächlich bezahlt.
Den Tunnel hochbringen
wg-quick liest dieselbe Datei und führt nacheinander genau die Schritte aus, die in der eigenen Ausgabe aufgeführt sind: Er erstellt die Schnittstelle, lädt den Schlüssel, weist die Adresse zu und führt jede PostUp Zeile.
Eine neue Benutzeroberfläche zeigt 0 empfangene Bytes an, bis der Gegenpart tatsächlich antwortet, was nach dem allerersten Paket einen Moment dauern kann. Ein Handshake belegt lediglich, dass die verschlüsselte Verbindung zum Gegenpart an sich funktioniert; daher sollte gezielt getestet werden, ob eine geroutete Adresse tatsächlich von Ende zu Ende erreichbar ist, anstatt dies aufgrund eines einwandfreien wg show allein.
Eine Adresse an die VM weiterleiten
Der Tunnel landet nun auf dem Proxmox-Host selbst, sodass ein weiterer Hop erforderlich ist, um die VM tatsächlich zu erreichen: eine Route, die eine bestimmte Adresse an die eigene private Adresse dieser VM auf vmbr0 weiterleitet – derselben Bridge, die bereits vor zwei Anleitungen konfiguriert wurde.
ip route add 195.123.189.17/32 via 10.0.2.100 dev vmbr0Diese eine Zeile macht den entscheidenden Unterschied aus zwischen der Bereitstellung einer weitergeleiteten Adresse durch das Gateway selbst und der Weiterleitung an eine dahinter liegende VM: Anstatt die Adresse zu lo Auf dem Host leitet dieser den Datenverkehr – anders als bei einem direkt auf dem Gateway laufenden Dienst – einen Hop weiter an die interne Adresse, die die VM bereits besitzt.
Auf der Seite der VM werden zwei passende Elemente benötigt: die öffentliche Adresse selbst und eine Route zurück über den Host für alle Daten, die von dort stammen.
ip address add 195.123.189.17/32 dev ens18
ip route add default via 10.0.2.100 dev ens18 onlinkBevor Sie von außen testen: Stellen Sie sicher, dass net.ipv4.ip_forward = 1 wird tatsächlich auf dem Proxmox-Host selbst festgelegt. Die Weiterleitung zwischen dem Tunnel und vmbr0 hängt davon ab, und eine geroutete Adresse gelangt ohne diese Einstellung stillschweigend nirgendwohin. Um dies zu überprüfen, sysctl net.ipv4.ip_forward sollte eine 1 ausgeben.
Wenn die Weiterleitung aktiviert und auf beiden Seiten konfiguriert ist, ip route get 1.1.1.1 from 195.123.189.17 Ein auf dem Proxmox-Host ausgeführter Befehl bestätigt den tatsächlich für diese Adresse gewählten Pfad: Das Ergebnis lautet dev wg0 bedeutet, dass Antworten wie vorgesehen durch den Tunnel geleitet werden, während in allen anderen Fällen das quellspezifische Routing aus dem vorherigen Schritt vor weiteren Tests noch einmal überprüft werden muss.
Die verbleibenden Adressen verteilen
Vier Adressen aus eben diesem Befehl sind noch ungenutzt, und das Muster, nach dem die erste Adresse zugewiesen wurde, wiederholt sich bei jeder einzelnen genau gleich: eine private Adresse auf vmbr0 für die betreffende VM, eine hostseitige Route, die auf diese verweist, und die Adresse selbst, die der eigenen Schnittstelle dieser VM hinzugefügt wurde.
195.123.189.17 -> web01, 10.0.2.100 (this guide)
195.123.189.18 -> next VM, once created
195.123.189.19 -> next VM, once created
195.123.189.20 -> next VM, once created
195.123.189.21 -> next VM, once createdAlle fünf nutzen weiterhin denselben Tunnel und dieselbe zuvor eingerichtete Routing-Tabelle: Tabelle 20 enthält bereits eine quellspezifische Regel für jede Adresse in diesem Block, sodass eine neue VM immer nur ihre eigene benötigt. ip route add <address>/32 via <its internal IP> dev vmbr0 auf der Host-Seite, zum Tunnel selbst gibt es nichts Weiteres zu sagen.
Zusammenfassend lässt sich sagen
- Ein WireGuard-Tunnel ist eine einfache Linux-Schnittstelle, die unabhängig davon, ob Proxmox beteiligt ist oder nicht, mit denselben Befehlen konfiguriert wird.
Table = offZudem sorgt das quellspezifische Routing dafür, dass eine geroutete Adresse von der eigenen Standardroute des Hosts getrennt bleibt.- Die Zuweisung einer Adresse an eine VM anstelle des Gateways selbst fügt lediglich eine weitere Route hinzu, die auf die interne Adresse dieser VM verweist.
- Jede Adresse in derselben Reihenfolge wird über denselben Tunnel geleitet, wobei jede nur ihre eigene Route benötigt, sobald eine VM vorhanden ist, die sie empfangen kann.
Im nächsten Leitfaden werden Sie diese VM als Vorlage speichern, um die nächste in einem Bruchteil der Zeit bereitzustellen.