ab und zu lese ich, dass tinc irgendwie anfällig sein soll, finde im Forum jedoch nichts konkretes dazu.
Woher kommt diese Aussage, wie zeigt sich diese Anfälligkeit?
Wir setzen tinc in einem kleinen privaten meshed VPN seit fast 10 Jahren ein und haben da keine Probleme gehabt bisher - zugegeben läuft aber wenig Traffic drüber.
(Aufgrund fehlender Mesh-Funktionalität kämen für uns die meisten anderen VPN-Lösungen nicht in Frage, aber das ist ein anderes Thema)
uns bricht regelmäsig tinc weg zwischen unseren XEN Servern, wo unsere VM liegen. Auf denen dann auch viel Batman Traffic läuft. Das kann an Batman-v14 liegen, oder an den „hörensagen“ doch recht alten tinc code, wobei wir da auch einiges durchprobiert haben an Versionen.
Ob das nun an dem XEN-Tinc-Batman Setup insgesammt liegt, oder an dem code, kann ich nicht sagen. Wir arbeiten daran auf Wireguard umzustellen.
Der Mensch der das viel Maintained und debugged ist da ziemlich angeranzt - mehr kann ich konkret dazu nicht beitragen.
Rein interessehalber, warum tinc zwischen den XENs und nicht L2TP, @fuzzle?
Ich stehe tinc ambivalent gegenüber, die Grundidee ist schick, IMHO, macht den „virtuellen IXP“ (Internet Exchange [Point]) recht komfortabel scriptbar, und die Lösung erscheint intelligent (intern werden kurze, direkte, Wege genommen zwischen unseren VMs). Aber: jedes übertragene Byte erzeugt CPU-Last, wir sehen das auf einer VM, die IPv6 über tinc und Berlin macht, zeitweise sehr deutlich:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2934 root 20 0 23736 3928 1328 R 10.5 0.4 3842:42 tincd
1701 root 20 0 101392 2304 1620 S 3.7 0.2 3828:34 fastd
1666 bind 20 0 234396 116128 2212 S 0.3 11.4 193:46.27 named
22671 root 20 0 104568 3964 2884 S 0.2 0.4 0:00.04 sshd
Was die Stabilität angeht, ich habe schon Debuggingsessions gehabt, wo Traffic in einem Protokoll (z. B. IPv4) tat, im anderen (z. B. IPv6) versackte. Zum gleichen Peer, aber auch nur auf einer unsere VMs, und ein tincd-Restart löste mindestens dieses Problem in Wohlgefallen auf (nach durchaus signifikanter, verbratener Zeit bei der Suche nach der vermuteten Fehlkonfiguration). Dann stirbt der tincd bei uns auch gelegentlich, was per cron dann „behoben“ wird. (tincd stammt aus der jeweiligen Distribution, also Ubuntu LTS, derzeit überwiegend noch 14.04; never touch und so, außerdem hat man dafür ja eine LTS-Version ;)).
Kurzum: wir wollen mittefristig aus dem tinc-basierten ICVPN aussteigen und auf private Peerings setzen (oder einen Ersatz auf Basis von L2TP- oder GRE-Tunneln; letztere kosten deutlich weniger CPU-Zeit, und die 1:1-Zuordnung der Verbbindungen erleichtert das Debugging). Kurzfristig ist geplant, die Anzahl der teilnehmenden Hosts (bei uns die »Backbone-Router«, derzeit 4+1) auf einen zu reduzieren und den bisher über tinc via Berlin laufenden v6-Traffic selbst zu routen (das ist der größte Trafficanteil bei uns in Verbindung mit dem ICVPN und damit tinc).
wir haben in der regel : crypt as much as you can. daher (und damit der hinweis das unser setup die tinc crypto nutzt)
das wurde an anderer Stelle schon breit hin und her geschoben - wer mag , kann dazu mal im forum suchen