• 08621 - 9 88 30 88

Autor-Archiv cubewerk

Voncubewerk

ISDN-Ablösung im Allgäu für Komm mit Morent GmbH

Wir freuen uns über einen weiteren zufriedenen Kunden im Allgäu. Die Komm mit Morent GmbH hat sich für eine ISDN-Ablösung entschieden aber lesen Sie selbst:

Zum Bericht.

Voncubewerk

ACHTUNG: Betriebsurlaub vom 06-17. August 2018!

ACHTUNG: Wir machen Betriebsurlaub vom 06-17. August 2018!

Voncubewerk

Kopano-Mailserver und Proxmox-Virtualisierung – Glas Baumgartner Trostberg

Danke für das Vertrauen und ein weiteres spannendes Projekt für Glas Baumgartner in Trostberg.

Zum Referenzbericht geht es hier.

Voncubewerk

openvpn cipher performance benchmark vergleich geschwindigkeit

Möchte man z.B. wie wir, über einen WPA2 WLAN-Link, eine doppelte Sicherheit und deshalb noch ein VPN spannen, nimmt man hierzu gerne OpenVPN. Geht es um größere Bandbreiten (> 100Mbit) des Links, kann man schnell an Grenzen stoßen. Der machbare Durchsatz hängt von mehreren Faktoren ab:

  • Gewählte Cipher
  • Verfügbare CPU-Leistung für Verschlüsselung
  • Genutztes Protokoll
  • Genutzte Art der Verschlüsselung (TLS / PSK)

Ziehen wir das Pferd von hinten auf. Je nach genutzter Verschlüsselung, bieten sich unterschiedliche Ciphers an. Dies zeigt auf einem OpenVPN-Knoten:

`openvpn –show-ciphers`

Bei unserer Verbindung kommt ein statischer Schlüssel zum Einsatz (secret….) wodurch alle TLS-Ciphers in der Übersicht ausscheiden. Den besten Durchsatz haben wir erreicht mit aes-256-cbc.

Da UDP verbindungslos ist, ist UDP hier dem TCP-Protokoll vorzuziehen.

Bei allen unseren Tests wurde klar, dass Verschlüsselung ganz gravierend auf die CPU schlägt und OpenVPN bis heute im Jahr 2018 pro Verbindung jeweils nur einen CPU-Kern nutzt.  Aus diesem Grund bremst fast immer die CPU (100% Last) die Übertragung.

Hier noch ein paar Performancewerte (Angabe jeweils in Mbits-Durchsatz – gemessen mit iperf im client/server Mode mit TCP – 40 Sekunden Test)

OpenVPN als virtuelle KVM-Maschine auf mobilem Intel i5 Laptop:

BF-CBC -> 213 Mbits

AES-128-CBC -> 227 Mbits

CAMELLIA-128-CBC -> 206 MBit

Man sieht immer schön mit ‚top‘ dass die CPU bei 100% hängt – technisch deutlich mehr möglich wäre also, wenn die Rechenleistung verfügbar ist.

Ein Blick in Proxmox/KVM zeigt, dass hier nicht alle CPU-Flags (vgl. cat /proc/cpuinfo) an die VM durchgereicht werden. Wählt man in der Virtualisierungslösung bei CPU-Typ ‚host‘ bzw. einen aktuellen CPU, sehen die Werte nach einem Neustart der VM gleich anders aus:

AES-128-CBC -> 313 Mbit

AES-256-CBC -> 309 Mbit

Es bleibt jedoch die CPU der Flaschenhals. Im Vergleich dümpelte ein Xeon E3 Prozessor auf dem Ziel-OpenVPN-System bei ~ 45 % Auslastung herum. Hier wäre noch Luft nach oben. Dennoch bleibt Verschlüsselung eine nicht zu unterschätzende Anforderung an die CPU.

Voncubewerk

cubewerk stellt zweiten Cover-Artikel für Linux-Magazin – Load-Balancer

Wir freuen uns, dass wir das Linux-Magazin mit unserem Artikel zum Thema Load-Balancer überzeugen konnten. Danke für die Veröffentlichung als Cover-Artikel.

Zum Artikel.

Voncubewerk

Abgeschlossenes Telefonieprojekt – Immobilien Stockhammer Trostberg

Und wieder ein abgeschlossenes Projekt. Danke für das Vertrauen. Diesmal konnten wir sogar unser KnowHow im Bereich Elektrotechnik ausspielen.

Zum Bericht:

https://www.cubewerk.de/wp-content/uploads/2018/05/cubewerk_it_beratung_Trostberg_Immobilien_Stockhammer_Telefonanlage.pdf

Voncubewerk

Postfix – Absender darf nur spezielle Domains adressieren

Ausgangslage:

Mehrere Systeme im Haus, relayen über den zentralen Postfix-Mailserver

Anforderung:

Ein bestimmter Absender (benachrichtigung@cubewerk.de) darf nur 3 bestimmte Zieldomains (microsoft.com, aol.com, yahoo.com) anschreiben.

Für alle anderen Domains, soll dieser eine Absender ein reject erhalten.

main.cf erweitern um:

smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/benachrichtigung
smtpd_restriction_classes = benachrichtigung
benachrichtigung = check_recipient_access hash:/etc/postfix/erlaubt, reject

/etc/postfix/benachrichtigung erstellen mit
benachrichtigung@cubewerk.de benachrichtigung

postmap /etc/postfix/benachrichtigung

/etc/postfix/erlaubt erstellen mit
microsoft.com OK
aol.com OK
yahoo.com OK

postmap /etc/posfix/erlaubt

Abschließend ein /etc/init.d/posfix restart

Jetzt der Praxistest:

bauer@mail05:~$ telnet localhost 25
Trying ::1…
Connected to localhost.
Escape character is ‚^]‘.
220 mail05.int ESMTP Postfix (Ubuntu)
mail from: benachrichtigung@cubewerk.de
250 2.1.0 Ok
rcpt to: test@microsoft.com
250 2.1.5 Ok
rcpt to: test@yahaoo.com
250 2.1.5 Ok
rcpt to: anderer-empfaenger@t-online.de
554 5.7.1 <benachrichtigung@cubewerk.de>: Sender address rejected: Access denied

Restliche Absender davon nicht berührt:

bauer@mail05:~$ telnet localhost 25
Trying ::1…
Connected to localhost.
Escape character is ‚^]‘.
220 mail05.int ESMTP Postfix (Ubuntu)
mail from: interner-absender@cubewerk.de
250 2.1.0 Ok
rcpt to: anderer-empfaenger@t-online.de
250 2.1.5 Ok

Voncubewerk

VDSL und SIP-Trunks in Trostberg, Traunreut, Altenmarkt, Traunstein, Tacherting uvw.

Unser Partner Easybell bietet ab sofort anlagenfähige Telefonanschlüsse in Kombination mit VDSL. Jetzt Angebot anfordern!

Voncubewerk

kopano K-1216 – security update – duration np-defrag

Aufgrund CVE-2018-8950 und CVE-2018-8951 sollte aktuell jeder Kopano-Server aktualisiert werden.

Details hierzu hier:

Kopano Groupware Core 8.5.8: Vulnerability fixes and more (updated)

Bei unserem Server mit ~ 120 Benutzern und Corosync/Pacemaker-Cluster und ~ 200GB Mysql-Datenbank dauerte der anschließende Aufruf von opano-dbadm k-1216 ~ 5 1/2 Stunden.

Trotz 32 CPU-Kernen schnappt sich MySQL immer nur einen Kern wie es scheint.

Auszug des Laufs:

up: merging #3946 into #1375 in „lob“…
dbadm: executing action „np-defrag“
defrag: 2960 IDs
defrag: moving 2 -> 1 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 4 -> 2 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 6 -> 3 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 8 -> 4 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 10 -> 5 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 12 -> 6 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 14 -> 7 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 16 -> 8 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 18 -> 9 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 19 -> 10 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 21 -> 11 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 23 -> 12 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 25 -> 13 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 27 -> 14 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 29 -> 15 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 31 -> 16 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 33 -> 17 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 35 -> 18 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 37 -> 19 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 39 -> 20 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 41 -> 21 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 43 -> 22 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 45 -> 23 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 47 -> 24 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 49 -> 25 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 51 -> 26 (names) (properties) (tproperties) (mvproperties) (indexedproperties) (singleinstances) (lob)
defrag: moving 53 -> 27 (names) (properties)