Eine sichere Multi-Site-Webplattform bauen: Hetzner Cloud + MikroTik CHR + Proxmox über VXLAN

Ich betreibe mehrere Websites und Dienste auf einem einzigen dedizierten Server – aber ich wollte nicht, dass dieser Server direkt am Internet hängt. Was ich wollte:

• Die Rechenleistung (und den Preis) eines dedizierten Root-Servers mit Proxmox VE.
• Einen einzigen, sauberen Interneteingang mit Cloud-Firewall, einem echten Router davor und VPN-Zugang – ohne dafür Spezialhardware zu mieten.
• DDoS-Schutz und TLS zentral an einer Stelle, nicht auf jedem Webserver einzeln.
• Internen Traffic, der das Hetzner-Rechenzentrum nie verlässt.

Herausgekommen ist eine gestaffelte Architektur: ein winziger Cloud-Server mit einem MikroTik Cloud Hosted Router (CHR) als Torwächter, per VXLAN direkt an das Software-Defined-Networking eines Proxmox-Dedicated-Servers gekoppelt. Dahinter ein HAProxy als Reverse Proxy, und erst danach die eigentlichen VMs.

Dieser Beitrag ist bewusst als Anleitung geschrieben: mit Diagrammen, echten Befehlen und – fast wichtiger – den Stolperfallen, die mich Nerven gekostet haben.

Hinweis zu den Adressen: Alle öffentlichen IPs, Schlüssel und MAC-Adressen in diesem Text sind Platzhalter aus den Dokumentations-Bereichen (RFC 5737 / RFC 3849). Ersetze sie durch deine eigenen. Das interne Netz 10.99.0.0/24 kannst du übernehmen.

Inhaltsverzeichnis

1. Die Architektur auf einen Blick
2. Warum VXLAN und kein Hetzner vSwitch?
3. Teil 1 – Der Cloud-Server & die Hetzner Cloud Firewall
4. Teil 2 – MikroTik CHR installieren
5. Teil 3 – Das VXLAN-Overlay aufbauen
6. Teil 4 – Der CHR als DHCP, Gateway und NAT
7. Teil 5 – Die grobe Firewall am CHR
8. Teil 6 – VPN-Zugang per WireGuard
9. Teil 7 – HAProxy: TLS, Routing und das Feintuning
10. Die wichtigsten Stolperfallen
11. Verifikation
12. Fazit

1. Die Architektur auf einen Blick

Der Kerngedanke ist eine Zwiebel aus Schutzschichten: außen grob und billig, innen fein und teuer. Jede Schicht fängt ab, was die nächste gar nicht erst sehen soll.

                              INTERNET
                                 │
                                 ▼
                   ┌─────────────────────────────┐
                   │   Hetzner Cloud Firewall     │  ← Schicht 1: lässt nur
                   │   (nur 80/443 TCP, 443 UDP,   │    das Nötigste durch
                   │    SSH von Admin-IP)          │
                   └──────────────┬──────────────┘
                                  │
        ╔═════════════════════════▼═══════════════════════════╗
        ║   Hetzner Cloud · kleiner V-Server (CX/CPX)          ║
        ║  ┌───────────────────────────────────────────────┐  ║
        ║  │   MikroTik CHR  (RouterOS 7)                   │  ║  ← Schicht 2:
        ║  │   • ether1 = öffentliche IP (WAN)             │  ║    grobe Firewall,
        ║  │   • NAT: 80/443 → HAProxy                     │  ║    NAT, DHCP,
        ║  │   • DHCP v4+v6, Gateway 10.99.0.1             │  ║    VPN-Konzentrator
        ║  │   • WireGuard-VPN nach Hause / weitere Netze  │  ║
        ║  │   • VXLAN-Endpunkt (VNI 99)                   │  ║
        ║  └──────────────────────┬────────────────────────┘  ║
        ╚═════════════════════════╪═══════════════════════════╝
                                  │   VXLAN (UDP 4789), MTU 1450
                                  │   unverschlüsselt, aber DC-intern
        ╔═════════════════════════╪═══════════════════════════╗
        ║   Hetzner Robot · Dedicated Server mit Proxmox VE    ║
        ║  ┌──────────────────────▼────────────────────────┐  ║
        ║  │   VXLAN-Endpunkt  ⇄  Bridge vmbr99  (SDN)      │  ║
        ║  └───┬───────────┬───────────┬───────────┬───────┘  ║
        ║      │           │           │           │           ║
        ║   ┌──▼──┐    ┌───▼───┐   ┌───▼───┐   ┌───▼───┐       ║
        ║   │Admin│    │HAProxy│   │ Web 1 │   │ Web N │  …    ║  ← Schicht 3+:
        ║   │ .100│    │ .101  │   │ .106  │   │ .10x  │       ║    HAProxy = TLS,
        ║   └─────┘    └───┬───┘   └───────┘   └───────┘       ║    DDoS-Feintuning
        ║                  │  routet nach Host/SNI              ║    Web-VMs = Dienste
        ║                  └────────► nginx / uvicorn / …       ║
        ╚═════════════════════════════════════════════════════╝
              alle im selben L2-Segment  10.99.0.0/24  ·  2001:db8:97::/64

Der Datenpfad einer eingehenden Anfrage (Mermaid – nur falls dein Blog Mermaid rendert, sonst gilt das ASCII-Bild oben):

flowchart LR
    U[Besucher] --> HF[Hetzner Cloud FW]
    HF -->|80/443| CHR[MikroTik CHR NAT + Rate-Limit]
    CHR -->|dst-nat 10.99.0.101| VX{{VXLAN VNI 99}}
    VX --> HAP[HAProxy VM TLS + Limits]
    HAP -->|Host/SNI-Routing| W1[Web-VM nginx]
    HAP --> W2[Web-VM uvicorn]

Die Rollenverteilung:

2. Warum VXLAN und kein Hetzner vSwitch?

Hetzner bietet mit dem vSwitch eine Möglichkeit, Robot-Server über VLANs zu verbinden. Warum stattdessen ein selbstgebautes VXLAN?

• Cloud und Robot sind zwei Welten. Hetzner-Cloud-Netzwerke und der Robot-vSwitch sprechen nicht nativ miteinander. Ich brauche aber genau diese Brücke: Cloud-CHR ⇄ Dedicated-Proxmox. VXLAN als Overlay über die öffentlichen IPs ist herstellerneutral und funktioniert zwischen beliebigen Endpunkten.
• Voller Durchgriff. Ich terminiere das Overlay selbst auf dem CHR und auf Proxmox und entscheide über VNI, MTU, DHCP und Routing – kein Hetzner-Automatismus dazwischen.
• Der Traffic bleibt im Rechenzentrum. Cloud-Server und Dedicated stehen bei Hetzner. Die VXLAN-Pakete laufen DC-intern. Deshalb ist die bewusste Entscheidung vertretbar, das Overlay unverschlüsselt zu fahren.

⚠️ Sicherheitshinweis: VXLAN hat keine Verschlüsselung. Wer dem DC-internen Pfad nicht traut, kapselt das VXLAN in einen WireGuard-Tunnel (VTEP-Adressen dann aus dem WireGuard-/30). Das kostet etwas Durchsatz, MTU und CPU, ist aber die saubere Lösung für höhere Schutzbedarfe. Ich habe mich hier bewusst dagegen entschieden.

3. Teil 1 – Der Cloud-Server & die Hetzner Cloud Firewall

Der Router läuft auf einem kleinen Cloud-Server – er routet und filtert nur, er rechnet nichts. Ein CX22/CPX11 reicht locker.

1. In der Hetzner Cloud Console ein Projekt anlegen, Server erstellen (Debian als Basis – wir überschreiben es gleich mit dem CHR-Image).
2. Cloud Firewall anlegen und dem Server zuweisen. Eingehend erlauben:

Die UDP-4789-Regel nur für die IP des Dedicated-Servers freizugeben ist wichtig – sonst könnte jeder Pakete in dein Overlay injizieren.

4. Teil 2 – MikroTik CHR installieren

Der CHR ist RouterOS als Disk-Image für Virtualisierer/Cloud. Installation über das Hetzner-Rescue-System, indem wir das Raw-Image direkt auf die Systemplatte schreiben.

# Server im Rescue-Modus (Linux) starten, dann per SSH einloggen:
cd /tmp
wget https://download.mikrotik.com/routeros/7.21.5/chr-7.21.5.img.zip
unzip chr-7.21.5.img.zip

# ACHTUNG: /dev/sda ist die Systemplatte – das überschreibt ALLES.
dd if=chr-7.21.5.img of=/dev/sda bs=4M oflag=sync

reboot

Nach dem Reboot bootet RouterOS. Standard-Login: Benutzer admin, kein Passwort (sofort setzen!). Da der CHR die öffentliche IP per DHCP von Hetzner bekommt, ist er direkt per SSH/Winbox erreichbar.

# Zuerst absichern:
/user set admin password=EIN-STARKES-PASSWORT
/ip service disable telnet,ftp,www,api,api-ssl
/ip dhcp-client add interface=ether1 disabled=no    # WAN-IP von Hetzner beziehen

💡 CHR-Lizenz: Ohne Lizenz limitiert der CHR jedes Interface auf 1 Mbit/s. Für den Produktivbetrieb brauchst du mindestens eine p1-Lizenz (1 Gbit/s). Es gibt eine 60-Tage-Testlizenz (p-unlimited) zum Ausprobieren.

5. Teil 3 – Das VXLAN-Overlay aufbauen

Jetzt die Brücke zwischen CHR und Proxmox. Wir nutzen Unicast-VXLAN mit statischem Remote-Endpunkt (VTEP) – kein Multicast, weil das über das Internet ohnehin nicht ginge.

Kenngrößen (auf beiden Seiten identisch):

5a. CHR-Seite (RouterOS)

/interface vxlan
add name=vxlan_proxmox vni=99 mtu=1450 local-address=203.0.113.10

/interface vxlan vteps
add interface=vxlan_proxmox remote-ip=198.51.100.20

# Der CHR bekommt die Gateway-Adressen im Overlay:
/ip address
add address=10.99.0.1/24 interface=vxlan_proxmox
/ipv6 address
add address=2001:db8:97::1 interface=vxlan_proxmox advertise=no

5b. Proxmox-Seite (Software-Defined Networking)

Am elegantesten über das Proxmox SDN: Datacenter → SDN → Zones → Add → VXLAN.

• Zone: vxlanz, Peers = beide VTEP-IPs (203.0.113.10, 198.51.100.20), MTU 1450.
• VNet: vmbr99, Zone vxlanz, Tag = 99 (das ist die VNI).
• Anschließend Apply. VMs hängst du danach einfach an das VNet vmbr99.

Wer es lieber transparent in /etc/network/interfaces hat – das ist exakt das, was das SDN im Hintergrund erzeugt:

auto vxlan99
iface vxlan99 inet manual
    pre-up  ip link add vxlan99 type vxlan id 99 dstport 4789 \
            local 198.51.100.20 remote 203.0.113.10 nolearning
    pre-up  ip link set vxlan99 mtu 1450
    up      ip link set vxlan99 up
    down    ip link del vxlan99

auto vmbr99
iface vmbr99 inet manual
    bridge-ports vxlan99
    bridge-stp off
    bridge-fd 0
    mtu 1450

Damit hängt auch der Proxmox-Host selbst am Overlay und kann mit allen VMs sprechen (praktisch fürs Deployment). Optional gibst du dem Host eine Adresse auf vmbr99.

🔧 MTU ist hier nicht verhandelbar. Underlay 1500 → VXLAN kostet 50 Byte → 1450. Setzt du die VM-Interfaces auf 1500, werden große Pakete still verschluckt (Blackholing): SSH-Login geht, aber ein apt update oder große HTTP-Responses hängen.

6. Teil 4 – Der CHR als DHCP, Gateway und NAT

Der CHR ist das Herz des Overlays: Er verteilt Adressen, ist Default-Gateway und macht das NAT nach außen.

6a. DHCP für IPv4

/ip pool
add name=dhcp_pool1 ranges=10.99.0.2-10.99.0.100

/ip dhcp-server
add name=dhcp1 interface=vxlan_proxmox address-pool=dhcp_pool1 lease-time=1w

/ip dhcp-server network
add address=10.99.0.0/24 gateway=10.99.0.1 dns-server=1.1.1.1,8.8.8.8

# Feste Adressen für die wichtigen VMs (per MAC gepinnt):
/ip dhcp-server lease
add address=10.99.0.100 mac-address=AA:BB:CC:00:01:00 server=dhcp1 comment="admin-pc"
add address=10.99.0.101 mac-address=AA:BB:CC:00:01:01 server=dhcp1 comment="haproxy"
add address=10.99.0.106 mac-address=AA:BB:CC:00:01:06 server=dhcp1 comment="web1"

6b. DHCP für IPv6

/ipv6 pool
add name=v6pool prefix=2001:db8:97::/64 prefix-length=64

/ipv6 dhcp-server
add name=v6dhcp interface=vxlan_proxmox address-pool=v6pool prefix-pool=v6pool

6c. NAT

/ip firewall nat
# Internet-Ausgang für alle internen Hosts:
add chain=srcnat action=masquerade out-interface=ether1

# Eingehend auf den HAProxy (10.99.0.101) umleiten:
add chain=dstnat action=dst-nat protocol=tcp dst-port=80  in-interface=ether1 to-addresses=10.99.0.101 to-ports=80
add chain=dstnat action=dst-nat protocol=tcp dst-port=443 in-interface=ether1 to-addresses=10.99.0.101 to-ports=443
add chain=dstnat action=dst-nat protocol=udp dst-port=443 in-interface=ether1 to-addresses=10.99.0.101 to-ports=443   # QUIC/HTTP-3

IPv6 wird geroutet, nicht genattet – die VMs bekommen globale v6-Adressen aus deinem /64 und sind direkt erreichbar. Für den v6-Default am CHR:

/ipv6 route add dst-address=::/0 gateway=fe80::1%ether1

7. Teil 5 – Die grobe Firewall am CHR

Der CHR muss sich nur um 80/443 kümmern (Hetzner hat davor schon alles andere weggeworfen), und er muss nur grobe Fluten abfangen – das Feintuning macht später HAProxy. Deshalb liegen die Schwellen bewusst hoch (CGNAT-freundlich: hinter einer Mobilfunk-IP sitzen viele echte Nutzer).

IPv4-Filter

/ip firewall filter
# >200 gleichzeitige TCP-Verbindungen pro IP verwerfen (selbstheilend, kein Bann)
add chain=forward action=drop protocol=tcp dst-address=10.99.0.101 dst-port=80,443 \
    connection-state=new connection-limit=200,32 comment="v4: max 200 gleichzeitig/IP"

# dasselbe für QUIC:
add chain=forward action=drop protocol=udp dst-address=10.99.0.101 dst-port=443 \
    connection-state=new connection-limit=200,32 comment="v4 QUIC: max 200 gleichzeitig/IP"

# bereits geblockte Quellen sofort verwerfen:
add chain=forward action=drop src-address-list=proxy-flood comment="Blacklist-Drop"

# bis 150 neue Verbindungen/s pro IP durchlassen …
add chain=forward action=accept protocol=tcp dst-address=10.99.0.101 dst-port=80,443 \
    connection-state=new dst-limit=150/1s,150,src-address/10s comment="Rate ok"

# … darüber für 1 h auf die Blacklist:
add chain=forward action=add-src-to-address-list protocol=tcp dst-address=10.99.0.101 \
    dst-port=80,443 connection-state=new address-list=proxy-flood address-list-timeout=1h

IPv6-Filter

/ipv6 firewall filter
add chain=forward action=drop protocol=tcp dst-address=2001:db8:97::c0de/128 \
    dst-port=80,443 connection-state=new connection-limit=200,64 comment="v6: max 200 je /64"
add chain=forward action=drop protocol=udp dst-address=2001:db8:97::c0de/128 \
    dst-port=443 connection-state=new connection-limit=200,64 comment="v6 QUIC: max 200 je /64"

Warum IPv6 anders ist: Der zweite Wert bei connection-limit=200,64 ist die Netzmaske, auf die die Quelladresse gruppiert wird – hier /64, also ein Endkundenanschluss. Ohne diese Gruppierung würde ein Angreifer einfach Adressen in seinem eigenen /64 rotieren (davon hat er Milliarden) und jedes Limit umgehen. Und eine Rate-Blacklist wie bei v4 gibt es hier bewusst nicht: RouterOS‘ dst-limit klassifiziert nur nach voller /128, wäre also mit /64-Rotation wirkungslos. Das connection-limit mit /64-Gruppierung ist der passendere v6-Schutz.

🛑 Firewall-Änderungen IMMER im Safe Mode – und richtig beenden! Das ist die Falle, die mich am meisten gekostet hat. Details unten. Kurz: Strg-X rein, Regeln setzen/prüfen, zweites Strg-X raus (Meldung [Safe Mode taken off]). Erst dann sind die Regeln dauerhaft.

8. Teil 6 – VPN-Zugang per WireGuard

Der CHR ist auch mein VPN-Konzentrator: Von zu Hause und aus anderen Netzen komme ich über WireGuard direkt ins 10.99.0.0/24, ohne Ports nach außen zu öffnen.

/interface wireguard
add name=wg0 listen-port=51820 mtu=1420

/interface wireguard peers
add interface=wg0 name=home public-key="<PUBKEY-DES-CLIENTS>" \
    allowed-address=10.10.255.30/32 persistent-keepalive=15s

/ip address
add address=10.10.255.29/30 interface=wg0

Größere Standort-Kopplungen fahre ich über OSPF auf dem WireGuard-Link, damit Routen automatisch ausgetauscht werden – mit einem wichtigen Detail:

/routing ospf instance
add name=ospf1 originate-default=never redistribute=connected,static

/routing ospf area
add name=area1 instance=ospf1

/routing ospf interface-template
add area=area1 interfaces=wg0 type=ptp

# Verhindern, dass der CHR eine Default-Route vom Peer lernt und plötzlich
# seinen GESAMTEN Ausgangstraffic durch den Tunnel schickt:
/routing filter rule
add chain=ospf-in rule="if (dst==0.0.0.0/0) { reject }"

Der Block_Default-Filter ist der Trick: Der Tunnel ist für interne Netze erreichbar, wird aber nie zum Default-Gateway des CHR. Sonst liefe dein kompletter Server-Ausgangstraffic durch die Gegenstelle.

9. Teil 7 – HAProxy: TLS, Routing und das Feintuning

Erst hinter dem CHR sitzt die VM, die die eigentliche Arbeit pro Anfrage macht: HAProxy auf 10.99.0.101. Er terminiert TLS, routet nach Hostname/SNI auf die richtige Web-VM und macht das feingranulare Rate-Limiting (Request-Raten, Fehlerraten, Slowloris) – alles, wofür der grobe CHR-Filter zu grob ist.

Minimal-Skelett (/etc/haproxy/haproxy.cfg):

frontend fe_https
    bind :443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1
    bind quic4@:443 ssl crt /etc/haproxy/certs/ alpn h3
    bind quic6@:::443 ssl crt /etc/haproxy/certs/ alpn h3
    http-after-response set-header alt-svc "h3=\":443\"; ma=86400"

    # Host-basiertes Routing über eine Map – WICHTIG: map_str, nicht map_dom!
    use_backend %[req.hdr(host),lower,map_str(/etc/haproxy/maps/hosts.map)]
    default_backend be_default

backend be_qr64
    server s1 10.99.0.109:80
backend be_seekampf
    server s1 10.99.0.108:8000

hosts.map:

qr64.de         be_qr64
seekampf.de     be_seekampf
www.seekampf.de be_seekampf

Zertifikate hole ich per DNS-01-Challenge (Wildcard möglich, kein Port 80 nötig), z. B. mit certbot und dem passenden DNS-Plugin deines Providers. Neue Site = Eintrag in hosts.map + Backend + Zertifikat, das Frontend bleibt unangetastet.

Für QUIC/HTTP-3 in HAProxy noch zwei Pflicht-Details:

global
    cluster-secret  DEIN-GEHEIMNIS    # sonst wird tune.quic....retry-threshold ignoriert
    tune.quic.fe.sock-per-conn  connection

10. Die wichtigsten Stolperfallen

Das hier ist der Teil, den ich mir selbst vorher gewünscht hätte.

🔴 Safe Mode ohne Commit = alles weg

RouterOS‘ Safe Mode ist kein „Speichern“, sondern ein Rollback-Journal. Du betrittst ihn mit Strg-X (Prompt zeigt [Safe]), machst deine Änderungen – aber sie werden nur behalten, wenn du mit einem zweiten Strg-X sauber aussteigst (Meldung [Safe Mode taken off]). Schließt du vorher das Terminal oder reißt die Verbindung ab, macht RouterOS alle Änderungen der Sitzung rückgängig.

Genau das ist mir passiert: Ich hatte meine Firewall-Filter im Safe Mode importiert, getestet, alles lief – dann die Sitzung beendet, ohne zu committen. Wochen später fiel per /export auf, dass nur noch die NAT-Regeln (aus einer committeten Sitzung) da waren, die Filter aber spurlos verschwunden. Außerhalb von Safe Mode schreibt RouterOS sofort persistent – das Risiko existiert nur wegen des nicht-committeten Safe Mode.

Merke: Nach jeder Änderung erst print prüfen, dann zweites Strg-X. Und Persistenz nie an „die Regel ist gerade aktiv“ festmachen – Beleg ist erst ein frischer /export in einer neuen Sitzung (idealerweise nach Reboot).

🔴 MTU-Blackholing im Overlay

Vergisst du die MTU auf 1450 zu setzen, funktioniert der Login (kleine Pakete), aber große Transfers hängen. Symptom: ssh geht, apt update/große Downloads bleiben stehen. Auf allen Overlay-Interfaces (VXLAN, Bridge, VM-NIC) 1450 setzen.

🔴 map_dom ist unsicher fürs Host-Routing

In HAProxy matcht map_dom ein Label an beliebiger Stelle – qr64.de.boese-domain.de würde dann fälschlich bedient. Nimm map_str und trage jede Subdomain explizit in die Map ein.

🔴 VXLAN-Port am falschen Ort offen

UDP 4789 in der Hetzner Cloud Firewall nur für die IP des Dedicated-Servers freigeben, nicht für die Welt – sonst kann jeder Frames in dein L2-Segment einspeisen.

11. Verifikation

# Von außen: kommt HTTP/HTTPS durch die ganze Kette?
curl -I https://deine-domain.de

# HTTP/3 / QUIC prüfen (z. B. https://http3check.net) oder:
curl --http3 -I https://deine-domain.de

Am CHR (RouterOS):

# Greifen die Filter? Trefferzähler statt Fremdlast:
/ip firewall filter print stats
/ipv6 firewall filter print stats

# Wer ist gerade geblockt?
/ip firewall address-list print where list=proxy-flood

# VXLAN-Endpunkt/Peer prüfen:
/interface vxlan print
/interface vxlan vteps print

Auf Proxmox:

ip -d link show vxlan99      # id 99, dstport 4789, mtu 1450?
bridge fdb show dev vxlan99  # ist der remote-VTEP gelernt?
ping 10.99.0.1               # Gateway (CHR) erreichbar?

12. Fazit

Die Architektur wirkt auf den ersten Blick nach viel – aber jede Schicht hat genau eine Aufgabe, und das macht sie robust und wartbar:

• Hetzner-Firewall wirft das Grobe weg,
• der MikroTik CHR ist Router, grobe Firewall, DHCP und VPN in einem – für ein paar Euro Cloud-Server plus Lizenz,
• VXLAN koppelt Cloud und Dedicated ohne Hersteller-Lock-in, mit DC-internem Traffic,
• Proxmox liefert die VMs,
• HAProxy macht das Feintuning, das eine Paket-Firewall nicht kann.

Das Ergebnis: ein einziger, gut kontrollierter Interneteingang vor beliebig vielen Diensten – und ein dedizierter Server, der nie direkt am Netz hängt. Nachbauen lohnt sich, wenn du mehrere Sites/Dienste sauber und sicher hinter einer Stelle bündeln willst.