Heute kam es, nebst den kleinen UDP Aussetzern durch den Tunnel, was noch ansatzweise verkraftbar war (da UDP derzeit Hauptangriffsziel ist), zu einer längeren Downtime durch X4B.net.
Das nehme ich mal als Grund, einen Erfahrungsbericht zu X4B.net zu erstellen.
Da habe ich natürlich sofort den Support informiert, es ist nicht hinnehmbar das man durch einen DDoS Schutz über 5 Minuten Downtime hat.
Gerade bei einem Service der dies eigentlich um jeden Preis verhindern sollte.
Was bekomme ich als Antwort?
„https://status.x4b.net/incident/1863
If you need high availability you should consider instead of ordering the budget singlehomed locations instead ordering the standard line (with Anycast HA).“
Wahnsinn. Hätte ich nicht sofort jegliches Tunneling entfernt, wäre meine Seiten auch jetzt, anderthalb Stunden später noch down. Dienst sofort gecancelt.
Und natürlich bekommt man kein Geld zurück! Auch bei einem Dienstausfall nicht, was imho einem ein Sonderkündigungsrecht einräumt. Ein Grund mehr den Laden zu meiden.
Habe als Abschluss auf das Ticket noch gefragt, ob die Herren eine Empfehlung hätten, wie ich die Änderungen dessen GRE Tunnel Script rückgängig machen kann und natürlich eine grantige Antwort, „Simply remove anything you have done, and reboot your server.“, zurückbekommen, mit anschließender Ticketschließung.
Zuvor hatte ich einige negative Erfahrungsberichte auf Google gefunden, es aber nicht weiter hinterfragt, da ich mir von sowas gerne selbst ein Bild mache.
Damit kann ich als Fazit nur eine klare Warnung ausgeben, X4B.net als DDoS-Schutz nicht einzusetzen. Der Support ist wirklich durchweg zynisch und grantig.
Als Anhang schreibe ich hier noch ein HowTo für’s manuell die GRE-Tunnel Script Änderungen rückgängig machen drunter.
Zuerst um mit dem Webserver wieder auf eure normale IP zu hören, falls ihr den Webserver nur auf die interne IP horchen lasst:
sed -i — ’s/10.16.0.x/EURE_SERVERIP/g‘ configfile.cnf (oder als wildcard *)
Aus /etc/modules die entsprechenden Module entfernen (ipip / ip_gre). Aus Kernel entfernbar über „modprobe -r ipip“ bzw ip_gre.
ip rule del from 10.16.0.108/30 lookup X4B0
nano /etc/iproute2/rt_tables (alle x4b zeilen entfernen)