imported>TechCorner-Redaktion: Neuer Artikel: tinc-Plugin (os-tinc 1.8, tinc 1.0.37), Stand OPNsense 26.7

2026-10-06T00:00:00Z

Neuer Artikel: tinc-Plugin (os-tinc 1.8, tinc 1.0.37), Stand OPNsense 26.7

Neue Seite

{{Steckbrief
| gilt_fuer = OPNsense 26.1/26.7 mit Plugin os-tinc 1.8 (tinc 1.0.37)
| bereich = IT-Security
| dauer = ca. 30 Minuten für zwei Standorte, je weiterem Standort ca. 10 Minuten
| rechte = Administrator (OPNsense-WebUI) auf allen beteiligten Firewalls
| stand = Oktober 2026
}}
'''tinc''' ist ein seit vielen Jahren bewährtes Open-Source-'''[[VPN]]''', das mehrere Standorte zu einem '''vermaschten Netz (Mesh)''' verbindet: Jeder Knoten kennt die anderen, Verbindungen werden automatisch aufgebaut, und fällt ein Knoten aus, findet tinc selbstständig andere Wege. Neben gerouteten Netzen (Layer 3) beherrscht tinc auch einen '''Switch-Modus (Layer 2)''', der entfernte Standorte wie an einem gemeinsamen Ethernet-Switch verbindet. Mit dem Plugin '''os-tinc''' lässt sich tinc direkt auf der OPNsense betreiben.

{{Hinweis|'''Einordnung Stand 2026:''' Das Plugin nutzt tinc 1.0. Die im März 2026 erschienene Version 1.0.37 ist laut Projektseite „höchstwahrscheinlich die letzte Version von tinc 1.0“; der Nachfolger 1.1 ist seit 2021 im Vorabstadium (1.1pre18). tinc 1.0 verwendet ein älteres Kryptografie-Design (RSA-Schlüssel, CBC-Verschlüsselung mit HMAC). Für '''neue Projekte''' sind [[WireGuard]], [[OPNsense - IPsec Site-to-Site route-based|IPsec (route-based)]] oder ein Mesh-Overlay wie [[OPNsense - NetBird-Plugin|NetBird]] in der Regel die zukunftssicherere Wahl. tinc bleibt sinnvoll für bestehende tinc-Netze und für Szenarien, die ein einfaches '''Layer-2-Mesh''' ohne zentrale Steuerung benötigen.}}

== Wie tinc funktioniert ==
* '''Dezentral:''' Es gibt keinen zentralen Server. Jeder Knoten hat ein Schlüsselpaar; die öffentlichen Schlüssel der Partner werden als ''Hosts'' hinterlegt.
* '''Meta-Verbindungen und Datenverkehr:''' Knoten bauen TCP-Verbindungen (Standardport '''655''') für den Austausch von Routing-Informationen auf. Nutzdaten werden möglichst '''direkt per UDP''' (ebenfalls Port 655) zwischen den beteiligten Knoten übertragen – auch wenn diese nicht direkt miteinander „verbunden“ wurden.
* '''Automatisches Mesh:''' Es genügt, wenn jeder Knoten zu einem oder zwei anderen eine Verbindung herstellt (''Connect To''); tinc lernt die übrigen Knoten und Netze automatisch.
* '''Modi:''' Im '''Router'''-Modus (Standard) gibt jeder Knoten an, welche Subnetze hinter ihm liegen. Im '''Switch'''-Modus arbeitet tinc wie ein virtueller Ethernet-Switch (Layer 2, inklusive Broadcast).

[[Datei:OPNsense-Tinc-Mesh.png|thumb|center|750px|tinc-Mesh mit drei OPNsense-Firewalls: Jede Firewall verbindet sich zu mindestens einem Partner, tinc lernt die übrigen Knoten automatisch; Nutzdaten fließen direkt per UDP 655 zwischen den Standorten.]]

== Beispiel-Szenario ==
{| class="wikitable"
! Knoten (Hostname) !! Öffentliche Adresse !! Tinc-Netzadresse !! Lokales LAN
|-
| <code>zentrale</code> || <code>vpn.example.com</code> || <code>10.99.0.1</code> || <code>192.168.10.0/24</code>
|-
| <code>filiale1</code> || dynamisch || <code>10.99.0.2</code> || <code>192.168.20.0/24</code>
|-
| <code>filiale2</code> || <code>203.0.113.50</code> || <code>10.99.0.3</code> || <code>192.168.30.0/24</code>
|}
Netzname: <code>firmennetz</code>, Tinc-Netz: <code>10.99.0.0/24</code> (Router-Modus).

== Schritt 1: Plugin installieren ==
Auf allen Firewalls '''System → Firmware → Plugins''': '''os-tinc''' installieren und die Seite neu laden. Die Konfiguration befindet sich unter '''VPN → Tinc → Configuration''', das Protokoll unter ''VPN → Tinc → Log File''.

== Schritt 2: Netzwerk auf jedem Knoten anlegen ==
'''VPN → Tinc → Configuration''', Reiter ''Networks'' → '''+''' (Beispiel Zentrale):
{| class="wikitable"
! Feld !! Wert !! Hinweis
|-
| Enabled || an ||
|-
| Mode || router || ''switch'' für Layer 2
|-
| Network Name || <code>firmennetz</code> || auf allen Knoten identisch, nur Buchstaben/Ziffern
|-
| Network || <code>10.99.0.1/24</code> || eigene Tinc-Adresse + Maske des gesamten Tinc-Netzes
|-
| PingTimeout || 5 (Standard) ||
|-
| StrictSubnets || nach Bedarf || nur Subnetze aus den lokal hinterlegten Host-Einträgen akzeptieren – empfehlenswert, damit kein Knoten fremde Netze „beanspruchen“ kann
|-
| Cipher || <code>aes-256-cbc</code> (Standard) || auf allen Knoten gleich; niemals ''none''
|-
| path MTU Discovery || an || vermeidet Fragmentierungsprobleme
|-
| Hostname (This Host) || <code>zentrale</code> || eindeutiger Name dieses Knotens
|-
| Ext. Address / Ext. Port || <code>vpn.example.com</code> / 655 || öffentliche Adresse; bei dynamischer IP DNS-Name verwenden oder leer lassen, wenn der Knoten nur selbst verbindet
|-
| Subnet || <code>192.168.10.0/24, 10.99.0.1/32</code> || Netze hinter diesem Knoten plus eigene Tinc-Adresse (im Router-Modus Pflicht)
|-
| Private key / Public key || leer || beim Speichern werden Schlüssel erzeugt
|}
Nach dem Speichern den erzeugten '''Public key''' kopieren – er wird auf den anderen Knoten benötigt. Auf den Filialen entsprechend mit eigener Adresse, eigenem Hostnamen und eigenem Subnetz verfahren.

== Schritt 3: Partner (Hosts) eintragen ==
Reiter ''Hosts'' → '''+''' – auf jedem Knoten für jeden anderen Knoten einen Eintrag (Beispiel auf der Zentrale für Filiale 2):
{| class="wikitable"
! Feld !! Wert
|-
| Network || firmennetz
|-
| Hostname || <code>filiale2</code> (exakt wie dort konfiguriert)
|-
| Ext. Address / Ext. Port || <code>203.0.113.50</code> / 655 (leer bei dynamischer IP)
|-
| Subnet || <code>192.168.30.0/24</code> und dessen Tinc-Adresse <code>10.99.0.3/32</code>
|-
| Public key || öffentlicher Schlüssel von Filiale 2
|-
| Cipher || identisch zum Netzwerk
|-
| Connect To || auf Knoten mit dynamischer IP aktivieren, um aktiv zu Knoten mit fester Adresse zu verbinden
|}
'''Faustregel:''' Knoten mit dynamischer IP verbinden sich aktiv (''Connect To'') zu den Knoten mit fester Adresse. Es reicht, wenn jeder Knoten mindestens eine erfolgreiche Verbindung hat; mit zwei Verbindungen pro Knoten bleibt das Mesh auch beim Ausfall eines Partners zusammen. '''Apply''' auf allen Knoten.

== Schritt 4: Firewall-Regeln und Interface ==
* '''WAN''' (''Firewall → Rules'', Interface ''WAN''): '''TCP und UDP 655''' auf ''This Firewall'' erlauben – idealerweise mit den bekannten Partneradressen als Quelle; bei dynamischen Partnern von ''any''.
* '''Tunnelverkehr:''' Das Plugin legt pro Netzwerk ein Gerät <code>tinc''ID''</code> an (z. B. <code>tinc1</code>). Unter '''Interfaces → Assignments''' zuweisen (Beschreibung z. B. ''TINC''), aktivieren, ohne IP-Konfiguration, und unter ''Firewall → Rules'' auf diesem Interface den gewünschten Verkehr zwischen den Standorten erlauben (z. B. Quelle <code>192.168.20.0/24</code> → Ziel <code>192.168.10.0/24</code>).
* '''Routen:''' tinc setzt die Routen für die Subnetze der Partner automatisch. Mit ''Disable subnet routes'' lässt sich das abschalten, z. B. für eigene Routing-Entscheidungen über Gateways und Policy-Based Routing.

== Schritt 5: Testen ==
* '''VPN → Tinc → Log File''' zeigt Verbindungsaufbau (''Connection with … activated'') und Fehler; für Details unter ''Debug'' die Stufe erhöhen.
* Von einem Client in Filiale 1 einen Server in der Zentrale anpingen; anschließend Filiale 1 → Filiale 2 testen – auch ohne direkt konfigurierte Verbindung sollte der Verkehr fließen.

== Layer-2-Modus (Switch) ==
Im Modus '''switch''' verhält sich tinc wie ein verteilter Ethernet-Switch: Statt Subnetze anzugeben, wird das Tinc-Interface z. B. per '''Bridge''' (''Interfaces → Devices → Bridge'') mit einem LAN- oder VLAN-Interface verbunden. Damit lassen sich Broadcast-abhängige Anwendungen, Altsysteme oder ein gemeinsames VLAN über Standorte hinweg betreiben. Nachteile: Broadcast- und Multicast-Verkehr läuft über alle Standorte, und Fehler wirken sich auf das gesamte Netz aus – Layer-2-Kopplungen daher sparsam einsetzen. Eine Alternative für virtuelles Ethernet ist [[ZeroTier – virtuelle Netzwerke mit Layer-2-Overlay|ZeroTier]].

== tinc im Vergleich ==
{| class="wikitable"
! Kriterium !! tinc (os-tinc) !! [[OPNsense - IPsec Site-to-Site route-based|IPsec route-based]] !! WireGuard (OPNsense-Kern) !! [[NetBird – Zero-Trust-Netzwerk mit WireGuard|NetBird]]
|-
| Topologie || automatisches Mesh || Punkt-zu-Punkt-Tunnel || Punkt-zu-Punkt / Hub || automatisches Mesh
|-
| Layer 2 möglich || ja (switch) || nein || nein || nein
|-
| Zentrale Steuerung || keine || keine || keine || Management-Server mit SSO
|-
| Kryptografie || tinc 1.0: RSA, AES-CBC + HMAC || IKEv2, AES-GCM || Curve25519, ChaCha20-Poly1305 || WireGuard
|-
| Weiterentwicklung || 1.0 auslaufend, 1.1 Vorabversion || aktiv || aktiv || aktiv
|}

== Sicherheitsempfehlungen ==
* '''Cipher''' auf allen Knoten auf <code>aes-256-cbc</code> (oder ein anderes starkes Verfahren) setzen – nie ''none''.
* '''StrictSubnets''' aktivieren, damit nur die lokal hinterlegten Netze akzeptiert werden.
* '''Private Schlüssel''' nur auf dem jeweiligen Knoten belassen; bei Verdacht auf Kompromittierung neue Schlüssel erzeugen und auf allen Partnern aktualisieren.
* '''Firewall-Regeln''' auf dem Tinc-Interface gezielt setzen – ein Mesh verbindet sonst schnell „jeden mit jedem“.
* Bestehende tinc-Netze '''mittelfristig migrieren''', z. B. auf IPsec route-based oder WireGuard; Logs zentral auswerten, etwa in einem [https://www.max-it.de/it-services/siem-open-source/ Open-Source-SIEM auf Wazuh-Basis].

== Typische Probleme ==
{| class="wikitable"
! Symptom !! Lösung
|-
| ''Peer … had unknown identity'' / Verbindung wird abgelehnt || Hostname oder Public key im Host-Eintrag stimmt nicht mit dem Partner überein.
|-
| Meta-Verbindung steht, aber kein Datenverkehr || UDP 655 blockiert (WAN-Regel oder vorgeschalteter Router); Cipher unterschiedlich; Firewall-Regel auf dem Tinc-Interface fehlt.
|-
| Netze eines Standorts nicht erreichbar || Subnet beim Knoten bzw. im Host-Eintrag fehlt; mit StrictSubnets muss das Subnetz lokal im Host-Eintrag stehen.
|-
| Große Übertragungen hängen || path MTU Discovery aktivieren, MSS-Clamping über ''Firewall → Settings → Normalization''.
|-
| Dienst startet nicht || Netzwerkname mit Sonderzeichen; Pflichtfeld Subnet im Router-Modus leer.
|}

== Fazit ==
tinc ist ein elegantes, dezentrales Mesh-VPN, das auf der OPNsense mit wenigen Einträgen mehrere Standorte automatisch vernetzt – inklusive optionalem Layer-2-Betrieb. Für bestehende Installationen und Spezialfälle bleibt es nützlich; da der 1.0-Zweig ausläuft und die Kryptografie nicht mehr dem neuesten Stand entspricht, sollten neue Standortvernetzungen jedoch auf IPsec, WireGuard oder ein modernes Overlay wie NetBird setzen.

== Unterstützung von m.a.x. it ==
Sie betreiben ein tinc-Netz und möchten es modernisieren, oder suchen das passende VPN-Konzept für mehrere Standorte? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit [https://www.max-it.de/it-services/opnsense/ OPNsense-Firewall-Services von m.a.x. it] und einer [https://www.max-it.de/it-services/managed-firewall/ Managed Firewall von m.a.x. it].

== Siehe auch ==
* [[OPNsense - IPsec Site-to-Site route-based]]
* [[OPNsense - OpenVPN Site-to-Site und Client-VPN]]
* [[OPNsense - NetBird-Plugin]]
* [[ZeroTier – virtuelle Netzwerke mit Layer-2-Overlay]]
* [[Tailscale – Mesh-VPN auf WireGuard-Basis]]
* [[VPN]]
* [[WireGuard]]

== Links und Quellen ==
* [https://www.tinc-vpn.org/ tinc – Projektseite und Dokumentation]
* [https://www.tinc-vpn.org/news/ tinc – Versionshinweise]
* [https://github.com/opnsense/plugins/tree/master/security/tinc Quellcode des Plugins os-tinc]
* [https://www.max-it.de/it-services/opnsense/ m.a.x. it – OPNsense-Firewall-Services]

{{Uebermax}}
[[Kategorie:IT-Security]]

OPNsense - Tinc Mesh-VPN - Versionsgeschichte

imported>TechCorner-Redaktion: Neuer Artikel: tinc-Plugin (os-tinc 1.8, tinc 1.0.37), Stand OPNsense 26.7