Nachtrag: Tunnel

Ich habe noch mal neu gebuddelt zwischen GT und B …

Nach den sonderbaren Ergebnissen letzte Woche, bin ich das Thema gestern und heute noch mal langsam und neu angegangen. Jetzt machen die Ergebnisse auch Sinn ;)

Technik Durchsatz (MBit/sec) PMTU (Byte)
Direkt (kein Tunnel) [1] 18,6 1500
GRE v4 [2] 18,0 1468
IPIP [3] 17,9 1472
OpenVPN via RZ [4] 9,29 1500
FB-IPSec [5] 11,7 1414
OpenVPN direkt [6] 17,5 1500

Die Verbindung dieses Mal war jeweils von GT (1&1 VDSL 100/40, gedrosselt auf 100/20 z. Zt.) nach B (1&1 VDSL 50/10), Quell- und Zielsysteme waren FSC Futro S550, die als ›exposed host‹ hinter der jeweiligen FB (jeweils 7362 SL) hängen. (Nur dadurch wurde IPIP, was als eigenes Internet-Protokoll läuft, welches die FB nicht weiterleiten kann, überhaupt möglich.) Alle sonstigen Freigaben wurden jeweils gelöscht.

Ich habe noch nicht ganz verstanden, was letzte Woche schief gelaufen ist, aber jetzt messe ich jedenfalls die erwarteten Werte: ohne Tunnel (aber darüber können natürlich keine privaten Netze geroutet werden) ist’s marginal besser als mit GRE oder IPIP, OpenVPN über die die SheevaPlug-CPU in GT (2009 waren 1,2 ARM-GHz noch flott, 2016 allerdings …) bremst den Durchsatz signifikant und spürbar.
Wobei: das Problem sind eigentlich die Kontextwechsel pro Datenpaket (OpenVPN läuft im Userspace, IPIP und GRE sind Kernelmodule), aber, wie die OpenVPN-Verbindung zwischen beiden Futros zeigt, ist das bei x86/x64-Technik weniger ein Probem …

Deutlich abgeschlagen ist AVMs IPsec; da die 7362 ja mit dem gleichen Rechenwerk der 7490 daherkommt, sind diese Werte entsprechend übertragber. Klartext: für vektorisierte Anschlüsse sind 736x oder 7490 nicht mehr Stand der Technik. Mehr als rund 10 MBit/sec VPN-Traffic sind aus der Hardware nicht rauszuholen — genug für Berliner VDSL-Anschlüsse (wo der Upstream mit 10 MBit/sec dieses Hardwarelimit kaschiert), aber viiiel zu lahm für Vectoring-Anschlüsse. Und mehrere parallele VPN-Verbindungen dürften den Durchsatz je Verbindung als auch insgesamt noch weiter senken … ich bin nur zu faul, das jetzt mit dem zweiten VDSL-Anschluß in GT und dem ADSL-Anschluß in B (jeweils ca. 2,5 MBit/sec im Upstream) zu belegen. AVM wird sich, wie schon beim lausigen USB3-Durchsatz, eh’ mit »intendiertem Nutzen« herausreden und darauf verweisen, daß der IPSec-Zugang eigentlich nur zur sicheren Administration oder so gedacht sei — definitiv nicht jedenfalls für den hochperformanten Anschluß ganzer Subnetze … Man bilde sich daher bitte seine eigene Meinung ;-)

Ich schätze, ich werde »dennoch« bei OpenVPN bleiben — bei OpenVPN direkt zwischen den Futros, denn OpenVPN kommt mit dem nächtlichen IP-Wechsel klar, GRE, L2TP oder IPIP müßte ich, je Tunnelende einmal am Tag nach der Wiedereinwahl, auf die neuen Ziel-IPs rekonfigurieren. Kein Hexenwerk, aber OpenVPN kann das – dank vorhandenem, eigenem DynDNS zumindest – generell alleine, ohne externe Skripte.

Unten dann noch die Rohdaten ;-)

__________
[1]
Client connecting to 84.128.xxx.xxx, TCP port 5001
TCP window size: 85.0 KByte (default)
————————————————————
[ 3] local 192.168.177.9 port 34330 connected with 84.128.xxx.xxx port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.1 sec 133 MBytes 18.6 Mbits/sec

traceroute to 84.128.166.210 (84.128.xxx.xxx), 30 hops max, 60 byte packets
1 192.168.177.11 (192.168.177.11) 0.340 ms 0.361 ms 0.547 ms
2 62.155.243.28 (62.155.243.28) 38.046 ms 38.029 ms 38.157 ms
3 b-ea7-i.B.DE.NET.DTAG.DE (62.154.47.78) 16.301 ms b-ea7-i.B.DE.NET.DTAG.DE (62.154.46.182) 20.365 ms 20.293 ms
4 217.0.77.57 (217.0.77.57) 17.015 ms 17.376 ms 17.789 ms
5 p5480XXXX.dip0.t-ipconnect.de (84.128.xxx.xxx) 34.398 ms 35.308 ms 35.908 ms
6 p5480XXXX.dip0.t-ipconnect.de (84.128.xxx.xxx) 36.542 ms 31.287 ms 31.465 ms

[2]
Client connecting to 100.127.254.2, TCP port 5001
Binding to local address 100.127.254.1
TCP window size: 85.0 KByte (default)
————————————————————
[ 3] local 100.127.254.1 port 55990 connected with 100.127.254.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.1 sec 129 MBytes 18.0 Mbits/sec

traceroute to 100.127.254.2 (100.127.254.2), 30 hops max, 60 byte packets
1 100.127.254.2 (100.127.254.2) 29.442 ms 29.840 ms 30.204 ms

[3]
Client connecting to 100.127.254.6, TCP port 5001
Binding to local address 100.127.254.5
TCP window size: 85.0 KByte (default)
————————————————————
[ 3] local 100.127.254.5 port 5001 connected with 100.127.254.6 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 128 MBytes 17.9 Mbits/sec

traceroute to 100.127.254.6 (100.127.254.6), 30 hops max, 60 byte packets
1 100.127.254.6 (100.127.254.6) 30.927 ms 31.264 ms 32.176 ms

[4]
Client connecting to 193.26.120.97, TCP port 5001
Binding to local address 192.168.5.33
TCP window size: 45.0 KByte (default)
————————————————————
[ 3] local 192.168.5.33 port 5001 connected with 193.26.120.97 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.2 sec 66.6 MBytes 9.29 Mbits/sec

traceroute to 193.26.120.97 (193.26.120.97), 30 hops max, 60 byte packets
1 nslug-1.uu.org (192.168.5.245) 0.398 ms 0.373 ms 0.371 ms
2 susan2nslug.uu.org (193.26.120.228) 42.028 ms 42.327 ms 42.519 ms
3 congstar-b.vpn.uu.org (193.26.120.211) 82.523 ms 84.777 ms 84.872 ms
4 dhcp-30.berlin.uu.org (193.26.120.97) 84.964 ms 85.016 ms 85.082 ms

[5]
Client connecting to 192.168.176.9, TCP port 5001
TCP window size: 45.0 KByte (default)
————————————————————
[ 3] local 192.168.177.9 port 43554 connected with 192.168.176.9 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 83.9 MBytes 11.7 Mbits/sec

traceroute to 192.168.176.9 (192.168.176.9), 30 hops max, 60 byte packets
1 192.168.177.11 (192.168.177.11) 0.310 ms 0.424 ms 0.481 ms
2 192.168.176.9 (192.168.176.9) 30.337 ms 31.164 ms 31.800 ms
3 192.168.176.9 (192.168.176.9) 33.951 ms 34.240 ms 34.496 ms

[6]
Client connecting to 192.168.78.2, TCP port 5001
TCP window size: 45.0 KByte (default)
————————————————————
[ 3] local 192.168.78.1 port 60362 connected with 192.168.78.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.1 sec 126 MBytes 17.5 Mbits/sec

root@gw-gt:/etc/openvpn# traceroute 192.168.78.2
traceroute to 192.168.78.2 (192.168.78.2), 30 hops max, 60 byte packets
1 192.168.78.2 (192.168.78.2) 32.342 ms 32.202 ms 32.563 ms