Kategorie: IT

Veröffentlicht am

1blu zeigt sein wahres Gesicht

Wow, das ist wirklich mutig. Die Produktpreise auf einen Schlag um 360 Prozent (!!!) erhöhen. Nein, nicht 3,6 Prozent, nicht 36 Prozent, sondern fast das Vierfache.

Was ist passiert?

Ich bekomme eine E-Mail, in der der Preis meines Webhosting-Paketes von derzeit 2,74 € auf 9,99 € pro Monat angehoben werden soll:

Sehr geehrter Herr Kunde,
mit dieser Nachricht informieren wir Sie über eine Tarifänderung für Ihr aktuelles Produkt „1blu-Homepage Easy“ | Vertrag 227435 zum Beginn Ihrer nächsten Vertragslaufzeit am 07.01.2025.
In den vergangenen Monaten haben wir nach wie vor einen starken Anstieg der Kosten für qualifiziertes Personal, den Einkauf von Soft- und Hardware, Domains und Lizenzen verzeichnen müssen. 
Um für Sie weiterhin eine hohe Qualität und Stabilität unserer Dienstleistungen zu gewährleisten, werden wir leider eine Preisanpassung unserer Tarife vornehmen.
Ab der nächsten Vertragslaufzeit nutzen Sie Ihr Produkt 1blu-Homepage Easy dann für 9,99 €/Monat*.
Für alle Fragen zu den Tarifanpassungen stehen wir Ihnen per E-Mail unter vertragsinfo@1blu.de zur Verfügung. Alternativ können Sie gern auch direkt auf diese E-Mail antworten.

Wir möchten uns bei Ihnen für Ihr Vertrauen in unsere Dienstleistungen bedanken und hoffen, Ihnen auch zukünftig als Servicepartner für ein stabiles und leistungsstarkes Hosting zur Verfügung stehen zu können.

Freundliche Grüße aus Berlin
Ihr Serviceteam der 1blu AG

* Preis/Monat inkl. 19% MwSt. Vertragslaufzeit 6 Monat(e), Abrechnungszeitraum 3 Monat(e). Verträge jederzeit kündbar mit einem Monat Frist zum Vertragsende.


Respekt! Nicht.

Früher wurde das Hosting-Paket in einer renomierten Fachzeitschrift mit einem „Dauerpreis“ von 2,29 € beworben. Dann wurde es moderat etwas angehoben.
Und auch aktuell wird in der Heise C’t wieder dieses Paket von 1blu für 2,69 € beworben. Im gleichen Atemzug, während man es bei (vielleicht unaufmerksamen?) Bestandskunden auf knapp 10 € anheben will.

Man könnte fast meinen, das sei arglistig?

Aber warum zerlegt sich der Dienstleister nun selbst? Oder liege ich hier falsch?
Ein Johann Dasch als Vorstand dieser 1blu Aktiengesellschaft kann doch nicht vollen Ernstes davon ausgehen, dass dieser Schachzug , der auf Unzuverlässigkeit und Unzurechenbarkeit schließen lässt, ohne Folgen bleibt. Oder etwa doch?

Wer, außer Menschen die davon nichts wissen, würden in Zukunft noch Geschäftsbeziehungen mit so jemandem eingehen?
Never ever würde ich einem solchen Menschen meine Daten anbieten oder mich in irgendeine Form von ihm oder seiner Firma abhängig machen!

Den Einträgen in diversen Foren nach versucht 1blu diesen neuen Preis nur vereinzelt durchzusetzen. Womöglich, um nicht zu viel Staub aufzuwirbeln, denn eine solche Preiserhöhung ist ja mehr als unpopulär.

Vielleicht setzt man hier auf folgende Rechnung:
Einige wachsame Kunden wird man verlieren, aber ein gewisser Teil wird nicht aufmerksam oder zu bequem sein, die Dienstleistung zu kündigen. Und wenn am Ende mehr Gewinn dabei rauskommt, dann ist ein möglicher Reputationsverlust schlicht einkalkuliert.
Zusätzlich hat man künftig all die Kunden abgestoßen, die Ansprüche (wie Zuverlässigkeit und Seriösität) stellen, oder sogar widersprechen, denn die kosten nur Geld und mindern den Gewinn. Die übriggebliebenen Kunden sind tendentiell eher willfährig und dann kann man vielleicht auch noch weiter die Preisschraube andrehen. Denn: Was einmal funktioniert hat …

Schade nur, dass das auch meinem Ruf schadet, denn ich hatte 1blu bisher im kleinen Kreis als zuverlässig, und seriös, weiterempfohlen. Ich konnte ja nicht wissen, dass man dem Laden nicht vertrauen kann, wenn er Versprechungen wie „Dauerpreis“ macht, und dann doch bricht.

Alternativen zu 1blu? Ich schaue mir nun all-inkl.com und netcup.com an.
Ionos ist für mich auch schon lange raus.

All das Geschriebene spiegelt nur meine Meinung und Gedanken wider.

Veröffentlicht am

Putty, SSH und Server refused our key

Du hast dir die Mühe gemacht, deinen Debian oder Linux-Server mit Pubkey-Zertifikaten abzusichern und nun bekommst du bei einem neuen Server dauernd die Meldung „Server refused our key“, wenn du dich per Putty verbinden willst?

Hast Du eventuell auch Debian 12, bookworm neu installiert?

Was bisher immer tadellos funktionierte, benötigt offensichtlich nun eine extra Zeile in der

/etc/ssh/sshd_config

PubkeyAcceptedAlgorithms +ssh-rsa

starte danach deinen SSH-Server neu mit:

$ sudo systemctl restart sshd

und der Login über deinen Schlüssel sollte wie bisher weiter funktionieren.

Du kannst im Vorfeld auch selbst überprüfen, ob die Einschränkung des Algorithmus die Ursache ist:
Dazu hast du die Möglichkeit, den Loginprozess auf den SSH-Server zu mitzuloggen, bzw. die Ausgaben live abzusehen.

Starte hierzu einen extra SSH-Serverprozess auf der Linux-Shell mit z.B. Port 2020

sudo `which sshd` -p 2020 -Dd

Du bekommst dann schonmal rund 13 Zeilen Debug-Ausgaben mit dem Hinweis, dass der Server nun an Port 2020 lauscht.
Nun kannst du dich vom Client her, z.B. Putty, auf diesen Port verbinden und dabei wie gewohnt deinen Private-Key mit einbinden.

Wenn bei den Debug-Ausgaben auf dem Linux-Rechner dabei folgende Zeile enthalten ist:

debug1: userauth-request for user mustermax service ssh-connection method publickey [preauth]

, dann ist das der definitive Hinweis, dass du die oben erwähnte Zeile (PubkeyAcceptedAlgorithms +ssh-rsa) in die SSH-Config eintragen darfst.


Veröffentlicht am

OpenVPN zwischen Teltonika und Sophos

Ein VPN mit Netz-zu-Netz (Site2Site) Kopplung zwischen Teltonika Mobile Routern und Sophos Firewalls funktioniert bestens.

Daher hier die Anleitung:

1. Schritt: VPN in Sophos Firewall erstellen

In einer Sophos (getestet mit einer SG-125) eine SSL Verbindung (Site-to-site VPN) anlegen. Das lokale und das entfernte Netz eingeben. Die Verbindung als „Connection type“ Server konfigurieren. Nun die VPN-Verbindungsdatei herunterladen.

2. Schritt: APC Datei „zerpflücken“

Die eben heruntergeladene VPN-Datei hat die Endung .apc, z.B. vpnserver.company.de.apc

Im nächsten Schritt geht es darum, die verbindungsspezifischen Daten zu extrahieren. Für die Gegenstelle (Teltonika-Router) benötigt man drei Dateien, Passwort und Username.

Am Anfang stehen die drei nötigen Zertifikate (in der Reihenfolge „Client Zertifikat, CA und Private Key), jeweils mit einigen für uns unnötigen Inforamtionen dazwischen. Wichtig sind immer die Werte ab:
—–BEGIN CERTIFICATE—– bis einschließlich —–END CERTIFICATE—– bzw. beim
Private Key ab —–BEGIN PRIVATE KEY—– bis einschließlich —–END PRIVATE KEY—–.
Dann steht am Ende der APC-Datei noch der Username und das Passwort. Beide beginnen mit REF_, beim Username (ist relativ kurz) steht direkt danach „username“, beim Passwort direkt danach „password“ (dieses ist relativ lang).

Die entsprechenden Teile der Zertifikate und des Private-Keys per z.B. Notepad++ auszuschneiden und in eine neue, leere Datei kopieren.
Wichtig ist auch, dass das „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE—–“ mit in die neu zu erstellende Datei übernommen wird.

Diese entsprechend abspeichern (die Dateiendung scheint egal zu sein), also z.B. pk.txt, ca.txt und cz.txt und für den nächsten Schritt vorhalten.
Die Stellen, an denen sich Username und Password in der Datei befindet, habe ich oben rot markiert.

3. Schritt: Teltonika Router konfigurieren

Im Mobile-Router nun eine neue VPN-Verbindung entsprechend des unten gegebene Screenshots konfigurieren. Die drei Dateien in die zugehörigen Fehler hochladen.

Sofern keine Fehler unterlaufen sind oder die Komponenten bei Sophos oder Teltonika abgeändert wurden, sollte die VPN-Verbindung schnell zustande kommen und beide Netze jeweils gegenseitig erreichbar sein.

Veröffentlicht am

Sophos Rejected: RBL (cbl.abuseat.org)

Sophos Firewalls können zum Zeitpunkt dieses Postings (Oktober 2021) eingehenden E-Mail Verkehr ablehnen.

D.h. im Logfile erscheinen plötzlich viele Einträge, in denen ankommenden E-Mails wegen vermeinlichem Blacklist-Eintrag bei cbl.abuseat.org abgelehnt werden. Die manuelle Überprüfung der angezeigten Einträge ergeben bei allen Blacklist-Anbietern jedoch keine Auffälligkeiten, d.h. die es handelt sich um ein „falsches Ablehnen“ (false positives).

Ohne irgendeine Änderung an der Firewall-Konfiguration tritt dieser Fehler bei Kunden plötzlich am 12.10.21 auf. Die eingesetzten Firewall-Geräte sind zwei Sophos SG-135, als Failover-Cluster betrieben. Die installierte Firmware-Version ist 9.707-5.

Die Angelegenheit beeinträchtigt den Geschäftsbetrieb von Unternehmen massiv.

Der Grund dafür scheint bisher nicht klar, wird unter dem „Aktenzeichen“ NUTM-13047 dort untersucht.

https://community.sophos.com/utm-firewall/f/mail-protection-smtp-pop3-antispam-and-antivirus/128016/rbl-working-too-well

Es scheint, als habe es etwas mit den eingetragenen DNS-Servern zu tun.

Veröffentlicht am

Sophos Firewalls können kein DHCPv6-PD

Zugegebenermaßen, es betrifft nicht jeden. Aber es ist totzdem dramatisch, wenn eine sogenannte UTM Enterprise-Firewall eine Technik nicht beherrscht, die selbst eine kleine Fritzbox schon drauf hat. Es handelt sich um DHCPv6 prefix delegation, was die Fähigkeit bezeichnet, IPv6-Netze vom Zugangsrouter an dahinterliegende Router weiterzureichen. Mit Softwarestand 9.510-5 auf Sophos Firewalls ist diese Funktion auch im Jahr 2019 noch nicht vorhanden.

Für alle, die jetzt nur Bahnhof verstanden haben:
Das ist in etwas so, wie wenn man ein Auto kauft und stellt fest, dass es keinen Rückwärtsgang hat. Natürlich hat man im Autohaus nicht danach gefragt – ist doch selbstverständlich, dass Autos Rückwärtsgänge haben.

Am kuriosesten ist an der Angelegenheit jedoch, wie man sich als Firewall-Hersteller eine solche Blöße leisten kann. Es gibt etliche Fälle von Global-Playern, die praktisch von einem Tag auf den anderen von der Bildfläche verschwunden sind, weil sie sich auf ihren Lorbeeren einfach ausgeruht haben. Daher fällt es schwer nachzuvollziehen, wie Sophos derart am Kunden vorbei entwickeln kann. Es gibt im Forum alleine 193 Anfragen für die Funktion. Das seit über 3 Jahren!
Ich habe gelernt, dass ein Kunde, der sich beschwert, für etwa 170 andere Kunden steht, die sich an der selben Sache stören. Das macht etwa 32.000 Kunden. Denn jeder, der dort seinen Willen kund getan hat, hat schon einen weiten Weg hinter sich, mit Recherchieren, mit Ausprobieren, einloggen, Posten, etc., um dann schließlich festzustellen: Das Ding kann DHCPv6-PD tatsächlich nicht. Die ignorieren die Kunden einfach.

Zeit, zu wechseln, wie dieser Beitrag zeigt…

und

wie der Kunde seit 2013 (!) ignoriert wird.

Veröffentlicht am

VMs lassen sich plötzlich nicht mehr migrieren

In einem Datacenter mit einem vmware-Cluster, bestehend aus mehreren ESXi Hosts trat die Unannehmlichkeit auf, dass sich einige virtuelle Maschinen unvermittelt nicht mehr migrieren ließen. Die Option zum Auswählen im Kontextmenu ist einfach ausgegraut, deaktiviert, nicht anklickbar. Ein Hinweis darauf, warum die Funktion nicht mehr verfügbar ist, ist nicht erkennbar. Das Hostbetriebsystem ist VMware ESXi, 6.5.0, 6765664, verwaltet von vCenter Server Appliance 6.5.0, 5973321.
Von der Beharrlichkeit, sich nicht zu anderen ESXi-Hosts migrieren zu lassen, sind Linux wie Windows Maschinen betroffen. Der Inhalt der virtuellen Container scheint somit keine Rolle zu spielen. Snapshots sind konsolidiert, bzw. es bestehen keine. Weiterhin sind keine Images in die virtuellen CD-Laufwerke der VM’s gemountet, was sonst unter vmware auch gerne mal zu informationtechnischem Schluckauf führen kann. Migrationen sind weder live, noch im ausgeschalteten Zustand der betroffenen VM’s möglich. Neustart des vCenter, der Hosts, sowie des Storge bringen keine Abhilfe. Die virtuellen Maschinen erscheinen festgenagelt an die Hardware.

Recherchen bringen Folgendes hervor:

https://kb.vmware.com/s/article/2044369

Notiz vom 09.November 2018 seitens vmware: Currently, there is no resolution

Vmware hat offensichtlich keine Ahnung, warum VM’s spontan nicht mehr korrekt in der Datenbank registriert sind, vCenter Server also an digitaler Amnesie leidet. Eine Lösung gibt es nicht, außer der harten OP an der Datenbank, oder der De- und Reregistrierung betroffener VM’s. Ich bevorzuge Letzteres.

Unangenehm an der Angelegenheit ist, dass man sich so nicht mehr auf die HA-Funktionalität verlassen kann. Die man teuer bezahlt hat. Keine Ahnung, wie sich der vmware Cluster verhält, wenn ein vmware Host wegbricht. Außerdem ist die Migration für den Fall eines Stromausfalles nicht mehr gesichert. Im Falle eines Stromausfalles meldet die USV innerhalb des Rechenzentrums, dass die VM’s in ein anderes RZ zu migrieren sind, um den reibungslosen Betrieb sicher zu stellen. Wenn VM’s jedoch an der Hardware „kleben“, crashen sie mit Ablauf der Batterielaufzeit. Wer kommt dann für den Schaden auf?

Veröffentlicht am

HFO Telecom bringt Ansage, dass Sprachkanäle begrenzt sind

Seit Anfang Dezember 2018 erhalte ich Beschwerden von Kunden der HFO Telecom, dass sie die Ansage hören, die maximale Anzahl von Sprachkanälen sei erreicht. Weitere Telefonate können dann nicht mehr geführt werden. Dies tritt ein, wenn zwei Leitungen belegt sind, obwohl vertraglich mehr Sprachkanäle ausgehandelt sind.

Nach Aussagen der HFO Hotline vom 10.Dezember ist dieses Verhalten auf einen Fehler zurückzuführen und sollte nun der Vergangenheit angehören.

Veröffentlicht am

HFO Telecom Ausfall

Seit mindestens 6 Uhr am 04.12.2018 wird mir von erheblichen Problemen bei der Erreichbarkeit von Anschlüssen berichtet, die beim SIP-Provider HFO Telecom konnektiert sind. Kunden klagen über einseitige Gespräche, abgehackte Anrufe oder auch totale Unerreichbarkeit.

Die Hotline des Anbieters konnte ich um 8 Uhr gar nicht erst erreichen.

Seit 10.21 Uhr ist der Status bei „NGN-Telefonie“ auf „schwerer Ausfall“ geändert.

Trotz Allem finde ich gut, dass der Anbieter Transparenz zeigt und die Vorfälle auf seiner Statusseite zeitnah publiziert.

Seit 13 Uhr entspannt sich die Lage. Die Kunden können wieder telefonieren.

Veröffentlicht am

VPN Durchsatz bei AVM’s Fritzbox

Der VPN Durchsatz der Fritzbox hat mich lange interessiert. Eben weil ich Heimzugänge mit Firmen damit gerne vernetzen wollte. Meine Erfahrungen mit dem Durchsatz waren dabei immer wieder ernüchtern. Mit dem Modell 7490 bekam ich immer nur maximal 1,2 Mbyte/s (entsprechend etwa 10MBit/s) durch die Leitung, egal ob eine weitere Fritzbox oder z.B. eine pfsense oder Linux im Rechenzentrum als Gegenstelle fungierte.

Gut, man kann einwenden, dass die Fritzbox ein Konsumer-Produkt und keine Enterprise Firewall ist. Und man darf sich darüber bewusst sein, dass nur wenige Kunden die Firewall-Funktionalität nutzen, gemessen an den gesamten Verkaufszahlen. Trotzdem dürften es sicher bestimmt einige zehn- bis hunderttausende Nutzer sein.

Recherchen zum VPN-Durchsatz blieben regelmäßig unklar. AVM vermied es, sich in irgendeiner Weise zum Durchsatz zu äußern. Tausend Meinungen in Foren, wenig kontextuelles Verständnis [1], schon gar keine brauchbaren Fakten.
Ein Datendurchsatz wie zu Modemzeiten, schrieb ein Forenteilnehmer jedoch passend im Jahr 2016.

Ebenfalls im Jahr 2016 misst ein Johannes Weber unter https://blog.webernetz.net/fritzbox-vpn-speedtests/ den Durchsatz unter professionelleren Bedingungen, und bestätigt, was ich auch immer messe: Der Durchsatz liegt üblicherweise bei höchstens um die 9 MBit/s. Unterirdisch.

Unter diesem Link schiebt der Hersteller AVM den Durchsatz sogar auf das Verhältnis von Overhead zu Payload, d.h. den Verwaltungsdaten zu Nutzdaten, das noch unter der alten Fritzbox 7390, bei der die CPU der noch limitierendere Faktor gewesen sein dürfte und noch lange nicht einmal 10 Mbit drin waren.

Ich hätte mir etwas mehr Ehrlichkeit von AVM gewünscht gegenüber den Kunden! Dass VPN immer langsamer als der native NAT-Durchsatz ist, das dürfte fast jedem klar sein. 20% Abzug, völlig normal.  Aber bei einer Diskrepanz von mehreren hundert Prozent, wenn man z.B. eine 50 oder 100 MBit Internetleitung betreibt und gerade mal 10 Mbit VPN-Durchsatz hat, da kommt man sich schon ziemlich „veräppelt“ vor, bei Hersteller-Aussagen, wie oben angeführt.

Die Zeitschrift C’t kommt mit den Durchsatzmessungen in Ausgabe 21/18 zu den selben Ergebnissen, wie meinen eigenen, als auch denen von Johannes Weber.

Ich tunnele nun mit OpenVPN und AES-NI-fähigen Prozessoren, damit ist der Durchsatz praktisch Wire-Speed (abzüglich Oberhead).

Veröffentlicht am

Utax Drucker und die Druckwarteschlange

Wie unter „https://www.nicht-trivial.de/index.php/2018/09/13/druckwarteschlange-stuerzt-unregelmaessig-ab/“ bereits angemerkt, stürzt auf einem Windows Server Betriebssystem unregelmäßig, aber häufig, die Druckwarteschlange ab. Und zwar sowas von „ab“, dass selbst Windows den Dienst selbsttätig nicht mehr startet. In einigen Fällen war sogar der Befehl „net stop Druckwarteschlange“ wirkungslos und produzierte nur den Ereigniseintrag (Eventlog) mit EventID: 7011 „Das Zeitlimit (30000 ms) wurde beim Warten auf eine Transaktionsrückmeldung von Dienst Spooler erreicht.“

Weiterhin sind gehäuft Meldungen mit EventID 1530 aufgetaucht:
„Es wurde festgestellt, dass Ihre Registrierungsdatei noch von anderen Anwendungen oder Diensten verwendet wird. Die Datei wird nun entladen. Die Anwendungen oder Dienste, die Ihre Registrierungsdatei anhalten, funktionieren anschließend u. U. nicht mehr ordnungsgemäß. “ betreffend \Device\HarddiskVolume1\Windows\System32\spoolsv.exe .

Bisher hatte ich die UTAX Druckertreiber in Verdacht. Der Verdacht hat sich nun erhärtet, als ich den Tipp bekam, den virtuellen Druckeranschluss (Standard TCP/IP Port) von RAW auf LPR umzustellen. Seither läuft die Druckwarteschlange stabil.