To tunnel or not to tunnel: Infrastruktur-Fusion mit einer bedeutenden Neukundin – Teil 3/4

Die Sache mit den rohen Eiern

Nein, wir steigen nicht ins Food-Business ein 😉. Aber der Roll-out der lokalen Firewall hat es bereits gezeigt: Selbst kleine Fehler können zu Problemen führen. Je nach Art des Fehlers – und je nachdem, wen man fragt – fällt das dann irgendwo zwischen "nicht so schlimm" und "KATASTROPHE!".

Die als nächstes anstehenden Migrationsschritte betrafen zentrale Komponenten wie das Netzwerk und damit die Erreichbarkeit der Server. Sprich, wir mussten wie mit einem Karton roher Eier sehr, sehr vorsichtig hantieren, um nichts kaputtzumachen. Das machte sämtliche Arbeiten relativ komplex, weil wir fortlaufend sicherstellen mussten, dass der nächste Schritt keine ungewollten Nebeneffekte hat – und was unser Rollback-Plan ist, sollte doch etwas nicht so klappen wie erhofft.

Das Ganze ergab sehr interessante Diskussionen zwischen mir und Andri – teils haben wir gefühlt unzählige Varianten ge-brainstormed, durchdiskutiert, verworfen, verfeinert – um am Ende gerade mal einen winzigen Schritt vorwärts zu machen. Bei einem Teilaspekt waren wir am Ende sogar erst mit Variante G glücklich, A–F hatten wir geprüft und verworfen …

Migrations-Tunnel

To tunnel or not to tunnel ist natürlich Blödsinn. Dass wir den Traffic für die Migration – darunter sensitive Kundendaten – selbstredend nicht unverschlüsselt über das öffentliche Internet spulen werden, war uns von Anfang an klar. Unklar war aber, wie wir diesen Tunnel zwischen dem abzulösenden Datacenter-Standort der Webagentur und unserem Datacenter-Standort bauen werden.

Nutanix bietet die Möglichkeit einer Migration von VMs via SSH, was eine verschlüsselte Verbindung wäre. Dieses Feature haben wir aber verworfen, weil es laut Nutanix "for testing only" und somit nicht für den produktiven Betrieb gedacht ist. 

Tunneln “übers Kreuz”

Unser Plan mit "möglichst viel Flexibilität" sah vor, dass wir im zu bauenden Migrations-Tunnel zumindest vorübergehend alles übers Kreuz nutzen können, inkl. produktivem Traffic.

Ein möglicher Ansatz war, dies mittels Wireguard zu machen. Dies hätte zwar für die Verknüpfung der zwei Nutanix-Cluster funktionieren können (Layer 3 Traffic), nicht aber für den Über-Kreuz-Betrieb von VMs, für welchen wir zwingend auch Layer 2 Traffic durch den Tunnel bekommen mussten – womit Wireguard dann raus war.

Ebenso verworfen haben wir relativ schnell, das Tunneling mittels OpenVPN zu machen (unter anderem, weil sie in der Dokumentation bereits schreiben, dass sie reines Layer 3 VPN machen).

Die Lösung: tinc

Und hier kommt tinc ins Spiel. Ein kleines Linux-Tool, das als VPN-Dienst betrieben werden kann – und sowohl Layer 3 als auch Layer 2 Traffic tunnelt (notabene in 2 separaten Tunneln, aber das spielt hier keine Rolle).

In der obigen Grafik sind schematisch die zwei VPN-Tunnel für Layer 2 und Layer 3 zu sehen. Besonderes Augenmerk hatten für uns die grünen und pinken Pfade: Temporär während der Migration wollten wir einzelne IP-Prefixe via BGP noch via dem bisherigen AS announcen lassen – die VMs aber im Hintergrund bereits auf unseren Cluster migrieren und dort betreiben können (grüner Pfad). 
Oder umgekehrt dann auch BGP bereits umstellen und von unserer Seite her announcen, während die VMs noch auf dem bisherigen Cluster laufen (pinker Pfad). 
Am Ende spielte es keine Rolle, auf welcher Seite ein Prefix announced wurde und wo die VM lief – sie war über einen der zwei Pfade erreichbar. Das gab uns viel Flexibilität.

Natürlich lief das Set-up nicht einfach im ersten Anlauf. Insbesondere weil das, was wir damit gemacht haben, nicht grad der 08/15-Case ist, für den wir 1:1 eine fertige Config aus der Dokumentation hätten kopieren können … Nach etwas Tüfteln liefen am Ende aber beide Tunnel zwischen den Tunnel-VMs salt und pepper.

Auf der Grafik zu sehen sind die zwei Tunnel VMs, auf denen für L2/L3 jeweils ein separater tinc-Daemon gestartet wurde, der auf je einem dedizierten Port erreichbar war.

tinc-Konfiguration, Vor-Synchronisation und erneuter Firewall-Ärger

Damit sich die zwei Nutanix-Cluster gegenseitig erreichen können, reichte eine im Vergleich einfache tinc-Konfiguration mit den entsprechenden Netzwerken. Auf Seiten Firewall resp. Router genügte eine statische Route, damit der Traffic zum anderen Cluster zur Tunnel-VM geführt, von dort dann via dem L3-Tunnel ins andere Datacenter transportiert und dort wieder an den Switch übergeben werden konnte.

Über den Layer 3 Tunnel konnten wir die zwei Nutanix-Cluster miteinander verbinden, eine erste VM testweise migrieren und später die Vor-Synchronisation sämtlicher VMs in Richtung des Ops One Clusters machen. Dieser initiale Sync dauerte seine Zeit, was aber nicht tragisch war und gut im Hintergrund laufen konnte. Parallel dazu konnten wir uns um den Layer 2 Pfad kümmern, der etwas herausfordernder war …

Eine Challenge für sich stellte die Firewall-Lösung auf Seite der Webagentur dar. Manchmal ist zu viel Sicherheit auch einfach ein Klotz am Bein … Bis die Pakete, die durch den Tunnel gingen – und die Antworten dazu – der Firewall soweit genehm waren, dass keine Anti-Spoofing- und sonstigen Schutz-Mechanismen reingefunkt haben, dauerte es die eine oder andere Runde des gepflegten Fluchens.

Finales Tunnel-Konstrukt

Nun aber zur Layer 2 Verbindung: Beidseitig sind die Netzwerke segmentiert und sowohl auf Ebene der IP-Netze als auch auf Ebene der Switches als einzelne VLANs aufgeteilt. Insgesamt gab es VMs aus rund 15 Segmenten zu migrieren, wobei z. B. auf Quellseite das VLAN 200 genutzt wurde, dies auf Zielseite aber neu z.B. VLAN 1050 sein sollte. Wir mussten also irgendwo auch diese Übersetzung einbauen. Das finale Konstrukt ist im unteren Teil der obigen Grafik zu sehen:

• Die VM hat ein "physisches" Interface eth2 im VLAN 0 (und ist auf Ebene des Nutanix-Clusters auf "trunked"-Mode konfiguriert, um alle VLANs erreichen zu können, siehe KB-3324).
• In der Tunnel-VM gibt es für dieses Interface dann pro VLAN ein Sub-Interface wie z.B. eth2.200, sowie ein virtuelles Tunnel-Interface wie z.B. tun02.200.
• Der Traffic wird über eine Bridge (br02) von eth2.200 nach tun02.200 "gespiegelt" und landet damit bei tinc, welches auf die lokalen Tunnel-Interfaces hört und dort aufschlagende Pakete entsprechend in den VPN-Tunnel übergibt.
• In der tinc-Konfiguration gibt es beidseitig das Matching der Tunnel-Interfaces, sodass tun02.200 auf der linken Seite sinngemäss mit tun02.200 auf der rechten Seite verbunden ist.
• Auf der Ziel-Seite ist schematisch das gleiche Set-up mit den Bridges eingerichtet. Mit dem Unterschied, dass wir hier am Schluss der Kette die Übersetzung machen (siehe rote Markierung), und Pakete aus dem Source-VLAN bei der Übernahme aus z. B. tun02.200 auf die richtige Destination-VLAN-ID auf dem Interface der Tunnel-VM übergeben (z. B. eth2.1050 und damit ins VLAN 1050).

Sobald der Layer 2 Tunnel inkl. der gesamten VLAN-Bridging-Konfiguration lief, konnten wir VMs frei hin und her migrieren. Es spielte (fast) keine Rolle mehr, ob sie noch im bisherigen oder schon im Ops One Cluster liefen – sie waren in beiden Fällen weiter unter der bisherigen IP-Adresse erreichbar.

Wir haben dennoch darauf verzichtet, VMs für längere Zeit "über Kreuz" laufen zu lassen, und diese Option wirklich nur für die Dauer der Migration genutzt. Denn neben der zusätzlichen Komplexität und allfälligem Troubleshooting-Aufwand brachte dieser Umweg auch einen gewissen Performance-Impact sowie Limitierungen des tinc-Tunnels mit sich.

Die andere site-to-site VPN-Strecke

Wir hatten zu Beginn des Migrationsprojekts den bestehenden site-to-site VPN-Tunnel zwischen den Firewalls der Webagentur und einem externen Partner als kritisch erkannt – und wollten dafür möglichst früh im Projekt eine Lösung finden. Während ich mich um die oben beschriebene Netzwerk-Verbindung zwischen den zwei Clustern kümmerte, hat sich Andri dieser VPN-Konfiguration angenommen.

Diskutierte Lösungen

Auch hier wurden am Ende mehrere Varianten angedacht, geprüft, diskutiert, teils getestet, und wieder verworfen. Im Raum standen unter anderem (wenn auch nur sehr kurz), die bestehende physische Firewall umzuziehen und weiterlaufen zu lassen, diese durch eine virtuelle Appliance des selben Herstellers zu ersetzen, die VPN-Konfiguration in einem VyOS-Setup abzubilden etc.

Unsere Lösung basiert nun auf einem Ops One Managed Server, der mit seinem Debian Linux eine super Basis bietet – und auf welchem Strongswan für den IPsec-Tunnel konfiguriert ist. Die Konfigurationsparameter konnten wir teils aus den bestehenden Firewalls und den bereitgestellten Dokumentationen/Config-Sheets erhalten – teils musste etwas weiter gegraben werden. Eine Konfigurations-Option erschloss sich erst nach Konsultation von RFC 5114 Abschnitt 3.2 – denn wer weiss schon auswendig, dass die "Diffie-Hellman Group 20" synonym für "384-bit Random ECP Group" steht?

Umstellung der VPN-Strecke

Die effektive Umstellung dieser VPN-Strecke selbst – und der involvierten Systeme, die darüber Daten austauschen – war dank der ausführlichen Vorbereitung und vieler Tests dann eine relativ kleine Sache, die wir an einem Abend umsetzen konnten, ohne dass davon jemand etwas mitbekam. Nach einigen Tagen mit besonderem Augenmerk auf den Neuerungen zeigte sich, dass der Tunnel stabil ist. Und auch Tage mit viel Traffic auf den involvierten Systemen brachten nichts ins Wackeln.

Damit wurde aus diesem als heikel erkannten Punkt in der Planung am Ende in der Realität – glücklicherweise – ein unproblematischer Schritt, und wir konnten hier schneller einen Haken dran machen als erwartet (bzw. in der papierlosen Variante das Ticket schliessen). 

Routing-Migration

Bis hierhin (wir befinden uns mittlerweile im Spätherbst 2025) wurden die zu migrierenden IPv4- und IPv6-Prefixe weiterhin über die bisherige Routing-Infrastruktur und das autonome System der Web-Agentur announced und waren darüber erreichbar.

Als einen der finalen Schritte mussten wir diese IP-Prefixe zu uns und unserem AS198249 bringen. Dazu mussten wir einige Weichen umstellen, und zwar im laufenden Betrieb. Entsprechend vorsichtig gingen wir vor und testeten diesen Migrationsschritt ausführlich mit einem Test-Prefix, um möglichst alle scharfen Kanten und Stolpersteine schon vorab zu finden und zu entfernen.

Vorarbeiten für die Umstellung

Als Vorbereitung für die Umstellung begannen wir bei RIPE die nötigen Route-Objekte in der RIPE-DB zu erstellen, sowie in einem zweiten Schritt die für RPKI nötigen ROAs einzutragen. Vereinfacht gesagt wird damit eine Signatur erstellt, welche es Netzwerkbetreibern ermöglicht, BGP-Announcements bei einer zentralen Instanz (in unserem Fall die für Europa zuständige RIPE) zu validieren. Es könnte sonst ja irgendwer behaupten, gewisse IP-Prefixe zu besitzen, und den Traffic zu sich umleiten. RPKI unterbindet solche (versehentlich oder absichtlich) falsch gesetzten Route-Announcements.

Manuelle Intervention nötig

Das Internet, das wir täglich sehen, nutzen und mit dem Handy in unserer Hosentasche herumtragen, wirkt topmodern und glänzt im Sonnenlicht. Im Hintergrund ist es auch modern – aber nicht alles läuft einfach auf Knopfdruck vollautomatisch. So mussten einzelne unserer Upstream-Provider die neuen Prefixe manuell freischalten, damit unsere Announcements auch effektiv weiterverteilt und weltweit sichtbar wurden. Diesen Fakt erkannten wir relativ schnell, auch dank der Website bgp.tools, welche eine weltweite Aussensicht der BGP Announcements der verschiedensten Provider bietet.

AS-Path-Prepending

Das Testnetz hatten wir zu diesem Zweck über mehrere Tage hinweg parallel angekündigt. Weiterhin über das bisherige AS der Webagentur (wie bisher), und zusätzlich von unserem AS198249 her, aber so konfiguriert, dass dieser Pfad als schlechtere Option gesehen wird (zu diesem Thema habe ich eine ausführliche Zusammenfassung zum AS-Path-Prepending in meinem persönlichen Blog veröffentlicht). So konnten wir die Durchlässigkeit der Konfigurationen und Filter unserer Upstream-Provider prüfen, und sehr gut steuern, wann genau wir den Traffic wohin leiten wollen.

Die harte Deadline kommt näher!

Alle Involvierten waren über Wochen hinweg stark auf dieses Projekt fokussiert und die Arbeit war intensiv. Einerseits machten wir konstant Fortschritte und sahen deutlich, dass wir vorankamen. Andererseits war eine gewisse Spannung spürbar, vielleicht auch eher Neugierde, ob alles Vorbereitete dann auch effektiv funktioniert, wenn wir die letzten Schritte gehen: produktive VMs migrieren, Weichen umstellen und schlussendlich, möglichst vor Weihnachten, die abgelösten Komponenten zurückbauen.