--- title: "Strongswan-VPN in Kubernetes: Externe Dienste sicher einbinden" description: "✅ Schritt-für-Schritt: So richtest Du eine VPN-Verbindung mit Strongswan in K8s ein. Sicher, flexibel & cloud-native." canonical_url: "https://www.blueshoe.de/blog/vpn-kubernetes-strongswan/" --- In manchen Fällen benötigt es eine VPN-Anbindung zu einem externen Service - was mit Kubernetes tricky sein kann. In diesem Beitrag zeigen wir, wie man mit StrongSwan einen IPsec-Tunnel aus Kubernetes heraus zu einem externen Dienst aufbaut und dabei Nginx als Reverse-Proxy nutzt. Das Setup ist klar strukturiert, gut wartbar und unterscheidet dynamisch zwischen Staging und Production. ![IPsec-VPN-Tunnel aus Kubernetes heraus sicher aufbauen](/img/blog/kubernetes-strongswan.svg) - [IPSec](https://de.wikipedia.org/wiki/IPsec) und VPN - [Strongswan](https://strongswan.org/) - [Internet Key Exchange (IKE)](https://de.wikipedia.org/wiki/IPsec#Automatische_Schl%C3%BCsselverwaltung) Solltest du Fragen haben, oder dir etwas unklar sein, kannst du die Kommentarfunktion unter dem Artikel nutzen. ## 1. Problemstellung Manchmal steht eine wichtige Datenbank nicht im eigenen Cluster, sondern hinter einer Firewall auf einem externen Server. Der Zugriff erfolgt nur über ein VPN – zum Beispiel via IPSec mit einer WatchGuard-Appliance. Die Herausforderung: Wie erreichen Anwendungen im Cluster diesen Service zuverlässig und sicher? ## 2. Zielbild Ziel war es, eine schlanke und wartbare Lösung zu schaffen, die: - von innerhalb des Clusters auf fest definierte externe Services via VPN zugreifen kann, - klar zwischen Staging- und Produktionszugängen unterscheidet, - flexibel konfigurierbar bleibt, - mit Kubernetes-Standards arbeitet (Probes, Services, ConfigMaps etc.). ![Das Strongswan Kubernetes Setup](/img/blog/strongswan-k8s.png) ## 3. Lösungsidee Wir haben einen dedizierten Pod mit Strongswan und Nginx aufgesetzt: - Strongswan übernimmt den Aufbau des IPSec-Tunnels zum externen VPN-Endpunkt. - Nginx fungiert als TCP-Proxy und leitet Anfragen aus dem Cluster an den externen Service weiter. - Je nach Umgebung (Staging oder Production) wird der Nginx entsprechend konfiguriert. Innerhalb des Clusters können andere Services einfach via `ClusterIP` auf den Nginx zugreifen, der dann die Verbindung über das VPN übernimmt. ## 4. Umsetzung in Kubernetes ### a) Dockerfile Im Container laufen Nginx und Strongswan nebeneinander. Ein Startscript entscheidet je nach `ENVIRONMENT`-Variable, welche Konfigurationsdateien verwendet werden. ```dockerfile FROM nginx:1.27.3-alpine RUN apk add --no-cache strongswan netcat-openbsd ... CMD ["/scripts/startup.sh"] ``` ### b) Nginx-Konfiguration Für Production gibt es eine einzige TCP-Weiterleitung (z. B. auf Port 8080), im Staging sind es zwei (8080 + 8081 für Prod/Staging). ```nginx stream { upstream ext-db-production { server NGINX_EXTDB_IP_PRODUCTION:NGINX_EXTDB_PORT_PRODUCTION; } server { listen 8080; proxy_pass ext-db-production; } ... } ``` ### c) VPN-Setup mit Strongswan Der Tunnel wird über `swanctl.conf` und Umgebungsvariablen dynamisch konfiguriert. So können IP-Adressen, PSK und Subnetze per Helm Template eingespielt werden. ```bash connections { k8s-ext-db { remote_addrs = SWANCTL_CONF_REMOTE_ADDRS local { auth = psk id = SWANCTL_CONF_LOCAL_ID } remote { auth = psk } children { net-net { local_ts = SWANCTL_CONF_LOCAL_TS remote_ts = SWANCTL_CONF_REMOTE_TS esp_proposals = SWANCTL_CONF_ESP_PROPOSALS ... } } version = 2 proposals = SWANCTL_CONF_PROPOSALS ... } } secrets { ike-k8s-nors { id-k8s = SWANCTL_CONF_LOCAL_ID secret = SWANCTL_CONF_SECRET_PSK_TOKEN } } ``` Die großgeschriebenen Variablen in allen Config-Dateien werden vom Startup Script mit Werten aus den Umgebungsvariablen ersetzt. Dadurch kann der Pod für verschiedene Umgebungen dynamisch konfiguriert werden. Die Werte könnten natürlich auch direkt angegeben werden. Das Startup Script führt dann nur noch folgende Commands aus um die VPN Verbindung aufzubauen: ```bash swanctl --load-all ipsec up k8s-ext-db ``` ### d) Health-Probes Ein Shell-Skript prüft regelmäßig: - ob die VPN-Ziel-IP erreichbar ist: `nc -z -w 1 $PROBE_STRONGSWAN_IP $PROBE_STRONGSWAN_PORT` - ob der interne Nginx eine `/healthz`-Route bedient: `curl -f -LI $PROBE_NGINX_IP:$PROBE_NGINX_PORT/healthz` Nur wenn beide Bedingungen erfüllt sind, wird der Exit-Code 0 zurückgeben. Damit lassen sich die Pods gut in Kubernetes überwachen und restarten, falls etwas hängt. ## 5. Besonderheiten - Der Pod benötigt die `NET_ADMIN`-Capability, damit Strongswan Routing-Tables setzen darf. - Production und Staging unterscheiden sich nicht nur in den Zielsystemen, sondern auch in der Menge der angebundenen externen Dienste. - Der gesamte Tunnel läuft in einem dedizierten Service – andere Pods im Cluster brauchen davon nichts zu wissen. ## 6. Pod Manifest Hier ein Beispiel für das Pod-Manifest: ```yaml apiVersion: v1 kind: Pod metadata: name: vpn-client namespace: vpn spec: containers: - name: vpn image: your-vpn-image:1.0.0 imagePullPolicy: Always envFrom: - configMapRef: name: vpn-client-configmap ports: - containerPort: 8080 name: ext-db-prod protocol: TCP livenessProbe: exec: command: - /scripts/probe.sh failureThreshold: 3 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 2 readinessProbe: exec: command: - /scripts/probe.sh failureThreshold: 1 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 2 startupProbe: exec: command: - /scripts/probe.sh failureThreshold: 40 periodSeconds: 5 successThreshold: 1 timeoutSeconds: 2 securityContext: capabilities: add: - NET_ADMIN ``` ## 7. Fazit Die Kombination aus Strongswan und Nginx ist eine robuste, leichtgewichtige Möglichkeit, externe Dienste über VPN in Kubernetes anzubinden. Die strikte Trennung nach Umgebungen, flexible Helm-Templates und Kubernetes-Probes machen die Lösung production-ready – ohne Overhead durch zusätzliche Tools. ## 8. Häufige Fragen ### 1. Warum brauche ich ein VPN in Kubernetes? Ein VPN ermöglicht sichere Verbindungen zwischen deinem Cluster und externen Systemen, etwa Datenbanken oder Legacy-Systemen, die nicht öffentlich erreichbar sind. Es ist besonders sinnvoll, wenn sensible Daten übertragen werden oder direkte IP-Kommunikation erforderlich ist. ### 2. Was ist StrongSwan und warum eignet es sich für Kubernetes? StrongSwan ist eine etablierte Open-Source-VPN-Lösung für IPsec-basierte Tunnel. Sie ist leichtgewichtig, zuverlässig und lässt sich durch ihre Modularität gut in containerisierte Umgebungen wie Kubernetes integrieren. ### 3. Wie integriere ich StrongSwan in Kubernetes? StrongSwan kann als dediziertes Deployment in einem Pod betrieben werden. Über eine angepasste Netzwerkkonfiguration und iptables-Routing wird der Traffic durch das VPN geleitet. NGINX oder andere Proxies übernehmen dabei das Routing zum Zielsystem über das VPN. ### 4. Gibt es Helm-Charts für StrongSwan in Kubernetes? Nein, es gibt keine offiziellen Helm-Charts. Die meisten Setups nutzen eigene Deployments mit Docker-Images, Konfigurationsdateien und init-Skripten. Das kann zwar mühselig sein, ermöglicht aber maximale Flexibilität bei der VPN-Einrichtung. ### 5. Welche Alternativen zu StrongSwan gibt es? Je nach Anforderungen kannst du auch WireGuard (modern, schnell), OpenVPN (bewährt, aber komplexer) oder VPN-Services von Cloud-Anbietern wie AWS Site-to-Site VPN oder Azure VPN Gateway einsetzen. ## Sitemap See the full [sitemap](/sitemap.md) for all pages.