webcodr

Synology DSM and Let's Encrypt Trouble

This is just a quick note to all with problems to create Let’s encrypt certificates with Synology DSM.

I had trouble for months with this. DSM returnd always that port 80 is closed, but my EdgeRouter config said otherwise and content from the Synology web server itself was accessible via port 80. So, no ISP issue either.

After some research, I used acme.sh with a DNS-based challenge on macOS and imported the certificate. Well, it works, but I wanted a real solution.

Again, after a little more than some reseach, I found a valuable hint. In dual-stack configurations with both, real IPv4 and IPv6 addresses, the Synology Let’s Encrypt client uses IPv6 for the challenge. Of course port 80 was only opened for IPv4 connections. I opened the port and … it didn’t work. I’m not sure why, since I am no master of the CLI-based configuration of a router.

Next idea: turn off IPv6 in Synology’s dynamic DNS service. Well, turns out, you can’t configure which protocols the services will use. Turning off IPv6 in the network settings also didn’t help.

The solution: use a dynamic DNS service that can configure the protocols or does not have IPv6 support. After some fiddling around with the list of supported services in DSM, I decided to use NoIP. And? It works, finally!

Why NoIP? Well, some of the supported services websites seemed ancient and frankly, I don’t want to pay money just for creating a new certifacte every 90 days.

Dear Synology devs

If you read this, please consider adding the DNS challenge option. This was proposed multiple times in the Synology forums since you introduced Let’s Encrypt support and it would help in such situations, where port 80 cannot be accessed due to firewall or ISP issues like dual-stack lite. Thank you.

TL;DR

If you’re having trouble with Synology DSM, Let’s Encrypt and port 80 error messages and you’re using a dual-stack connection like me, turn off IPv6 for your dynamic DNS service or try to open your firewall for IPv6 port 80.

About

Topics: programming in general, Kotlin, Rust, developer productivity (better shells, tmux, nvim etc.), Apple products, mechanical keyboards, some networking stuff (UBNT Edge and Unifi) and some older posts about Ruby and JS.

Webcodr on GitHub

Real-world Node.js Performance Improvements

I just updated from Node.js 8.2.1 to 8.4.0 within my current project. The update to V8 6.0 really shines as I noticed some major real-world performance improvements.

So I decided to do some tests with the above mentioned versions and the latest LTS version, 6.11.2.

Testing methodology

The Webpack build contains the following tasks:

  • Building of two stylesheets with SASS and Autoprefixer
  • Transpiling with Babel of a large AngularJS app written in ES2015
  • Copying images and some other static files
  • Chunking into vendor.js and application.js

Each test ran nine times for each Node.js version.

The tests were conducted in dev mode (no minification, no uglification) with a Debian-based Docker container on Windows 10 Pro with HyperV.

Hardware

  • Core i7-7700K (the Docker container had access to all cores)
  • 16 GB RAM (8 GB for the Docker container)
  • PCIe SSD

As you can see, the system has more than enough power and is significantly faster than my MacBook. Docker on HyperV is incredibly fast and a joy to work with.

Results

Node.js performance benckmark

The improvement between version 8.2.1 and 8.4.0 is a bummer. V8 6.0
does a great job. Node.js 6 used Crankshaft as JIT, Node 8.0 to 8.2 used a combinaton of Crankshaft and Turbofan (V8 5.9). As of version 8.3.0 Node.js utilizes only Turbofan with V8 6.0.

About 10% improvement with a minor version is a really big step and I’m really looking forward to the next V8 versions and even more power.

Ubiquiti EdgeRouter X vs. MikroTik hEX

Da ich auch mal Router testen wollte und den EdgeRouter X (ER-X) eh schon besitze, habe ich mir ein vergleichbares Gerät von MikroTik besorgt, den hEX bzw. den RB350Gr3 (dritte Generation des hEX).

MikroTik ist ein Netzwerkausrüster aus Lettland. Wie Ubiquiti bieten sie professionelle Netzwerk-Hard- und Software zu bezahlbaren Preisen an. Man kann sogar Einzelteile wie Boards, Ports, Gehäuse usw. einzeln kaufen und sich damit seinen Traum-Router zusammenbauen.

Die Kontrahenten

Sie könnten zwar von außen nicht unterschiedlicher sein, ihre inneren Werte sind jedoch sehr vergleichbar. Beide bieten fünf Gigabit-Ports und können an Port 1 über 24 V Passive PoE mit Strom versorgt werden. Außerdem nutzen beide den gleichen SoC von MediaTek und damit die gleiche CPU: einen 880 MHz MIPS Dual Core (4 Threads). Preislich liegen sie mit ca. 55 - 60 Euro natürlich auch gleich auf.

Ubiquiti EdgeRouter X

Ubiquiti EdgeRouter X

Putzig, was? Der ER-X ist wirklich klein, aber davon sollte man sich nicht täuschen lassen. Er bietet fünf völlig frei konfigurierbare Gigabit-Ports. Einmal WAN, einmal LAN und drei Switch-Ports mit separatem Netz? Kein Problem. Zweimal WAN mit automatischem Fail Over? Klar. Reiner Switch-Betrieb? Und ob, auch wenn er alleine dafür zu schade ist.

Auf dem ER-X läuft eine Linux-Distribution namens EdgeOS, die auch auf allen weiteren EdgeMAX-Geräten von Ubiquiti eingesetzt wird. Auf Einschränkungen im Vergleich zu den größeren Brüdern verzichetet man dankenswerterweise.

EdgeOS bietet ein recht umfangreiches Web-Interface mit dem sich viele Aufgaben schnell und einfach erledigen lassen. Für die wichtigsten Standard-Anwendungsfälle stehen Assistenten (Wizards) bereit. Ein simples Setup für WAN mit vier LAN-Ports als Switch und PPPoE inkl. Firewall ist damit in einer Minute erledigt. IPv6 wird leider bisher vom Web-Interface kaum unterstützt, bis auf eine Option in den Wizards für ein Standard-Setup mit Firewall, das aber ohne weitere manuelle Konfiguration nicht funktioniert, kann es nur noch IPv6-Adressen für die Interfaces anzeigen.

Alles weitere inkl. der tiefgreifenderen Konfigurationsmöglichkeiten muss über das CLI erledigt werden. Klingt nun schlimmer als es ist. EdgeOS basiert auf Vyatta, einer Linux-Distribution speziell für Netzwerkgeräte. Vyatta hat ein übersichtliches, recht einfach zu erlernendes Interface. Änderungen werden nicht sofort aktiv, erst nach dem man den Befehl commit abschickt werden sie aktiv aber noch nicht gespeichert. Sollte man sich also z.B. mal bei einer Firewall-Änderung aussperren, reicht ein Neustart des ER-X und alles läuft wie zuvor. Um zu speichern wird der Befehl save genutzt.

Man muss also keine Angst vor dem CLI haben. Kaputt machen kann man nichts, sofern man nicht gleich jede Änderung speichert.

Zusätzlich bietet der EdgeRouter X via CLI zuschaltbare Hardware-Beschleunigung für NAT und IPsec (aktuell Beta). Lt. eines Mitarbeiters auf Reddit überlegt Ubiquiti derzeit außerdem Deep Packet Inspection (DPI) in Hardware zu unterstützen – da fehlt wohl noch ein passender Treiber. Damit wäre er fast auf dem Niveau des nächst größeren Bruders, dem EdgeRouter Lite (ca. 90 - 100 Euro).

MikroTik hEX

MikroTik hEX

Zugegeben, das Gehäuse wirkt im Vergleich zum ER-X etwas billig, es stört aber auch nicht. Ich habe jedenfalls noch niemanden gesehen, der Router wegen ihres Gehäuse-Designs kauft. Die Metallhülle des ER-X mag Hitze besser ableiten, aber da beide Geräte nicht sonderlich heiß werden, spielt das eine untergeordnete Rolle.

Die Ports lassen sich genauso frei konfigurieren wie bei der Konkurrenz. Selbst Port Mirroring in Hardware ist möglich, was meines Wissens nach aktuell beim ER-X nur via Software geht.

Zusammen mit dem hEX kommt eine Lizenz für RouterOS, MikroTiks Gegenstück zu EdgeOS. Es kann allerdings auch separat lizenziert und auf x86-Hardware betrieben werden. Wer sich das Web-Interface (WebFig) vorab ansehen möchte, kann das hier tun.

Der hEX kommt wird vorkonfiguriert geliefert: WAN liegt auf Port 1, die restlichen Ports sind dem Switch zugeordnet. Ein DHCP-Server, DNS-Forwarding usw. sind bereits eingerichtet. Assistenten für andere Konfigurationen gibt es aber nicht. wenn lieber selbst Hand anlegen möchte, besteht beim ersten Login die Möglichkeit einfach per Klick alle vordefinierten Einstellungen zurückzusetzen.

WebFig ist standardmäßig an LAN-Port 2 über die IP-Adresse 192.168.88.1 erreichbar. Alternativ bietet MikroTik mit WinBox ein Windows-Programm, das wie eine Art Wrapper für WebFig aussieht, sich aber durch Fenster-Unterstützung innerhalb der Software besser und schneller bedienen lässt. Für Mac-User gibt es WinBox inkl. Wine als fertiges Bundle – funktioniert bei mir bisher probemlos.

Im Gegensatz zum Web-Interface von EdgeOS kann WebFig alle Funktionen konfigurieren. Über einen Paket-Manager lassen sich außerdem weitere Möglichkeiten nachrüsten, u.A. IPv6, das als inaktives Paket mitgeliefert wird.

Die Oberfläche erschlägt einen auf den ersten Blick durch die vielen Optionen und ist etwas gewöhnungsbedürftig, wenn man vorher nur mit EdgeOS zu tun hatte. Nach ein paar Problemen komme ich aber mit WebFig ziemlich gut klar. Die grundsätzlichen Vorgänge unterscheiden sich ja nicht. Umgekehrt ist sicherlich auch EdgeOS für einen MikroTik-Nutzer erstmal sehr ungewohnt.

Das CLI von RouterOS ist ebenso so logisch und einfach strukturiert wie in EdgeOS, auch wenn natürlich die Syntax anders aussieht. Änderungen sind im Gegensatz zu EdgeOS sofort aktiv und werden direkt gespeichert. Um Probleme zu verhindern, bietet RouterOS den Safe Mode für das CLI und WebFig. Darin gemachte Änderungen werden auch sofort umgesetzt, aber erst gespeichert, wenn man das entsprechende Kommando gibt. Im Zweifelsfall reicht ein Neustart und nichts ist passiert.

In Sachen Hardware-Beschleunigung zeigt sich der hEX knausriger als der ER-X, da aktuell nur IPsec unterstützt wird. Ob da weitere Planungen anstehen, konnte ich leider nicht in Erfahrung bringen. Bleibt die Frage, ob das überhaupt geht? Offiziell unterstützt der SoC beider Geräte nur Hardware-IPsec. Es ist also wahrscheinlich, dass der ER-X zusätzliche Hardware für NAT und DPI besitzt.

Benchmark

Mein Benchmark-Szenario basiert auf iPerf3 mit einer, zehn und 100 gleichzeitigen TCP-Verbindungen und ist damit eher theoretischer Natur. Einen ausgefeilten Test mit zigtausenden HTTP-Downloads in verschiedenen Größen wie Ars Technica kann ich leider derzeit nicht bieten. Vielleicht sollte ich “routerperf” entwickeln. :D

Der Benchmark fand zwischen meinem PC und dem MacBook Pro statt. Der Windows-Rechner verfügt über eine Intel-LAN-Schnittstelle, während der Mac über einen Thunderbolt-Ethernet-Adapter mit dem LAN verbunden war. Sind also beides keine Krücken.

Als Referenzwerte dienen Durchläufe an beiden Rechnern, die über einen Cisco SoHo-Switch verbunden waren.

In allen anderen Szenarien war der Mac als Server am WAN-Port des jeweiligen Routers und der PC am entsprechenden LAN-Port in einem separaten Netz. Das NAT findet via Masquerading in IPTables statt.

Ergebnis

Benchmark Results

Das Hardware-NAT des ER-X schlägt richtig ein, während die Leistung ohne Hardware-Unterstützung ungewöhnlich inkonsistent ist. Das volle Potenzial wird erst mit mehreren Verbindungen wirklich genutzt. Der hEX dagegen skaliert in dieser Situation wie man es erwartet.

Da beide die gleiche CPU verwenden ist das Ergebnis bei nur einer Verbindung umso erstaunlicher. Es wäre durchaus möglich, dass es sich hier um einen Bug handelt. Ein ähnliches Problem gab es im Sommer mit dem UniFi Security Gateway, das auf der Hardware des EdgeRouter Lite basiert.

In der Realität dürfte die Differenz zwischen dem hEX und ER-X ein Stück kleiner ausfallen, denn nicht jede Verbindung läuft über TCP und die Paketgröße hat hier auch ein Stück mitzureden.

Fazit

Ich bin mit beiden Geräten sehr zufrieden. Für knapp 60 Euro bekommt man in beiden Fällen ein überzeugendes Produkt, das auch gehobenen Ansprüchen im Heimnetz mehr als gerecht wird.

Nur wer sich glücklich schätzen kann eine Gigabit-Internetverbindung zu besitzen, dürfte mit dem ER-X die schlauere Wahl treffen – auch wenn in der Realität der Unterschied geringer ausfallen wird. Ganz nebenbei: der hEX hat natürlich auch größere Brüder.

Letztendlich dürfte es für die meisten von uns eine reine Geschmacksfrage sein. Ich werde beide im Wechsel einsetzen und die Entwicklung beobachten. Da beide praktischerweise 24 V Passive PoE unterstützen, lassen sie sich sehr einfach tauschen. Kabel bei einem abstecken, beim anderen anstecken – fertig.

Adios, Kabel-Internet (Update)

Zum Nachtrag vom 13.1.2017

Wie im Guide zum Vigor 130 bzw. EdgeRouter X schon angedeutet, bin ich von meiner bisherigen Vodafone/Kabel Deutschland-Verbindung zur Telekom mit VDSL 100 gewechselt.

Damit halbiert sich mein Downstream, da Vodafone hier 200 Mbit/s anbietet und VDSL mit Vectoring bekanntlich nur max. 100 Mbit/s hergibt. Als Trostpflaster gibt’s aber immerhin 15 Mbit/s mehr Upstream.

Für Entscheidung war das aber alles zweitranging. In den letzten Monaten gab es immer mehr Probleme mit der Kabel-Verbindung, sei’s durch merkwürdiges Verhalten der Fritzbox 6490, zunehmender Last im Kabelsegment oder mit Routing/Peering der Kabel-Infrastruktur.

Gerade letzteres habe ich eigentlich erst richtig gemerkt, als der Vergleich zur Telekom möglich war.

Die Symptome:

  • Als der Anschluss auf 200 Mbit/s geschaltet wurde, waren stabile Downloadraten von 23 - 25 MB/s in Steam die Regel. Inzwischen sind sie nur noch die Ausnahme und nur außerhalb der Hauptlastzeiten möglich. Gilt nicht nur für Steam, generell für alle Downloads.

  • Wenn Steam die Bandbreite nicht auslasten kann, öffnet es zusätzliche TCP-Verbindungen. Können schon mal an die 50 - 70 Stück sein. Ab dem Punkt steigt die Fritzbox langsam aus, weil sie mit NAT nicht mehr hinterher kommt. Ping-Zeiten steigen deutlich an, Surfen nebenbei macht keinen Spaß mehr … der EdgeRouter X lächelt dank Hardware-NAT nur müde.

  • Teils massive Probleme mit Ping-Zeiten und Packet Loss in Battlefield 1, manchmal völlig unspielbar. Lag für mich immer an EA, bis ich ein paar Runden via VDSL gespielt habe …

  • Apple Music war richtig lahm, Streaming von Filmen aus dem iTunes Store war auf PC und Mac ein Graus bis unbrauchbar, Downloads im App Store waren mal pfeilschnell, dann wieder unglaublich langsam usw. – hatte ich alles auf Apple geschoben, aber wie schon bei Battlefield 1 lag’s an Vodafone. Gleiches gilt auch für teils extrem langsam Downloads aus dem PlayStattion Network.

  • Ich schaue gerne die Reviews von SF Debris, es war aber zunehmend schwer sich die Videos überhaupt anzusehen. Die Seite lädt im Vodafone-Netz extrem lahm und die Videos brauchen gefühlte Ewigkeit, bis mal ein bisschen matschiges 240p zu sehen ist. Über die Telekom starten die Videos sofort – in HD.

  • Vermehrt Probleme mit YouTube, manchmal so schlimm, dass selbst Videos in SD nicht mehr flüssig liefen.

  • Starke Schwankungen bei den Ping-Zeiten, auch ohne Last.

Ein Vergleich:

Vodafone

~ ❯❯❯ ping -c 100 google.de
PING google.de (172.217.21.195): 56 data bytes
64 bytes from 172.217.21.195: icmp_seq=0 ttl=53 time=21.271 ms
...
64 bytes from 172.217.21.195: icmp_seq=99 ttl=53 time=28.892 ms

--- google.de ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 19.163/30.845/111.265/15.526 ms

Telekom

~ ❯❯❯ ping -c 100 google.de
PING google.de (172.217.21.163): 56 data bytes
64 bytes from 172.217.21.163: icmp_seq=0 ttl=57 time=21.731 ms
...
64 bytes from 172.217.21.163: icmp_seq=99 ttl=57 time=21.594 ms

--- google.de ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 21.482/21.760/22.146/0.156 ms

Mit IPv6 schaut’s für Vodafone sogar noch etwas schlechter aus.

Diese Ping-Messungen habe ich an einem frühen Nachmittag ausgeführt, also sollte sich die Last im Segmet bzw. Netz doch in Grenzen gehalten haben.

Meine Diagnose:

  1. Die Fritzbox 6490 mag für Normalnutzer okay sein, aber nicht für mich. Den Bridge-Modus lässt Vodafone leider durch Einschnitte in FritzOS nicht mehr zu und ein reines Kabelmodem für EURODOCSIS 3.0 zu finden ist ein Ding der Unmöglichkeit.

  2. Mein zuständiges Kabel-Segment wird zunehmend überlastet. Früher war ich hier der einzige weit und breit mit einer Internet-Verbindung über Kabel. Da es zumindest bis Dezember 2016 auch keine Alternativen für anständige Bandbreiten gab, geht in dem Segment nun zunehmend die Post ab.

  3. Das interne Routing von Vodafone geht z.T. über sehr viele Hops, sowohl mit IPv4 als auch IPv6. Das ist grundsätzlich nicht weiter schlimm, aber es erhöht die Anfälligkeit für Fehler und Packet Loss.

  4. Der vermutlich schwerwiegendste Punkt: das Peering in andere Netze ist z.T. eine Katastrophe. Alle og. Probleme mit den Servern von Apple, EA, Google/YouTube, Sony usw. liegen daran. Über den Punkt kann ich nicht mehr hinwegsehen. Bandbreiten und Ping-Schwankungen sind eine Sache, aber wenn ich für mich wichtige Dienste nicht mehr richtig nutzen kann, ist der Ofen wirklich aus.

Kabel Deutschland bzw. jetzt Vodafone hatte ich fast acht Jahre ohne größere Probleme, aber da ich auch beruflich auf die Internetverbindung angewiesen bin, muss ich an der Stelle den Stecker ziehen.

Vodafone wird mit Sicherheit an den Problemen arbeiten – dauert halt. Eine Segment-Aufteilung kann sich über mehrere Monate bis ein Jahr ziehen. Internes Routing lässt sich auch nicht von heute auf morgen verbessern, ebenso das Peering.

Man hat es hier mit den Angeboten für 200 Mbit/s bzw. in vielen Haushalten auch schon 400 Mbit/s wohl übertrieben ohne die Infrastruktur dahinter auszubauen.

Zumindest im Mobilfunk-Bereich hat Vodafone in den letzten Jahren einiges deutlich verbessert. Schaffen sie im Kabelnetz hoffentlich auch noch. Konkurrenz belebt das Geschäft.

Solange bin ich aber wieder Telekom-Kunde. VDSL mit Vectoring ist nur eine Übergangslösung bis FTTH im großen Stil kommt, aber bin nicht mehr auf ein Shared Medium wie Kabel angewiesen und ab dem MSAN hängt man im BNG, dem neuen, verdammt flotten Backbone-Netz der Telekom.

Außerdem kann ich meine Wunsch-Hardware nutzen, auch wenn es nicht viele Vectoring-taugliche DSL-Modems da draußen gibt.

Für die meisten tut’s der übliche Speedport, der mir zumindest in seinem Verhalten unter Last besser gefällt als die Fritzbox. Der Vergleich hinkt natürlich etwas, da die Fritte deutlich mehr kann.

In Sachen WLAN sind sie beide ziemlich meh, besonders im Vergleich zu meinen früheren AirPorts oder jetzt UniFi Access Points – ist natürlich wieder unfair. Gibt weit teurere Consumer-Geräte, die viel schlimmer sind, siehe Ars Technica.

Nachtrag vom 13.1.2017:

Nach diesem Bericht von Golem ist mir dann auch klar, warum ich die Probleme mit Vodafone hatte. Traffic Shaping verzögert oder verwirft Pakete einfach, je nach Konfiguration bzw. Last. Das erklärt die schwankenden Ping-Zeiten, den Packet Loss in Spielen, die inkonsistenten Download-Raten usw.

Es ist zwar logisch, dass Vodafone QoS einsetzt, damit das Netz nicht komplett zum Teufel geht. Man kann aber nicht einfach den Backbone-Ausbau verschlafen oder gar sogar absichtlich verzögern, während man den Kabel-Kunden immer mehr Bandbreite anbietet und die DSL-Kunden ins Kabelnetz lockt bzw. mancherorts wohl sogar drängt.