OpenVPN vs. TincVPN vs. SoftEther

[wanne]

in größeren Entitäten entscheidet darüber die "Gouvernance" und der Admin resp. der Dienstleister befolgt jene resp. setzt sie um.

Ja, da kommen teilweise recht komische Entscheidungen zusammen. Aber für gewöhnlich keine harte Whitelist DPI.

[r4pt0r]

Ich hatte bis vor ca 2 Monaten OpenVPN und seitdem Tinc im Einsatz zur Standortvernetzung (gesamt ca 40 Clients in 3 Standorten, ~50GB/Woche durchsatz im VPN-Netz)
Grund für den Wechsel: Server an 2 Standorten, daher war eine reine Server/Client Konfiguration mit einem VPN-Master unpraktisch.

OpenVPN hat IMHO eine schön strukturierte "klassische" Konfiguration, dadurch sind auch komplexe variationen je client möglich ohne dass man den Überblick verliert.
Forward secrecy ist recht simpel einzurichten, auch durch die klar strukturierte Konfiguration und da man alles Zentral einrichten kann. Änderungen sind damit schneller durchgeführt.
Tinc ist da im Vergleich etwas "wirr" durch seine dezentrale Konfiguration. Zudem scheint es alles gleich out of the box zu machen/machen zu wollen - was es IMHO etwas undurchsichtig macht.
Tinc ist dafür aber auch in 5min eingerichtet und läuft - solange ein Teilnehmer von aussen für die anderen erreichbar ist baut sich das mesh-netzwerk auch auf. Praktisch wenn man an einem Standort gezwungen ist einen "dummen" NAT-Router zu nutzen (und keine Portforwardings einrichten darf!)...

Geschwindigkeit/Nutzbandbreite ist praktisch identisch - mit der Ausnahme dass der Verkehr ggf eben nicht "ums Eck" über den VPN-Master laufen muss.
Ansonsten waren aber keine Unterschiede zu OpenVPN messbar (jeweils mit&ohne Kompression)

Stabilität: OpenVPN machte nie Probleme. TINC muss sich bereits einen "Schluckauf" anrechnen lassen - nach ausfall der DSL-Leitung an einem Standort wollte sich der Server an dem Standort nicht mehr automatisch ins VPN einklinken - Dienst mustse einmal durchgestartet werden, dann liefs wieder. Anschließender Test ("Steck doch mal kurz das DSL-Modem aus") verlief aber problemlos...




SoftEther kannte ich noch nicht - klingt aber genial, werde ich mir definitiv genauer anschauen!

[ThorstenS]

Wie sieht dein Ré­su­mé nach bald zwei Jahren mit Tinc aus? Läuft es so stabil, wie du es brauchst?
Ich setze nach wie vor openvpn ein - die config steht ja.

[r4pt0r]

Tinc war die absolut richtige Wahl. Seit einem Jahr läuft noch ein zusätzliches Tinc-VPN im bridge-modus zur vernetzung einer neuen Telefonanlage. Das geroutete VPN schaufelt mittlerweile monatlich summiert über alle Standorte ~1TB weg! (ca 50% davon austausch von offsite-backups, dazu ein Testcluster mit Apache Cassandra + Spark)

Selbst ein temporäres Setup an einem Standort mit DSL+LTE, selektivem routing und fallback per selbsgebauten shellscripten lief absolut Problemlos. Eine ständig wegbrechende Verbindung entpuppte sich als miserabler LTE-Empfang, tinc baute aber immer sofort wieder alle Verbindungen auf (>300x am Tag über ein verlängertes WE ).

Die Performance speziell im bridge-modus ist sehr gut, die zusätzliche Latenz ist extrem niedrig, was im gerouteten Setup unser Hauptproblem mit der TK-Anlage war, speziell an den DSL-Anschlüssen (deutliche echos, Lautstärke ging bis ins unhörbare nach unten bis hin zu kompletten abbrüchen und ständigen neustarts der Satelliten). OpenVPN war hier noch schlechter, da hier alles durch den Master geroutet werden musste - Gespräche zwischen den Satelliten waren praktisch nicht möglich.

Auch meine Server zuhause und extern wurden per tinc vernetzt - für Monitoring, Backup und was sonst so alles anfällt. Das Notebook tunnelt von Unterwegs aus unsicheren Netzen ebenfalls alles durch tinc. Da das Setup so schön schnell erledigt ist, kann man praktisch für jeden Zweck ein eigenes "wegwerf-VPN" einrichten.


Tinc ist für mich mittlerweile ein absolutes "fire & forget"-Tool - einmal eingerichtet verrichtet es absolut klaglos und stabil seinen Dienst (wie geschrieben: selbst Monitoring läuft durchs tinc-VPN).
Da das setup auch noch sehr schnell ist (<5min je host), kann man auch kurz mal für tests oder einzelne Anwendungsfälle ein eigenes VPN zwischen mehreren Rechnern aufbauen - solange einer davon ne feste/bekannte IP hat, können (direkte!) Verbindungen zwischen allen Teilnehmern aufgebaut werden.

[ThorstenS]

boah, danke dir. Das hört sich ja super an!
Dann werde ich mich doch mal einlesen und es für den remote-Zugriff in die 4ma einsetzen. (ein bridging meines Laptops in das vlan an eth0.xx sollte ja möglich sein).

[r4pt0r]

Bridging direkt auf ein physisches Interface ist kein Problem - so habe ich die TK-Anlage vernetzt.

Einzige "besonderheit" in der tinc-konfiguration ist das "tinc-up" script, in dem das von tinc erstellte interface (tunN) an die bridge gekoppelt wird, an der bereits das physische interface hängt.

Sieht bei mir z.B. so aus:

/etc/network/interfaces

Code: Alles auswählen

auto eth4
iface eth4 inet manual

auto bridge0
iface bridge0 inet manual
        address 172.16.0.1
        netmask 255.255.255.0
        bridge_ports eth4
        bridge_stp on
        bridge_fd 0

tinc-up

Code: Alles auswählen

#!/bin/sh
ifconfig $INTERFACE 0.0.0.0
brctl addif bridge0 $INTERFACE
ifconfig bridge0 172.16.0.1 netmask 255.255.255.0
ifconfig $INTERFACE up

In der tinc.conf wird dann noch "mode = switch" gesetzt, damit wird tinc völlig transparent und die Geräte an den ethX-interfaces sind miteinander verbunden als würden sie gemeinsam an nem switch hängen. Es findet also kein routing/firewalling durch den host statt (=> niedrige latenzen) und auch ICMP wird transparent durchgereicht - also vorsicht wenn man ganze Netze/-segmente damit verbindet!
Wenn man nicht über die tinc-server/gateways in das Netz zugreifen muss, kann man auch die IP-konfiguration (address, netmask) für die bridge weglassen - dann sind wirklich nur die Geräte die an die ethX-interfaces angeschlossen werden miteinander verbunden.

Um ein Laptop transparent ins LAN zu holen müsste das gateway dann das tun-interface von tinc in eine bridge mit dem LAN-interface werfen. Ich wüsste aber nicht wozu man diesen "Aufwand" betreiben sollte - ein standardsetup (geroutet) ist da einfacher...

[ThorstenS]

Klasse, danke für deine detailierte Antwort.

Den Aufwand möchte ich treiben, weil ich gelegentlich mit tools hantieren muß, die darauf angewiesen sind in der gleichen broadcast-domain zu sein, wie die Hardware, die sie managen sollen (z.B. v2 netgear Switche und ein DVD Vervielfältiger). Wenn ich mich mit einem neuen tool beschäftige, dann soll es auch gleich einen deutlichen Mehrwert bringen

[debi14]

Hi!

So hier noch meinen Senf zu dem Thema: Wir nutzen hier seit knapp 12 Monaten OpenVPN und sind sehr zufrieden.

Umgebung:
Standleitung: 50Mbit symmetrisch
2x Server (T. Krenn) mit Intel Xeon im HA Verbund > Es wird also per "random" entschieden auf welchen Server sich ein Client verbindet.
OS: Debian jessie
Darüber arbeiten 50 User (Road Warrior), davon sind min. 30 gleichzeitig online.

Outlook lokal, div. Anwendungen wie ELO DMS, CRM etc im Browser, der Rest über Terminalserver.

Wir hatten bisher noch keine Probleme, die beiden Server laufen nun seit einem Jahr ohne Neustart etc

Im Vorfeld haben wir mit iperf und Co die Geschwindigkeit getestet und konnten von Beginn an ohne "tweaks" die volle Geschwindigkeit rausholen.

Aktuell wüssten wir nicht was man(n) an OpenVPN besser machen könnte