Womit werden die 12% CPU-Last produziert?
Ein Server im Leerlauf sollte doch kaum mehr als 0,5-1% CPU Last aufweisen.
Warum weißt Du, dass das Problem am NetCup vServer liegt und nicht auf Deinem Monitoring-Server von dem aus Du den Curl-Aufruf tätigst?
Sprichst Du den Server mittels IP-Adresse oder Domain-Name an? Sofern Domain-Name könnte das Problem auch in der Namensauflösung liegen. Welche DNS-Server verwendet Dein Monitoring-Server? Könnten diese vielleicht ab und an mal träge reagieren?
Wie und womit erfolgt die Messung?
Welche Ladezeit hast Du im Fehlerfall?
Wie sieht die Load des Servers (IO, CPU) zu den fraglichen Zeitpunkten aus?
Edit: Wenn ich das richtig sehe muss ich meine DNS Records ständig anpassen, wenn ich LE verwende
Musst Du nicht zwingend, Alternativ den Private-Key des Zertifikates (solange nicht kompromittiert) beibehalten: https://hitco.at/blog/lets-encrypt-csr/
Das "Blackhole" Problem ist auf Sender-Seite nicht lösbar.
Da Du als Versender auch keine Vertragsbeziehung zu Microsoft hast, ist Deine rechtliche Position hier aus meiner Sicht eine sehr schwache.
Die Empfänger (outlook.at / outlook.com ... Nutzer) haben jedenfalls eingewilligt, dass Microsoft ungefragt löschen / unterdrücken darf:
Microsoft has no obligation to monitor the Communication Services. However, Microsoft reserves the right to review materials posted to the Communication Services and to remove any materials in its sole discretion. Microsoft reserves the right to terminate your access to any or all of the Communication Services at any time, without notice, for any reason whatsoever.
Hier forderst Du eine Entfernung Deiner IP-Adresse von der Microsoft Blacklist an:
http://go.microsoft.com/fwlink/?LinkID=614866
Wie bereits mehrfach hier im Forum erläutert ist die erste Mail stets nur automatisierter Roboter-Bullshit, erst in der 2ten/3ten Antwort-Mail antwortet irgendwann vielleicht ein Mensch. Man kommt zügig binnen ein paar Stunden zu einem wieder funktionierenden Mailversand, landet aber nach ein paar Wochen regelmäßig wieder auf der Blacklist.
Hier kann man den Status seiner IPs prüfen bzw. seine IPs bzw. Ranges zur Überwachung registrieren:
https://postmaster.live.com/snds/auto.aspx
=> Da erhält man dann auch zwei URLs mit API-Key-Parameter, um automatisiert abzufragen ob man auf der Blacklist ist. Nutze ich mittlerweile bei mir am Server mittels Cronjob, sodass ich sofort mitbekomme wenn ich wieder auf deren Blacklist gelandet bin.
Vielleicht mag Netcup ja mal deren gesamte Ranges bei Microsoft registrieren und überwachen, und allfällige Blacklistings proaktiv wieder zur Freischaltung beantragen, bevor hier im Forum wieder die Verzweiflung der Kunden aufpoppt.
Ich hoffe doch, die Eier stammen von glücklichen Hühnern.
Na ich hoffe doch, die hier versteckten Eier sind allesamt vegan 
Bin Kunde beim ISP UPC in Wien. Kann jedoch leider nicht bestätigen, dass das Peering am VIX beim Zugriff auf Server bei Netcup genutzt wird. Offenkundig wird das peering hier weiterhin sowohl für IPv4 als auch IPv6 in Frankfurt durchgeführt:
C:\Users\gunnar>tracert www.netcup.de
Routenverfolgung zu www.netcup.de [2a03:4000::e013]
über maximal 30 Hops:
1 1 ms <1 ms <1 ms 2a02-8388-6b86-xxxx-xxxx-xxxx-xxxx-xxxx.cable.dynamic.v6.surfer.at [2a02:8388:6b86:xxxx:xxxx:xxxx:xxxx:xxxx]
2 * * * Zeitüberschreitung der Anforderung.
3 12 ms 10 ms 10 ms at-vie-sk14-pe02-tengige0-0-0-33-6.v6.aorta.net [2a02:8380:103:f::1]
4 25 ms 26 ms 29 ms at-vie15a-rd1-lo0-0.v6.aorta.net [2001:730:2800::5474:8044]
5 48 ms 28 ms 26 ms at-vie05d-rc1-lo0-0.v6.aorta.net [2001:730:2800::5474:807e]
6 * * * Zeitüberschreitung der Anforderung.
7 24 ms 59 ms 27 ms de-fra04a-rc1-lo0-0.v6.aorta.net [2001:730:2d00::5474:8066]
8 24 ms 24 ms 25 ms de-fra01b-ri1-lo0-0.v6.aorta.net [2001:730:2d00::5474:8042]
9 28 ms 36 ms 44 ms 2001:730:2d01:17::d52e:b136
10 29 ms 28 ms 29 ms 2a03:4000::e013
Ablaufverfolgung beendet.
C:\Users\gunnar>tracert -4 www.netcup.de
Routenverfolgung zu www.netcup.de [46.38.224.30]
über maximal 30 Hops:
1 1 ms 1 ms 3 ms 192.168.0.1
2 19 ms 10 ms 10 ms 84.116.231.34
3 28 ms 20 ms 19 ms at-vie01b-rc1-ae11-0.aorta.net [84.116.228.201]
4 32 ms 22 ms 20 ms de-fra01b-rc1-ae1-0.aorta.net [84.116.136.118]
5 24 ms 23 ms 23 ms de-fra01b-ri1-ae0-0.aorta.net [84.116.134.6]
6 32 ms 32 ms 28 ms 213.46.177.54
7 28 ms 23 ms 33 ms www.netcup.de [46.38.224.30]
Ablaufverfolgung beendet.Auch die Gegenrichtung (von meinem RS bei Netcup aus zu meinem PC zuhause) sieht so aus.
Die Änderung seitens NetCup war nicht nur AES, sondern z.B. auch pclmulqdq.
Mein VPS hatte vor Aktivierung der neuen CPU-Features ca. 52MB/Sec geschafft, macht heute ca. 700MB/Sec und hat - wenn man wie von Dir beschrieben mittels export OPENSSL_ia32cap="~0x200000200000000"die AES-Hardwarenutzung deaktiviert - aktuell ca. 121MB/Sec chiffriert. Somit ist AES nicht die einzige Performance-Beschleunigung die nun wirksam ist, sondern eben z.B. auch pclmulqdq
Der Aufruf von openssl speed -elapsed -evp aes-128-gcm lastet bei mir nur einen Core aus. Um z.B. zwei Cores gleichzeitig auszulasten kann man openssl speed -elapsed -evp aes-128-gcm -multi 2 starten.
Verstehe nicht, was Du bemängelst.
Nehmen wir der Einfachheit halber die Werte die mit 8k Blockgröße ermittelt wurden:
| ohne AES-NI | mit AES-NI | |
| mein VPS mit Single-Core vCPU | 52 MB/Sek | 714 MB/Sek |
| Dein Router mit Intel Celeron N3150 | 269 MB/Sek | |
| Dein VPS 100 G7 (mit Single-Core vCPU) | 759 MB/Sek | |
| Dein RS 1000 G7 (der 2 exclusive Kerne bietet) | 1213 MB/Sek |
Für mich sind das äußerst nachvollziehbare Werte - Deine Aussage "nur 1/3 von ... hergibt" verstehe ich nicht. Worauf beziehst Du Dich konkret?
Am oben von mir genannten VPS läuft bewusst noch eine alte Debian 8 Installation (mit aktuellem Security-Patchstand), OpenSSL 1.0.1t.
Was meinst Du mit "Obs an dem liegt, wage ich zu bezweifeln"? Die von Dir am VPS gemessenen Werte sind doch in der gleichen Größenordnung wie die von mir nachdem AES-NI freigeschaltet wurde. Sehe da ad-hoc nicht ungewöhnliches?
Offenbar kann man - ohne sich zu registrieren - gar keine Beiträge lesen:
Der Zutritt zu dieser Seite ist Ihnen leider verwehrt. Sie besitzen nicht die notwendigen Zugriffsrechte, um diese Seite aufrufen zu können.
Ein Forum, wo ich mich erst registrieren muss um die Beiträge LESEN zu können wird wohl nicht sehr erfolgreich sein.
Apropos erfolgreich: Dir ist bewusst, dass es bereits mehrere deutschsprachige Skoda-Foren die auch sehr aktiv sind gibt? Ich sehe ehrlich gesagt ad-hoc nicht, womit Du Dich hier von den schon etablierten Foren abhebst.
Beim Inklusiv-Traffic habe ich persönlich keinen Wunsch.
Allerdings hätte ich den Wunsch, dass es den Storagespace auch kleiner gibt. Wunschgröße 100GB um 2€ - fürs Osternest? 
Zwar hier offTopic, aber weil es angesprochen wurde: Auch ich hätte Interesse an VPS/RS mit Serverstandort Wien - oder zumindest mit österreichischer, geolokalisierter IP-Adresse.
Kann ich bestätigen, und der Unterschied ist gewaltig:
Meine Messung openssl speed -elapsed -evp aes-128-gcm von oben vom 02. Februar:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-gcm 38157.24k 43114.26k 45115.65k 51486.72k 52180.31kUnd nun soeben:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-gcm 179710.91k 454486.02k 642883.41k 716375.72k 714416.13kDanke [netcup] Brian A. für die Rückmeldung.
Die hier angefragten CPU-Flags aes pclmulqdq sollten ja eigentlich auf allen derzeit bei euch als VPS-Hosts genutzten Maschinen technisch bereitstellbar sein. Sie daher den KVM-Gästen der VPS-Reihe 7 nicht zu offerieren erscheint mir unzweckmäßig. Es ist ja nicht so, dass nur wir Kunden davon profitieren würden, wenn ihr die vCores mit diesen beiden CPU-Flags konfigurieren würdet. Netcup würde ebenfalls davon profitieren, weil anstelle AES-Runden in Software zu rechnen die Hardware-Implementierung verwendet wird, somit sinkt die CPU-Auslastung des Hosts.
Diesem Wunsch schließe ich mich an.
Auf meinem VPS, Performance ohne AES-NI Flag, ermittelt mit: openssl speed -elapsed -evp aes-128-gcm
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-gcm 38157.24k 43114.26k 45115.65k 51486.72k 52180.31kZum Vergleich, wenn man die Umgebungsvariable export OPENSSL_ia32cap="+0x200000200000000" setzt um die Verwendung von AES-NI zu erzwingen:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-gcm 99506.82k 158212.54k 158870.53k 188262.74k 199183.02kdas ist eine Steigerung um den Faktor 2-4 je nach Blockgröße.
mainziman Das ist mir schon klar, aber dann ist der benötigte Client eben schon im Homerouter integriert. Das verlagert das Problem dahin: Wie kommt eine Unterstützung für $NeuerDynDNSAnbieter in den Homerouter. Sofern das ein generischer Client mit offengelegter API ist, den man auch für einen neuen DynDNSAnbieter nutzen kann ist man fein raus. Viele mir bekannte HomeRouter-Modelle unterstützen aber genau eine handvoll bekannter DynDNS-Anbieter und bräuchten für das Hinzufügen weiterer Anbieter ein Firmware-Update.
Zum Client, kann ich nur sagen das dieser nicht notwendig ist! mir wäre nicht bekannt, dass S****O einen Client, oder gar viele, hat (ja hab ich gerade geprüft).
Wie (wenn nicht mittels Client und/oder Script) möchtest Du Deine IP dem DynDNS-Anbieter mitteilen?
Dir wurde ja bereits eine ganz einfache Lösung genannt:
verwende den DynDNS-Anbieter Deiner Wahl und trage bei Deiner Domain z.B. sowas wie
home CNAME host.dyndns.com
Was daran gefällt Dir nicht?
Dazu musst Du gar keinen Server haben, ein einfacher CNAME Record den Du in der Domainverwaltung anlegst reicht aus um MeinHomeserver.MeineDomain.de nach MeinUsername.dyndns.ddnss.de zeigen zu lassen. Problem gelöst. Den Client dazu bekommst Du von Deinem DynDNS-Anbieter (z.B. ddnss.de).
Es ist ja seitens NetCup nicht damit getan eine API bereitzustellen. Die Anwender würden nach DynDNS-Clients für Windows, Linux, Mac in den unterschiedlichesten Versionen und Geschmacksrichtungen fragen. Ganz zu schweigen von vielen Home-Routern und NAS-Boxen für die man einen Client gerne hätte... also besser einen etablierten DynDNS-Anbieter verwenden für den es einen Client für das System seiner Wahl gibt, und mit einem CNAME-Eintrag darauf verweisen.
Bis auf "DES-CBC3-SHA" (die Du Dir absichtlich für WinXP gewünscht hast) sind alle CypherSuites forward secrecy tauglich.
Das "+SHA1" schiebt Dir die SHA1 basierenden CypherSuites ans Ende, belässt sie aber in der Liste (obwohl nicht mehr benötigt und WEAK). Beachte, dass wir hier nur die CipherStrings betrachtet haben, Dein TLS-Setup jedoch noch zahlreiche weitere Parameter benötigt um ein gutes Ergebnis zu erzielen, siehe mein geposteter Link zum Generator von Mozilla, Dinge wie SSLHonorCipherOrder sind essentiell!
Beachte die Bedeutung von +, - und ! - vor allem das "+" ist nicht intuitiv: https://wiki.openssl.org/index.php/Manual:Ciphers(1)
If ! is used then the ciphers are permanently deleted from the list. The ciphers deleted can never reappear in the list even if they are explicitly stated.
If - is used then the ciphers are deleted from the list, but some or all of the ciphers can be added again by later options.
If + is used then the ciphers are moved to the end of the list. This option doesn't add any new ciphers it just moves matching existing ones.
