VPN-Standortvernetzung: tinc vs. StrongSwan für Multi-Site-Infrastruktur

Drei Standorte, fünf Server, ein externer Partner mit strikten Compliance-Anforderungen - und alles soll sicher miteinander kommunizieren. Die Frage “Welches VPN?” ist komplexer als gedacht, denn die Antwort lautet oft: beide.

In diesem Artikel zeige ich, warum tinc und StrongSwan keine Konkurrenten sind, sondern sich ergänzen - und wann welche Lösung die richtige ist.

---

Das Szenario: Typische Multi-Site-Infrastruktur

┌─────────────────────────────────────────────────────────────────────────────┐
│                    MULTI-SITE INFRASTRUKTUR                                  │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│   STANDORT A (HQ)           STANDORT B (Prod)        STANDORT C (Dev)       │
│   ┌─────────────┐           ┌─────────────┐          ┌─────────────┐        │
│   │ Web-Server  │           │ DB-Primary  │          │ CI/CD       │        │
│   │ API-Gateway │           │ App-Server  │          │ Staging     │        │
│   │ Monitoring  │           │ Cache       │          │ Dev-DBs     │        │
│   └──────┬──────┘           └──────┬──────┘          └──────┬──────┘        │
│          │                         │                        │               │
│          └─────────────────────────┼────────────────────────┘               │
│                                    │                                        │
│                            ┌───────▼───────┐                                │
│                            │  INTERNET     │                                │
│                            └───────┬───────┘                                │
│                                    │                                        │
│                            ┌───────▼───────┐                                │
│                            │ PARTNER-API   │  ← IPsec-Anforderung!          │
│                            │ (Bank/Gov)    │                                │
│                            └───────────────┘                                │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

Zwei grundverschiedene Anforderungen:

1. Interne Server-Kommunikation (A ↔ B ↔ C): Flexibel, ausfallsicher, einfach erweiterbar
2. Partner-Anbindung: IPsec (Pflicht), feste IPs, Audit-Logs

---

Entscheidungsmatrix: tinc vs. StrongSwan

Kriterium	tinc	StrongSwan (IPsec)
Topologie	Mesh (jeder mit jedem)	Hub-and-Spoke / Site-to-Site
NAT-Handling	Automatisch, problemlos	NAT-T nötig, manchmal hakelig
Compliance	Selten akzeptiert	ISO 27001, BSI, Banken ✓
Partner-Kompatibilität	Praktisch keine	Cisco, Juniper, Fortinet, …
Konfiguration	Einfach, deklarativ	Komplex, viele Edge-Cases
Skalierung	100+ Nodes ohne Probleme	Pro Tunnel Konfig-Aufwand
Ausfallsicherheit	Automatisches Rerouting	Failover muss konfiguriert werden
Performance	Gut (userspace)	Excellent (kernel-level)

Fazit: tinc für interne Vernetzung, StrongSwan für externe Compliance-Anforderungen.

---

Teil 1: tinc für interne Mesh-Netze

Warum tinc für Server-Kommunikation?

tinc ist ein Mesh-VPN: Jeder Knoten kann mit jedem anderen direkt kommunizieren, auch wenn sie sich erst zur Laufzeit “kennenlernen”. Das macht es ideal für:

• Server, die in verschiedenen Rechenzentren stehen
• Dynamische Infrastruktur (Cloud-VMs kommen und gehen)
• Ausfallsicherheit (Routing um ausgefallene Knoten herum)

Hinweis zur Verschlüsselung: tinc verwendet eine eigene Crypto-Schicht (Curve25519/Ed25519 in aktuellen Versionen) statt klassisches TLS oder IPsec. Für interne Netze ist das völlig ausreichend. In hochregulierten Umgebungen (Banken, Behörden) ist diese “Non-Standard-Crypto” aber oft ein Ausschlusskriterium - deshalb eignet sich tinc primär für interne Vernetzung.

┌─────────────────────────────────────────────────────────────────────────────┐
│                         TINC MESH-TOPOLOGIE                                  │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│                              ┌─────────┐                                    │
│                         ┌────│ Node A  │────┐                               │
│                         │    └─────────┘    │                               │
│                         │         │         │                               │
│                    ┌────▼───┐     │    ┌────▼───┐                           │
│                    │ Node B │◄────┴────│ Node C │                           │
│                    └────┬───┘          └────┬───┘                           │
│                         │                   │                               │
│                         └────────┬──────────┘                               │
│                              ┌───▼───┐                                      │
│                              │Node D │  ← Neuer Node: automatisch im Mesh   │
│                              └───────┘                                      │
│                                                                              │
│   Fällt Node B aus → A kommuniziert direkt mit C und D                      │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

tinc Installation und Basis-Setup

# Debian/Ubuntu
apt install tinc

# CentOS/RHEL
dnf install tinc

# Netzwerk-Verzeichnis erstellen
mkdir -p /etc/tinc/meshnet/hosts

Konfiguration: Der erste Node (Gateway)

Jeder tinc-Node braucht drei Dateien:

1. /etc/tinc/meshnet/tinc.conf - Hauptkonfiguration:

Name = gateway
AddressFamily = ipv4
Interface = tun0
Mode = switch
ConnectTo = prod
ConnectTo = dev

2. /etc/tinc/meshnet/tinc-up - Interface-Start:

#!/bin/bash
ip link set $INTERFACE up
ip addr add 10.100.0.1/24 dev $INTERFACE

3. /etc/tinc/meshnet/tinc-down - Interface-Stop:

#!/bin/bash
ip link set $INTERFACE down

# Ausführbar machen
chmod +x /etc/tinc/meshnet/tinc-{up,down}

4. /etc/tinc/meshnet/hosts/gateway - Host-Definition:

Address = gateway.example.com
Port = 655
Subnet = 10.100.0.1/32

-----BEGIN RSA PUBLIC KEY-----
[wird automatisch generiert]
-----END RSA PUBLIC KEY-----

Schlüssel generieren

# RSA-Schlüsselpaar erzeugen
tincd -n meshnet -K 4096

# Generiert:
# - /etc/tinc/meshnet/rsa_key.priv (geheim!)
# - Public Key wird an hosts/gateway angehängt

Weitere Nodes hinzufügen

Für jeden weiteren Server das gleiche Schema:

Node “prod” (/etc/tinc/meshnet/tinc.conf):

Name = prod
AddressFamily = ipv4
Interface = tun0
Mode = switch
ConnectTo = gateway

Node “prod” (/etc/tinc/meshnet/hosts/prod):

Address = prod.example.com
Port = 655
Subnet = 10.100.0.2/32

-----BEGIN RSA PUBLIC KEY-----
[generierter Key]
-----END RSA PUBLIC KEY-----

Wichtig: Die hosts/*-Dateien müssen auf alle Nodes kopiert werden. Das ist der einzige “manuelle” Schritt bei tinc.

Host-Files verteilen (Automatisierung)

#!/bin/bash
# sync-tinc-hosts.sh

HOSTS_DIR="/etc/tinc/meshnet/hosts"
NODES="gateway prod dev staging"

for node in $NODES; do
    for file in $HOSTS_DIR/*; do
        rsync -avz "$file" "$node:$HOSTS_DIR/"
    done
    ssh $node "systemctl reload tinc@meshnet"
done

Firewall-Regeln

# tinc-Port (Standard: 655/tcp und 655/udp)
ufw allow 655/tcp
ufw allow 655/udp

# Oder mit nftables
nft add rule inet filter input tcp dport 655 accept
nft add rule inet filter input udp dport 655 accept

systemd Service aktivieren

# Service enablen und starten
systemctl enable tinc@meshnet
systemctl start tinc@meshnet

# Status prüfen
systemctl status tinc@meshnet
journalctl -u tinc@meshnet -f

Verbindung testen

# Auf gateway:
ping 10.100.0.2  # prod
ping 10.100.0.3  # dev

# Routing prüfen
ip route show dev tun0

# Aktive Verbindungen
tincd -n meshnet -kUSR1
journalctl -u tinc@meshnet | tail -20

Produktions-Tipps für tinc

1. Automatisches Reconnect bei Problemen:

# In tinc.conf
PingInterval = 30
PingTimeout = 5

2. Mehrere ConnectTo für Redundanz:

# Node kann über mehrere Wege ins Mesh
ConnectTo = gateway
ConnectTo = prod
ConnectTo = backup

3. Private Adressen für Nodes hinter NAT:

# In hosts/nat-node - KEINE Address-Zeile!
# Node verbindet sich nach außen
Subnet = 10.100.0.50/32

---

Teil 2: StrongSwan für Compliance & Partner

Wann IPsec unverzichtbar ist

Sobald externe Partner ins Spiel kommen, ist tinc meist keine Option:

• Banken verlangen IPsec nach PCI-DSS
• Behörden schreiben IKEv2/IPsec vor
• Enterprise-Partner haben Cisco/Juniper-Gateways
• Compliance-Audits akzeptieren nur “Standard-Protokolle”

StrongSwan ist die beste Open-Source-IPsec-Implementierung unter Linux.

StrongSwan Installation

# Debian/Ubuntu
apt install strongswan strongswan-pki libcharon-extra-plugins

# CentOS/RHEL
dnf install strongswan

# Version prüfen
ipsec version

Architektur: Site-to-Site VPN

┌─────────────────────────────────────────────────────────────────────────────┐
│                    STRONGSWAN SITE-TO-SITE                                   │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│   IHRE SEITE                                    PARTNER-SEITE               │
│   ┌─────────────────┐                          ┌─────────────────┐          │
│   │ 192.168.1.0/24  │                          │ 10.200.0.0/24   │          │
│   │                 │                          │                 │          │
│   │  ┌───────────┐  │      IPsec Tunnel        │  ┌───────────┐  │          │
│   │  │ StrongSwan│  │◄════════════════════════▶│  │ Cisco ASA │  │          │
│   │  │ Gateway   │  │      IKEv2 + ESP         │  │ Gateway   │  │          │
│   │  │203.0.113.1│  │                          │  │198.51.100.1│ │          │
│   │  └───────────┘  │                          │  └───────────┘  │          │
│   │                 │                          │                 │          │
│   └─────────────────┘                          └─────────────────┘          │
│                                                                              │
│   Traffic 192.168.1.x → 10.200.0.x geht verschlüsselt durch den Tunnel     │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

Grundkonfiguration: /etc/ipsec.conf

config setup
    charondebug="ike 2, knl 2, cfg 2"
    uniqueids=yes

conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    keyexchange=ikev2
    authby=secret

conn partner-bank
    left=203.0.113.1           # Ihre öffentliche IP
    leftsubnet=192.168.1.0/24   # Ihr internes Netz
    leftid=@vpn.ihre-firma.de   # Ihre VPN-ID

    right=198.51.100.1          # Partner-IP
    rightsubnet=10.200.0.0/24   # Partner-Netz
    rightid=@vpn.partner.com    # Partner-ID

    ike=aes256-sha256-modp2048  # IKE Phase 1
    esp=aes256-sha256           # ESP Phase 2

    # Modern (wenn Partner es unterstützt):
    # ike=aes256gcm16-prfsha256-ecp384
    # esp=aes256gcm16-ecp384
    # (GCM + ECP sind schneller und gelten als zukunftssicher,
    #  aber viele Banken/Behörden hängen noch an MODP)

    auto=start
    dpdaction=restart
    dpddelay=30s
    dpdtimeout=120s

Pre-Shared Key: /etc/ipsec.secrets

# Syntax: LocalID RemoteID : PSK "geheimer-schlüssel"
@vpn.ihre-firma.de @vpn.partner.com : PSK "c0mpl3x-pr3-sh4r3d-k3y-m1nd3st3ns-32-z31ch3n"

# Berechtigungen sichern!
chmod 600 /etc/ipsec.secrets

Alternative: Zertifikatsbasierte Authentifizierung

Für höhere Sicherheit (und wenn der Partner es unterstützt):

1. CA und Zertifikate erstellen:

# CA erstellen
ipsec pki --gen --type rsa --size 4096 --outform pem > caKey.pem
ipsec pki --self --ca --lifetime 3650 \
    --in caKey.pem --type rsa \
    --dn "CN=VPN CA" \
    --outform pem > caCert.pem

# Server-Zertifikat
ipsec pki --gen --type rsa --size 4096 --outform pem > serverKey.pem
ipsec pki --pub --in serverKey.pem --type rsa | \
    ipsec pki --issue --lifetime 730 \
    --cacert caCert.pem --cakey caKey.pem \
    --dn "CN=vpn.ihre-firma.de" \
    --san vpn.ihre-firma.de \
    --flag serverAuth --flag ikeIntermediate \
    --outform pem > serverCert.pem

2. Zertifikate installieren:

cp caCert.pem /etc/ipsec.d/cacerts/
cp serverCert.pem /etc/ipsec.d/certs/
cp serverKey.pem /etc/ipsec.d/private/

chmod 600 /etc/ipsec.d/private/*

3. Konfiguration anpassen:

conn partner-bank
    # ... wie oben, aber:
    leftauth=pubkey
    leftcert=serverCert.pem
    rightauth=pubkey
    rightca="CN=Partner CA"

Firewall für IPsec

# IKE (UDP 500) und NAT-T (UDP 4500)
ufw allow 500/udp
ufw allow 4500/udp

# ESP Protokoll
ufw allow proto esp

# Oder mit nftables
nft add rule inet filter input udp dport { 500, 4500 } accept
nft add rule inet filter input ip protocol esp accept

IPsec starten und debuggen

# Service starten
systemctl enable strongswan-starter
systemctl start strongswan-starter

# Status aller Verbindungen
ipsec statusall

# Verbindung manuell starten
ipsec up partner-bank

# Live-Debugging
journalctl -u strongswan-starter -f

# Detailliertes Debugging aktivieren
# In /etc/ipsec.conf:
# charondebug="ike 4, knl 4, cfg 4, net 4, esp 4, chd 4"

Typische Probleme und Lösungen

Problem 1: NAT zwischen den Gateways

# NAT-Traversal aktivieren (Standard, aber explizit)
conn partner-bank
    # ...
    forceencaps=yes   # ESP immer in UDP kapseln

Problem 2: Partner verwendet andere Cipher

# Unterstützte Algorithmen anzeigen
ipsec listcounters

# Flexible Cipher-Verhandlung
ike=aes256-aes128-sha256-sha1-modp2048-modp1024
esp=aes256-aes128-sha256-sha1

Problem 3: Verbindung bricht nach Rekey ab

# Rekey-Zeiten verlängern
ikelifetime=24h
keylife=8h
rekeymargin=30m

Problem 4: Traffic geht nicht durch den Tunnel

# Routing prüfen
ip route show

# IPsec-Policies prüfen
ip xfrm policy show
ip xfrm state show

# Kernel-Forwarding aktiv?
sysctl net.ipv4.ip_forward
# Falls 0: sysctl -w net.ipv4.ip_forward=1

---

Teil 3: Hybrid-Setup - Beide VPNs kombinieren

Architektur-Überblick

┌─────────────────────────────────────────────────────────────────────────────┐
│                    HYBRID VPN ARCHITEKTUR                                    │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                         TINC MESH (10.100.0.0/24)                    │    │
│  │                                                                      │    │
│  │   ┌──────────┐       ┌──────────┐       ┌──────────┐                │    │
│  │   │ Gateway  │◄─────▶│   Prod   │◄─────▶│   Dev    │                │    │
│  │   │10.100.0.1│       │10.100.0.2│       │10.100.0.3│                │    │
│  │   └────┬─────┘       └──────────┘       └──────────┘                │    │
│  │        │                                                             │    │
│  └────────┼─────────────────────────────────────────────────────────────┘    │
│           │                                                                   │
│           │ StrongSwan (IPsec)                                               │
│           │                                                                   │
│   ┌───────▼───────┐                      ┌─────────────────┐                 │
│   │   IPsec GW    │◄════════════════════▶│  Partner (Bank) │                 │
│   │ 203.0.113.1   │     IKEv2 Tunnel     │  198.51.100.1   │                 │
│   └───────────────┘                      └─────────────────┘                 │
│                                                                              │
│   Routing: 10.200.0.0/24 → IPsec Tunnel                                     │
│            10.100.0.0/24 → tinc Mesh                                        │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

Gateway-Konfiguration für beide VPNs

Der Gateway-Server betreibt sowohl tinc als auch StrongSwan:

Netzwerk-Interfaces:

eth0:  203.0.113.1/24  (öffentlich)
eth1:  192.168.1.1/24  (intern)
tun0:  10.100.0.1/24   (tinc mesh)

Routing-Tabelle:

# tinc-Netz
ip route add 10.100.0.0/24 dev tun0

# IPsec installiert automatisch Policy-Routes
# Prüfen mit:
ip xfrm policy show

Zugriff vom Mesh auf Partner-Netz

Wenn Prod-Server (10.100.0.2) auf das Partner-Netz (10.200.0.0/24) zugreifen soll:

1. Auf dem Gateway - IPsec-Config erweitern:

conn partner-bank
    # ...
    leftsubnet=192.168.1.0/24,10.100.0.0/24  # Beide Netze!

Achtung: Sobald Mesh-Traffic über das IPsec-Gateway geroutet wird, muss klar geregelt sein, welche Quell-IPs überhaupt ins Partnernetz dürfen. “Alles aus dem Mesh durchlassen” ist fast immer falsch - regeln Sie das explizit per Firewall. Sonst debuggen Sie nachts um 3 Uhr, warum der Dev-Server plötzlich auf die Produktions-API der Bank zugreift.

2. Auf dem Gateway - IP-Forwarding:

# /etc/sysctl.d/99-vpn.conf
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

3. Auf Mesh-Nodes - Route zum Partner:

# In /etc/tinc/meshnet/tinc-up ergänzen:
ip route add 10.200.0.0/24 via 10.100.0.1

Firewall-Regeln für den Gateway

#!/bin/bash
# /etc/nftables.d/vpn-gateway.nft

table inet vpn {
    chain forward {
        type filter hook forward priority 0; policy drop;

        # tinc Mesh intern
        iifname "tun0" oifname "tun0" accept

        # Mesh → Partner (über IPsec)
        iifname "tun0" ip daddr 10.200.0.0/24 accept

        # Partner → interne Server (wenn nötig)
        ip saddr 10.200.0.0/24 ip daddr 192.168.1.0/24 accept

        # Established/Related
        ct state established,related accept
    }
}

---

Teil 4: Monitoring und Troubleshooting

tinc Status überwachen

#!/bin/bash
# /usr/local/bin/tinc-status.sh

NETNAME="meshnet"

echo "=== tinc $NETNAME Status ==="
echo ""

# Aktive Verbindungen anzeigen
tincd -n $NETNAME -kUSR1
sleep 1
journalctl -u tinc@$NETNAME --since "1 minute ago" | grep -E "(Added|Deleted) "

echo ""
echo "=== Erreichbare Nodes ==="
for ip in 10.100.0.{1..10}; do
    if ping -c1 -W1 $ip &>/dev/null; then
        echo "✓ $ip erreichbar"
    fi
done

StrongSwan Monitoring

#!/bin/bash
# /usr/local/bin/ipsec-status.sh

echo "=== IPsec Tunnel Status ==="
echo ""

ipsec statusall | grep -E "(ESTABLISHED|INSTALLED|partner)"

echo ""
echo "=== Traffic Statistiken ==="
cat /proc/net/xfrm_stat | head -10

echo ""
echo "=== Letzte Rekey-Events ==="
journalctl -u strongswan-starter --since "1 hour ago" | grep -i rekey | tail -5

Prometheus/Grafana Integration

tinc Exporter (einfaches Script):

#!/usr/bin/env python3
# /usr/local/bin/tinc-exporter.py

import subprocess
import time
from prometheus_client import start_http_server, Gauge

NODES_UP = Gauge('tinc_nodes_up', 'Number of connected tinc nodes')
MESH_LATENCY = Gauge('tinc_mesh_latency_ms', 'Latency to mesh node', ['node'])

def collect():
    # Anzahl aktiver Nodes
    result = subprocess.run(
        ['tincd', '-n', 'meshnet', '-kUSR1'],
        capture_output=True
    )
    # Parse journalctl output...
    # (vereinfacht)

    # Latenz messen
    nodes = {'gateway': '10.100.0.1', 'prod': '10.100.0.2'}
    for name, ip in nodes.items():
        result = subprocess.run(
            ['ping', '-c', '3', '-q', ip],
            capture_output=True, text=True
        )
        # Parse avg latency...
        MESH_LATENCY.labels(node=name).set(latency)

if __name__ == '__main__':
    start_http_server(9101)
    while True:
        collect()
        time.sleep(30)

Alerting-Regeln (Prometheus)

# /etc/prometheus/rules/vpn.yml
groups:
  - name: vpn
    rules:
      - alert: TincNodeDown
        expr: tinc_nodes_up < 3
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "tinc Mesh degradiert"
          description: "Nur {{ $value }} Nodes im Mesh"

      - alert: IPsecTunnelDown
        expr: strongswan_ike_sa_established == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "IPsec Tunnel zu Partner down"

Hinweis: Die Metrik strongswan_ike_sa_established setzt einen StrongSwan-Exporter voraus (z.B. strongswan_exporter) oder eigene Textfile-Collector-Metriken via ipsec statusall-Parsing.

---

Fazit: Die richtige VPN-Strategie

tinc ist ideal für:

• Interne Server-Kommunikation über mehrere Standorte
• Dynamische Infrastruktur (Cloud, Kubernetes)
• Ausfallsichere Mesh-Topologie
• Schnelle Einrichtung neuer Nodes

StrongSwan ist unverzichtbar für:

• Partner-Anbindungen mit Compliance-Anforderungen
• Interoperabilität mit Enterprise-Hardware
• Audit-relevante Verbindungen (Banken, Behörden)
• Höchste Sicherheitsanforderungen (Zertifikate, HSM)

Die Kombination macht Sinn:

• Gateway-Server mit beiden VPNs
• tinc für internes Mesh, StrongSwan für externe Partner
• Routing zwischen beiden Welten über den Gateway

Der Aufwand für ein Hybrid-Setup ist überschaubar - und Sie haben das Beste aus beiden Welten: Die Flexibilität von tinc und die Compliance-Fähigkeit von IPsec.

---

Weiterführende Ressourcen

• tinc Manual
• StrongSwan Dokumentation
• BSI TR-02102 (Kryptografische Vorgaben)
• Cisco IPsec Interoperability Guide