UBNT NanoStation

Im Rahmen anderer Spielerein hab ich mich auch mal an das Thema Richt-WLan gewagt.

Da ich schon viel UBNT Gear im Einsatz habe, viel die Wahl schnell auf die NanoStation 5AC Loco:

  • 5GHz AC
  • 13 dBi
  • bis zu 450+ Mbps
  • klein & kompakt
  • Outdoorgeeignet
  • Mobile App easy Setup

Erster Testaufbau Wohnzimmer – Küche lief nach paar Konfigurationsproblemen meinerseits sehr gut, danach zogen beide AP’s an ihre neuen Ziele.

Anfangs hab ich gar keine Verbindung aufgebaut bekommen, trotz einer im Verhältniss kurzen Distanz. Leider ist das 5GHz sehr sehr anfällig für Wände und andere Hindernisse, nach einigem Umplazierungen bin ich jetzt bei einem schon mal akzeptablen Zwischenergebniss:

Am Wochenende werde ich mal schauen, wie weit es sich noch an anderer Position verbesser lässt, aktuell längen beide noch nicht optimal. Gut beim linken zu erkennen, der 2te Pegel (horizontale Achse) ist noch sehr begrenzt…

Fazit: Geile Sache, die Software und Hardware macht Spaß und ist gut zu finanzieren. Kann ich weiter Empfehlen.

btrfs – Ein Teilerfolg

Ich habe mich schon längere Zeit nach einer dynamischen Alternative zum bisher primär von mir eingesetzten ZFS umgeschaut, da mir die physischen Platten hier zu statisch zugeordnet sind.

Was heißt das im Detail? Ich hatte bisher ein Pool aus 3x (3x 3TB Platte im Z1), also 18TB Netto. Der Plan für die Zukunft war dann, die Platten durch größere auszutauschen und im Idealfall sogar weniger Spindeln zu benutzen.

Hier kommt das Problem: Es ist nicht möglich, einen der Z1 Verbünde zu entfernen oder um Platten zu vergrößern / verkleinern, es lassen sich lediglich Platten (durch größere) 1:1 tauschen oder weitere Verbünde in den Gesamtpool aufzunehmen.

Schöner macht es CEPH, was ich mir als erstes angesehen habe: Dynamisch Platten rein oder raus, unterschiedliche Größen, alles kein Thema. Das definierte Level an Verfügbarkeit wird aufrecht erhalten.

Nachteil bei CEPH: Es ist auch einen Aufbau über Systemgrenzen hinweg ausgelegt, wenn auch anders realisierbar, und der Einsatz von Erasure Coding, wie im Raid5, ist nicht ganz trivial.

Andere Alternative: BTRFS

Das System ist wie ZFS ein CoW Dateisystem, deckt meine Anforderungen ab und inzwischen ist der Raid5 Code für meine Ansprüche an Verfügbarkeit ausreichend stabil. Für alles andere gibt es ein Backup *räusper*.

Aktuelle fahre ich jetzt 4x 8TB im Raid5.

Leider gibt es hier aber ein paar Einschränkungen, die mir im Daily Use gegenüber ZFS fehlen:

  • Die Größe von Snapshots lässt sich nicht „elegant“ anzeigen
  • Quotas ziehen sehr massiv an der Performance, sehr sehr massiv!!!
  • „Viele“ Snapshots ziehen ebenfalls viel Performance. Was als „viele“ definiert wird? Keine Ahnung…
  • SSD Caching Tier

Ich werde dem Dateisystem trotzdem noch etwas Zeit geben, wie sich gerade zeigt ist der Support von Samba zu btrfs mittels vfs ganz gut (Shadow Copy, Server Side Copy Offload).

Es wird in ein paar Wochen bestimmt nochmal ein Feedback von mir kommen.

HTTP-Header-Hardening

Ich bin immer dabei, Ausschau zu halten wie man das Web, oder zumindest ich meine Seiten, sicherer gestalten kann. Dabei bin ich heute auf den folgenden Test aufmerksam geworden:

https://securityheaders.io/

Von einem anfänglichen D bin ich inzwischen auf ein A gekommen, die PKP-Laufzeit will ich wegen der recht kurzen Gültigkeit der LetsEncrypt Zertifikate aber aktuell nicht höher als eine Woche ansetzen:

Sehr viele Tipps und super Beschreibungen gibt es in diesem Blogbeitrag:

https://scotthelme.co.uk/hardening-your-http-response-headers/

Vielen Dank von meiner Seite für die dortigen Beiträge, der Blog kommt mit in meine beobachteten Seiten.

Der Vollständigkeit halber hier mal meine auf dem nginx gesetzten Headers:

### Secure Headers ###
add_header      Strict-Transport-Security       "max-age=31536000; includeSubDomains; preload" always;
add_header      Public-Key-Pins                 'pin-sha256="HkAH1iFqrQ902FeSM8bcR5g1Vhmjs7DZf36qBYnsHxk="; pin-sha256="fseSS72aNBsbopCJnqT/rkFjFhOm+F6fiQ5KwYryXaI="; max-age=604800; includeSubDomains' always;
add_header      X-Xss-Protection                "1; mode=block" always;
add_header      X-Frame-Options                 "SAMEORIGIN" always;
add_header      X-Content-Type-Options          "nosniff" always;
add_header      Referrer-Policy                 "strict-origin-when-cross-origin" always;
add_header      Content-Security-Policy         "default-src https: data: 'unsafe-inline' 'unsafe-eval'" always;

(Stand: 12.04.2017)

Unerwähnt sollte natürlich nicht der Test von SSL Labs bleiben, hier kann man sehr gut seine Cipher-Einstellungen und Browser-Kompatiblität testen:

Settings hierzu:

### Add SSL specific settings here ###
ssl_protocols                   TLSv1.2 TLSv1.1 TLSv1;
ssl_ciphers                     'EECDH+AESGCM EDH+AESGCM EECDH EDH !NULL !aNULL !eNULL !EXPORT !LOW !MEDIUM !DES !3DES !RC4 !SEED !CAMELLIA !MD5 !PSK !DSS !ECDSA';
ssl_prefer_server_ciphers       on;
ssl_dhparam                     /etc/nginx/dh2048.pem;
ssl_stapling                    on;
ssl_stapling_verify             on;
ssl_trusted_certificate         /etc/letsencrypt/live/blog.2-cpu.de/chain.pem;
ssl_session_timeout             10m;
ssl_session_cache               shared:SSL:10m;
ssl_session_tickets             on;
ssl_session_ticket_key          /etc/nginx/nginx_ticketkey;

(Stand: 12.04.2017)

Wenn jemand Probleme bei meiner Seite bemerkt freue ich mich über jedes Feedback 🙂

 

OpenVPN Cipher Speedtest

Aufgrund des Upgrades meiner Internetleitung auf 400/25MBit bei Vodafone Kabel und darauf folgend geringer OpenVPN Tunnel Performance habe ich mal ein paar Benchmarks gemacht.

Zuerst etwas zur Vorgeschichte:

Ich habe hinter dem Provider Router (Jetzt FritzBox 6490) schon lange eine pfsense Firewall laufen. Diese läuft auf einem kleinen, sparsamen Atom N2800 und macht neben Firewalling und Routing auch ein OpenVPN Tunnel zu meinem Root im RZ auf, um an die internen VMs zu kommen und Backups zu fahren.

Bei den bisherigen Leitungen (2MBit, 16MBit, 25MBit Downstream) war dies für die CPU kein Problem, mit AES-128-CBC als Cipher und SHA1 als Auth, die Bandbreite zu nutzen. Mit dem Upgrade auf die 400er Leitung blieb der Tunneldurchsatz allerdings bei etwa 30MBit „stecken“. Die CPU ist nicht die performanteste und unterstützt noch kein AES-NI oder AVX, aber mich hat natürlich interessiert, wie weit ich Upgraden müsste, um genug Durchsatz zu bekommen.

Leider finden sich kaum aktuelle Vergleiche im Netz, welche Kombination wie viel Durchsatz mit OpenVPN und verschiedenen Ciphern bringt. Der Server im RZ hat selber genug Power, dort werkelt ein Intel Core i7 6700, also aktueller Stand der Technik und AES-NI sowie AVX support. OpenVPN Cipher Speedtest weiterlesen