Proxmox-Dienste hinter CGNAT erreichbar machen: VPS-Gateway + WireGuard + socat

Sie haben zu Hause einen sauberen Proxmox-Cluster aufgebaut, Nextcloud, Vaultwarden, Ihren Mailserver, Ihr Wiki und Ihr Matomo eingerichtet. Und in dem Moment, in dem Sie Port 443 öffnen wollen, um das alles von außen erreichbar zu machen, stellen Sie fest, dass Ihr Provider Ihnen eine IP-Adresse aus dem Block 100.64.0.0/10 zugeteilt hat. Das ist CGNAT (Carrier-Grade NAT): Ihre scheinbare öffentliche IP teilen Sie mit anderen Kunden, Sie kontrollieren die Adressübersetzung nicht mehr, und jeder Versuch einer Portweiterleitung scheitert still.

Die schlechte Nachricht: Diese Lage kommt immer häufiger vor, besonders bei Mobilfunkanbietern (4G/5G als Festnetzersatz, Anschlüsse auf dem Land) und bei günstigen alternativen Providern. Die gute Nachricht: Es gibt mindestens fünf Wege, diese Sperre zu umgehen, und einer davon bewahrt die Souveränität über den Datenverkehr zu 100 %.

Warum CGNAT alles blockiert #

Bei einem klassischen Internetanschluss erhält Ihr Router eine eigene öffentliche IP und übernimmt das NAT zwischen Ihrem privaten LAN und der Außenwelt. Sie können auf dem Router eine Portweiterleitung 443 → 192.168.1.10:443 einrichten, und alles funktioniert. Unter CGNAT ist das anders: Ihr Router erhält eine IP aus dem privaten Block 100.64.0.0/10, und ein vorgelagerter Router beim Provider bündelt mehrere Hundert Anschlüsse hinter einer einzigen öffentlichen IP. Auf diesen Router des Betreibers haben Sie keinen Zugriff.

Die Folge: Ihre ausgehenden Verbindungen funktionieren normal (HTTP, SSH, ausgehendes WireGuard). Aber keine eingehende Verbindung aus dem Internet erreicht Ihr LAN: Der Provider weiß nicht, an welchen Kunden er das TCP-SYN-Paket auf Port 443 schicken soll.

Fünf Umgehungsstrategien #

1. Cloudflare Tunnel #

Die einfachste Konfiguration: Den Daemon cloudflared auf dem internen Host installieren, er baut einen ausgehenden Tunnel zu Cloudflare auf und macht Ihre Dienste unter einer Cloudflare-Subdomain erreichbar. Null Netzwerkkonfiguration, läuft in 10 Minuten.

2. Umgekehrter SSH-Tunnel #

Die schnellste Methode: ssh -N -R 0.0.0.0:443:127.0.0.1:443 user@mon-vps. Der VPS öffnet seinen Port 443 und leitet den gesamten Verkehr in den SSH-Tunnel. Souverän (Ihr VPS), einfach einzurichten. Die Kehrseite: auf Dauer anfällig, spürbar zusätzliche Latenz, und SSH ist nicht für Webverkehr mit hohem Durchsatz optimiert. Gut zur Fehlersuche oder für gelegentlichen Admin-Zugriff, schlecht für die Produktion.

3. frp (Fast Reverse Proxy) #

Open-Source-Werkzeug in Go, Server-Daemon auf dem VPS + Client im Heimnetz. Beliebige TCP- und UDP-Ports lassen sich freigeben. Leistungsfähiger als SSH-R, einfacher als WireGuard. Nur bedingt souverän (abhängig vom Upstream-Projekt), bleibt eine gute Option für alle, die die Komplexität von WireGuard vermeiden wollen.

4. Site-to-Site-VPN von pfSense zu pfSense #

Ansatz aus der Unternehmenswelt für mehrere Standorte: ein pfSense zu Hause, ein pfSense auf einem VPS, IPsec- oder OpenVPN-Tunnel dazwischen. Sehr robust, verlangt aber zwei eigene pfSense-Maschinen und echtes Netzwerkwissen. Überdimensioniert für ein einzelnes Homelab, ideal, um mehrere Firmenstandorte zu verbinden.

5. Europäischer VPS + WireGuard + socat (empfohlen) #

Der ausgewogenste Ansatz: ein VPS bei einem souveränen europäischen Hoster (Hetzner, OVH, Scaleway, Infomaniak) als Gateway, ein verschlüsselter WireGuard-Tunnel zwischen VPS und Proxmox-Host und ein socat-Relais, das den öffentlichen Verkehr auf Port 443 des VPS durch den Tunnel zu den internen Diensten weiterreicht. Ende-zu-Ende-Verschlüsselung, volle Souveränität, native WireGuard-Leistung.

Die Zielarchitektur im Detail #

So laufen die Pakete in der empfohlenen Variante. Ein Endnutzer spricht Port 443 des VPS an, der Verkehr geht durch den öffentlichen Reverse Proxy, dann kapselt socat den TCP-Strom in den verschlüsselten WireGuard-Tunnel, der auf dem Proxmox-Host hinter dem CGNAT wieder austritt, wo ein zweites socat (oder direkt der Dienst im LXC) den Strom entgegennimmt.

WireGuard-Konfiguration auf der Client-Seite (Proxmox) #

WireGuard wird direkt auf dem Proxmox-Host installiert (oder in einem eigenen LXC, wenn Sie es isolieren möchten). Die Konfigurationsdatei sieht so aus.

# /etc/wireguard/wg0.conf (Proxmox-Seite hinter CGNAT)
[Interface]
PrivateKey = <cle_privee_proxmox>
Address = 10.66.66.2/32
MTU = 1280

[Peer]
PublicKey = <cle_publique_du_vps>
Endpoint = vps.exemple.fr:51820
AllowedIPs = 10.66.66.1/32
PersistentKeepalive = 25

Auch die Direktive MTU = 1280 ist wichtig: Sie verhindert die Fragmentierung gekapselter UDP-Pakete in Mobilfunknetzen mit reduzierter MTU. Das ist der Wert, den WireGuard für unzuverlässige Strecken offiziell empfiehlt.

WireGuard-Konfiguration auf der VPS-Seite #

# /etc/wireguard/wg0.conf (öffentliche VPS-Seite)
[Interface]
PrivateKey = <cle_privee_vps>
Address = 10.66.66.1/32
ListenPort = 51820

[Peer]
PublicKey = <cle_publique_du_proxmox>
AllowedIPs = 10.66.66.2/32

# Start beim Booten auf beiden Seiten aktivieren
systemctl enable --now wg-quick@wg0

# Prüfen, ob der Tunnel steht
wg show wg0
# latest handshake muss < 2 Minuten sein

socat-Relais auf dem VPS #

Steht der WireGuard-Tunnel, konfigurieren wir socat auf dem VPS so, dass es den TCP-Verkehr vom öffentlichen Port an die interne IP des Proxmox im Tunnel weiterreicht. Das Ganze kommt in eine systemd-Unit, damit der Dienst sauber neu gestartet werden kann.

# /etc/systemd/system/socat-nextcloud.service
[Unit]
Description=socat relay 443 vers Nextcloud via WireGuard
After=network-online.target wg-quick@wg0.service
Requires=wg-quick@wg0.service

[Service]
Type=simple
ExecStart=/usr/bin/socat -d -d TCP4-LISTEN:8443,reuseaddr,fork TCP4:10.66.66.2:443
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now socat-nextcloud.service
systemctl status socat-nextcloud.service

Öffentlicher Reverse Proxy vor socat #

Um mehrere Dienste über denselben öffentlichen Port 443 zu bedienen, setzen wir Nginx (oder Traefik) davor. Jeder vhost leitet je nach server_name an ein anderes socat weiter.

# /etc/nginx/sites-enabled/nextcloud.conf (auf dem VPS)
server {
    listen 443 ssl http2;
    server_name cloud.exemple.fr;

    ssl_certificate     /etc/letsencrypt/live/cloud.exemple.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/cloud.exemple.fr/privkey.pem;

    client_max_body_size 10G;
    proxy_request_buffering off;

    location / {
        proxy_pass http://127.0.0.1:8443;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Sicherheit des Tunnels #

• Die WireGuard-Schlüssel liegen auf dem Datenträger des Proxmox mit LUKS verschlüsselt, wenn der Host physisch angreifbar ist.
• Die Firewall des VPS lässt nur Port 51820 UDP (WireGuard) und 443 TCP (öffentlicher Reverse Proxy) zu. Admin-SSH ist auf bestimmte Quell-IPs beschränkt.
• Der WireGuard-Tunnel ist selbst verschlüsselt (ChaCha20-Poly1305). Der socat-Verkehr darin ist auf Tunnelebene unverschlüsselt, aber auf Anwendungsebene bereits per TLS verschlüsselt (Nginx beendet TLS gegenüber dem Client, und der interne Dienst nutzt bei Bedarf eigenes TLS).
• Für strikte Ende-zu-Ende-Verschlüsselung ohne jede TLS-Terminierung auf dem VPS verwenden Sie in Nginx ein stream { ssl_preread; } mit Routing nach SNI statt eines klassischen HTTP-vhost.

Grenzen und Fallstricke #

• Zusätzliche Latenz: 5 bis 30 ms, je nach Entfernung des VPS. Platzieren Sie den VPS in derselben Region wie Ihre Nutzer.
• Bandbreite durch die Anbindung des VPS begrenzt: Ein VPS mit 1 Gbit/s reicht völlig, prüfen Sie es aber für Ihre Nutzung.
• Fällt der VPS aus, sind alle freigegebenen Dienste unerreichbar. Planen Sie eine externe Überwachung ein (UptimeRobot oder ein zweiter Reserve-VPS per DNS-Round-Robin).
• Ein VPS der Einstiegsklasse kostet bei souveränen europäischen Hostern etwa 5 bis 10 € pro Monat. Rechnen Sie das in die Gesamtkosten (TCO) des Projekts ein.
• UDP-Dienste (Spiele, VoIP) brauchen eine andere Konfiguration von socat oder Nginx stream: Überlegen Sie gut, welches Protokoll transportiert wird, bevor Sie einen Dienst hinzufügen.

Fazit #

CGNAT ist kein Schicksal. Mit einem europäischen VPS für ein paar Euro im Monat, WireGuard und socat (alle drei Open Source und ausgereift) machen Sie Ihre Proxmox-Dienste öffentlich so leistungsfähig erreichbar wie mit einer direkten festen IP und behalten 100 % der Souveränität über den Datenverkehr. Das ist mehr Arbeit als ein Cloudflare Tunnel, passt aber zum Ansatz: Wer die GAFAM verlässt, lässt sie nicht durch den Keller wieder herein.

Zur Infrastruktur hinter diesem Tunnel beschreibt die PBS-Anleitung, wie Sie den gesamten Bestand mit einer Backup-Richtlinie in Unternehmensqualität schützen, und der Vergleich Proxmox, TrueNAS und Unraid hilft bei der Wahl der richtigen Basis, wenn Sie bei null anfangen.