[Berlin-wireless] Foo-over-UDP (FoU) oder L2TP+Tunneldigger als Alternative zu OpenVPN für VPN03, c-base heute

[Bastian]

Hallo,

die gelieferten Stats sind ehrlich gesagt alle nicht ganz so brauchbar.
Aber definitiv erstmal besser als nix.

Uns interessiert die Packet-Size Verteilung auf dem Uplink.

Franz hat eigentlich ganz schöne Stats vom Switch-Port geliefert, dort
ist zumindest RX und TX getrennt. Brauchbar ist davon folgendes:

Packets Received 64 Octets        1022132
Packets Received 65-127 Octets        426739023
Packets Received 128-255 Octets        124812637
Packets Received 256-511 Octets        8963432
Packets Received 512-1023 Octets    14245713
Packets Received 1024-1518 Octets    25447738
Packets Received > 1522 Octets        0

Leider ist der Bereich 1024-1518 zu weit zusammengefasst. Genau an
dieser Stelle brauchen wir eine höhere Auflösung, wenn es uns um
Fragmentierung und die dadurch erzeugten zusätzlichen Packets geht.

Die vorhandenen Daten sagen aber schon einen deutlichen Trend aus:
Wir haben kaum Full-Frame Packets auf dem Upstream und somit kein
signifikant erhöhtes Hintergrund-Rauschen im schmalen Upload-Channel
eines 16/2 DSL-Anschlusses durch Fragmentierung.


Die vpn03-Server Stats von Philipp sind leider aggregiert. Speziell eth0
bringt uns gar nix, weil dort alles (OpenVPN-encapsulated + original)
enthalten ist.
Wie Malte schon ganz richtig angemerkt hat: Mit Wireshark detailliert
analysieren!

Cheers, Bastian

On 03/03/2016 02:04 AM, Malte wrote:
> On Thu, 3 Mar 2016, Philipp Borgers wrote:
> 
>>> Da sollte man doch mal genauer reinschauen, was die kleinen Pakete
>>> sind. Ist
>>> das VPN-gekapselter Traffic oder schon entkapselt?
>> Kann ich dir nicht sagen, da du den Kontext getötet hast. tun-udp
>> enthält nur
>> Payload. eth0 halt einen mix aus verpackten und echten Paketen.
> 
> Das war eth0, die Statistik bringt dann wenig.
> 
>>> Bei VPN-Paketen wäre ein Problem, dass bei älteren Kathleens wegen
>>> der "falschen" MTU durch OpenVPN aus jedem Klartext-Paket nahe der
>>> MTU dank des Overheads zwei gekapselte Pakete (ein grosses, ein
>>> winziges) werden.
>> Nach meinem Verständnis können wir an aufgeteilten Paketen nicht viel
>> machen.
> 
> Für das Gros der Daten erreicht OpenVPNs mssfix genau das: Es "täuscht"
> für TCP-Verbindungen der Clients eine kleinere MTU vor, OpenVPN bekommt
> damit also schon genügend kleine Pakete, die nicht (weiter) fragmentiert
> werden müssen. Für UDP vom Client hilft mssfix nichts, aber es gibt wohl
> fast keine UDP-Anwendungen, die große Pakete verschicken. Skype liegt
> wohl (nur mal kurz gesucht) bei sowas wie 100 Bytes/Paket, SIP bei rund
> 200 Bytes/Paket.
> 
>>> Nachher sind das die ganzen Pings vom SmartGateway und
>>> werweissnochwas... :)
>> SmartGateway pingt alle 30 Sekunden.
> 
> Man beachte das "werweissnochwas". Wenn irgendein Spaßvogel ein Flood
> Ping über das VPN macht, ist die Statistik schon komplett hin. Man muss
> sich halt mal die Finger schmutzig machen und für ein paar Sekunden
> Traffic Wireshark anwerfen, um da ein Gefühl für zu bekommen.
> 
> Grüße,
> Malte

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : VPN-upload-packet-size-distribution.png
Dateityp    : image/png
Dateigröße  : 8595 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160305/f5783913/attachment.png>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160305/f5783913/attachment.sig>