Tinc - Erfahrungen / Probleme?


#1

Fortsetzung der Diskussion von Wireguard 0.0.20161230 mit linux 3.18 kernel und damit gluon v2016.2.2:

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)


#2

Zumindest wird allenthalben kolportiert, dass Tinc solang stabil ist solange man seine Links nie ernsthaft sättigt.

Aber hier auch nur Gerüchtelage, sorry.


#3

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.


#4

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).


#5

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


#6

hier als review bzw. zur beachtung. Es sollte ja fast egal sein, ob olsr oder batman-adv verwendet wird, die Effekte sind ähnlich:
http://augsburg.freifunk.net/blog/show/archive/2012/April/14/nochmal_tinc_und_olsr_jetzt_wirklich_gefixt.html