Ein VLAN mit WireGuard und VXLAN zwischen Standorten aufspannen

Der teuerste Teil eines Anbieterwechsels sind selten die Server. Es sind die Adressen: jeder DNS-Eintrag, jede Firewall-Regel, jeder Lizenzschlüssel und jede Allowlist eines Partners, in der Ihre IPs eingetragen sind. Wenn dasselbe VLAN während des Umzugs an beiden Orten existieren kann, muss nichts davon geändert werden. So wird eine Layer-2-Erweiterung aus einfachen Linux-Bausteinen gebaut, und das müssen Sie richtig machen, bevor Sie ihr Produktionsverkehr anvertrauen.

Warum überhaupt aufspannen

Eine Umnummerierung erzwingt einen Cutover nach dem Big-Bang-Prinzip: Alles zieht in einer Nacht um, oder nichts. Ein aufgespanntes VLAN macht daraus viele kleine Schritte. Ein bereits umgezogener Server und ein noch nicht umgezogener teilen sich Subnetz und Gateway, also können Sie einen Host umziehen, ihn in seiner neuen Umgebung testen und zurückholen, wenn etwas nicht stimmt. Der Preis ist ein vorübergehender Tunnel. Die Ersparnis sind Wochen der Umnummerierung und eine Cutover-Nacht ohne Weg zurück.

Der übliche Einwand lautet, Layer 2 über Standorte hinweg sei fragil. Das ist es, wenn es als flache Bridge über das Internet gebaut wird. Gebaut als verschlüsseltes Overlay pro VLAN, das in einer richtigen Fabric landet, ist es ein diszipliniertes Migrationswerkzeug.

Die Bausteine

Vier Teile, alle im Mainline-Linux-Kernel:

1. WireGuard für den verschlüsselten Punkt-zu-Punkt-Pfad zwischen den beiden Endpunkten. Es ist klein, schnell und bietet fast nichts, was man falsch konfigurieren könnte.
2. VXLAN über WireGuard, ein VXLAN-Interface pro aufgespanntem VLAN, damit jedes Segment im Tunnel getrennt bleibt.
3. Eine Linux-Bridge pro VLAN, die das VXLAN-Interface mit dem lokalen VLAN verbindet.
4. Ein VLAN-Sub-Interface auf dem Trunk des Endpunkts zum lokalen Switch.

Auf jedem Endpunkt sieht die Form für ein VLAN so aus:

# encrypted underlay
ip link add wg0 type wireguard
wg setconf wg0 /etc/wireguard/wg0.conf
ip address add 10.255.0.1/30 dev wg0
ip link set wg0 up

# one VXLAN per stretched VLAN, unicast to the far end over the tunnel
ip link add vx210 type vxlan id 210 local 10.255.0.1 remote 10.255.0.2 dstport 4789
ip link add br210 type bridge
ip link add link eth1 name eth1.210 type vlan id 210
ip link set vx210 master br210
ip link set eth1.210 master br210
ip link set vx210 up; ip link set eth1.210 up; ip link set br210 up

Machen Sie es mit NetworkManager oder systemd-networkd persistent, sobald es funktioniert. Die Befehlsform ist der klarste Weg, die Schichten zu sehen.

Zuerst die MTU richtig einstellen

Fast jedes Problem der Art «Ping geht, aber die Anwendung hängt» auf einem aufgespannten VLAN ist die MTU. Jede Schicht bringt Overhead mit:

• WireGuard fügt 60 Bytes über IPv4 hinzu (80 über IPv6).
• VXLAN fügt 50 Bytes hinzu (äußeres Ethernet, IP, UDP und der VXLAN-Header).

Bei einem Standardpfad von 1500 Bytes zwischen den Standorten passt ein volles 1500-Byte-Frame eines Servers nicht hindurch. Sie haben zwei ehrliche Optionen: die MTU des Underlay-Pfads anheben (wenn die Glasfaserstrecke und beide Enden Jumbo Frames unterstützen, ist das die saubere Antwort) oder die MTU auf dem aufgespannten Segment für die Dauer der Migration absenken. Was Sie nicht tun dürfen, ist darauf zu hoffen, dass die Fragmentierung es schon richtet. Testen Sie mit Don't-Fragment-Pings in der Größe, die Sie erwarten:

ping -M do -s 1472 <host-on-far-side>

Den Loop-Schutz intakt lassen

Ein aufgespanntes VLAN verbindet zwei Layer-2-Domänen, und die verlockende Lösung für Beschwerden des Spanning Tree ist, Spanning Tree auf dem Port abzuschalten. Tun Sie das nicht. Filtern Sie BPDUs nur dort, wo der Endpunkt der Erweiterung angeschlossen ist, damit die beiden Seiten ihre Spanning-Tree-Domänen nicht zusammenlegen, während jeder andere Port den vollen Loop-Schutz behält. Und bauen Sie niemals zwei parallele Erweiterungen für dasselbe VLAN, es sei denn, etwas verhindert ausdrücklich, dass beide gleichzeitig aktiv sind.

In einer echten Fabric landen

Auf der empfangenden Seite sollte der Trunk des Endpunkts auf einem gewöhnlichen Switch-Port der Fabric landen, damit das aufgespannte VLAN zu einem normalen Segment wird: gleiches Gateway, gleiches Dual-Homing, gleiches Monitoring wie jedes native Segment. Wenn Ihre VLAN-Nummern mit Nummern kollidieren, die am Ziel bereits in Gebrauch sind, bilden Sie sie beim Eintritt auf einen freien Bereich ab und führen Sie eine schriftliche Tabelle der Zuordnung. In einer EVPN-Fabric leiten Sie die Segmentkennung aus der lokalen Nummer des Ziels ab, niemals aus der der Quelle, damit die Nummerierungsregel der Fabric selbst weiterhin gilt.

Für den Durchsatz planen

Verschlüsselung plus Kapselung ist CPU-Arbeit, und ein einzelner Tunnel auf einem gegebenen Endpunkt hat eine Durchsatzobergrenze, die durch diese Arbeit bestimmt wird. Sie reicht für die meisten Migrationen aus, aber sie ist eine echte Obergrenze. Messen Sie sie vor der Migration auf der Hardware Ihres Endpunkts mit iperf3 durch den Tunnel, binden Sie die Interrupts und die Arbeit des Tunnels an einen dedizierten Kern, und entscheiden Sie im Voraus, bei welcher Last Sie einen zweiten Tunnel auf einem zweiten Kern hinzufügen und die VLANs zwischen beiden aufteilen.

Eine Migrationsreihenfolge, die funktioniert

1. Bauen Sie die Erweiterung und testen Sie sie mit einem entbehrlichen Host auf jeder Seite.
2. Prüfen Sie die MTU Ende zu Ende bei voller Frame-Größe.
3. Ziehen Sie zuerst einen Server mit geringem Risiko um. Prüfen Sie die Erreichbarkeit des Gateways, DNS, Monitoring und Backups aus seiner neuen Umgebung.
4. Ziehen Sie den Rest in Gruppen um, die zu den Abhängigkeiten Ihrer Anwendung passen (Datenbank-Replikate vor den Primaries, Worker vor den Frontends).
5. Ziehen Sie das Gateway zuletzt um, sobald der meiste Verkehr lokal auf der neuen Seite stattfindet.
6. Entfernen Sie die Erweiterung erst, wenn nichts auf der alten Seite mehr auf dem Segment antwortet.

Bevor Sie anfangen, prüfen Sie

• Ist der Tunnel Ende zu Ende verschlüsselt, nicht nur «auf einer privaten Leitung»?
• Kennen Sie die MTU-Obergrenze des Pfads, gemessen, nicht angenommen?
• Ist die BPDU-Filterung auf die Ports der Erweiterung beschränkt?
• Gibt es eine schriftliche Tabelle der VLAN-Zuordnung?
• Haben Sie eine gemessene Durchsatzobergrenze und einen Plan für den Fall, dass Sie sie überschreiten?

Wir bauen solche Erweiterungen zwischen unseren eigenen Standorten und von jedem Ort aus, den wir per Glasfaser erreichen, damit Kunden ohne Umnummerierung zu uns wechseln. Wenn Sie einen Umzug planen und die Adressen bleiben sollen, wo sie sind, planen wir ihn gern mit Ihnen.

Mit einem Ingenieur sprechen

Verwandt: Zu uns wechseln ohne Umnummerierung: Layer-2-Erweiterung · Rechenzentrums-Fabric: EVPN/VXLAN auf Cisco Nexus · Verschlüsseltes Multi-Site-Backbone: das DMVPN-Mesh