Beiträge von frank_m

Tausende sind es bei mir nicht, aber einige Hundert über den Tag verteilt. Bei mir stehen die aber in einer ipset Blacklist und fliegen deshalb direkt in der ersten iptables Regel raus, egal auf welchen Port sie zugreifen.

Das Paper hier finde ich ganz interessant:

http://www.petarradojkovic.com/publications/MEMSYS-2019__DRAMErrors.pdf

Ist allerdings schon 3 Jahre alt. Ansonsten findet sich vielleicht noch was, wenn man nach MTBF oder MTTF von DRAM sucht, ggf. aus irgendwelchen Functional Safety Betrachtungen. Aus dem Feld der Functional Safety dürften die meisten Betrachtungen in der Richtung stattgefunden haben, z.B. ISO 26262 oder IEC 61508.

Die Bilder sind nicht sichtbar. So wird es schwierig.

Zitat von fwberni

Das bedeutet wenn ich im Emailprogramm ein falsches Passwort hinterlegt habe, werde ich sofort gepannt ?

Das hast du offensichtlich so eingestellt in Regel 3. Vielleicht ist es eine Default-Einstellung von Mailcow. Aber das sollte sich in der Fail2Ban Einstellung entschärfen lassen.

Zitat von fwberni

Konnte mich immer mit meinen angelegten Daten in Mailcow einloggen.

Jetzt aber nicht. Das kann ja eigentlich nur bedeuten, dass die Zugangsdaten falsch sind (auf Server oder Client Seite), oder dass die Konfiguration falsch/unvollständig sind.

Zitat

SASL PLAIN authentication failed

Warum passiert das? Da ist es ja kein Wunder, dass der Client gebannt wird, wer er sich mit falschen Daten einloggt. Oder auf die falsche Art und Weise.

Zitat von OCram85

Alternativ habe ich mal den quad9 oder google dns hinterlegt aber ohne Veränderung

Wie hast du das denn gemacht?

DNS Auflösungsprobleme werden hier im Forum öfter berichtet, allerdings immer nur in Zusammenhang mit den Netcup DNS Servern. Dagegen hilft das Setzen anderer DNS Server, z.B. Cloudflare oder Google.

Zitat von Max der kleine

Ich brauche im Prinzip eine bessere schnellere Verbindung zum Netz für meine Projekte.

Was für Projekte? Webseiten? Serverdienste? Generell hätte ich gesagt, für eine "schnellere Verbindung zum Netz" braucht man eine schnellere Internetverbindung, aber keinen VPS.

Zitat von Max der kleine

AWS war okey, allerdings werden die server da sie indirekt gleichzeitig genutzt werden zu bestimmten Zeiten langsamer.

Dann hab ich jetzt ganz schlechte Nachrichten für dich: Das ist hier auch so.

Wie hast du denn AWS zum Laufen gebracht? Weil deren Admin Konsole ist ja wirklich noch mal ne andere Nummer, als das freundliche SCP hier.

Was willst du mit den Server denn überhaupt erreichen? Vielleicht gibt es ja Produkte, die deine Anforderungen erfüllen und weniger gefährlich sind.

Oh je. Bist du dir sicher, dass du einen Server betreiben willst? Bedenke: Damit trägst du eine große Verantwortung! Wenn dein Server gehackt wird und für illegale Zwecke missbraucht wird, dann landen die Netcup-IPs auf Blacklisten, und darunter leiden alle Netcup Kunden!

Wenn du nicht mal weißt, wie du dich an einem Server anmelden sollst - zumal es am Ende des Installationsprozesses sogar angezeigt wurde - dann bin ich mir nicht sicher, ob du weitermachen solltest. Vielleicht fängst du bei dir Zuhause erst mal mit einer Linux Server Installation an und sammelst Erfahrung, z.B. in einer VM oder auf einem Raspi. Wenn du dann in Bezug auf Netzwerk, Adminstration, Firewall usw. topfit bist, dann kannst du einen Server in einer Clound betreiben. Vorher nicht.

Ist es denn so, dass XRDP den laufenden Desktop anzeigt? Startet der nicht eine neue Session? Bei mir ist es z.B. so, dass die DISPLAY Variable in der XRDP Session 10:0 ist. Das ist üblicherweise nicht das DISPLAY, dass eine lokale X Session benutzt. Ich benutze allerdings auch nur xrdp für den Zugriff und hab gar keinen lokalen X Server laufen.

Aber ggf. kann man das einstellen, welches DISPLAY xrdp überträgt.

Vermutlich kommt da ein Subnetz zum Einsatz, welches früher mal in Saudi Arabien verortet war, und die Lokalisierungsdienste sind noch nicht aktualisiert.

Zitat von Plavix98

Muss ich noch manuell was Routen damit wg0 quasi eth0 findet?

wg0 findet ja eth0, sonst würde ja der Tunnel (mit 10.66.66.6) auch nicht mehr funktionieren. Dafür sorgt wg beim Verbindungsaufbau durch eine dedizierte Host Route.

Aber natürlich ist 0.0.0.0/0 das Problem. Damit schaltest du das Internet im VPS quasi ab. Mach es dir klar: Ein Paket kommt von außen auf deinem Server auf eth0 an. Der will darauf antworten, guckt in seine Routen und schickt die Antwort zum VPN Interface raus, über deinen Heimrouter ins Internet. Es kommt vielleicht am Ende wieder beim Absender an, aber von einer komplett anderen IP Adresse. Der Sender weiß gar nicht, dass die Antwort mal zu seiner Frage gehörte und wird sie verwerfen.

Wenn der Internetzugang über eth0 erhalten bleiben soll, dann darfst du nicht 0.0.0.0/0 über VPN routen. Alternativ musst du über Portweiterleitungen dafür sorgen, dass die Dienste des Servers auf deinem FTTH Zugang erreichbar werden. Aber aus Sicht der Latenzen ist das natürlich eine Katastrophe. Und ich würde auch nicht Server Traffic durch mein Heimnetz routen wollen.

Was natürlich geht, ist ein policy based Routing für spezifische Randbedingungen. Da müsstest du dir halt überlegen, unter welchen Randbedingungen der VPN Tunnel genutzt werden soll, dann kann man ggf. eine Regel dafür bauen.

Bei mir ist es umgekehrt. Hinweg geht noch über Amsterdam, Rückweg biegt in Frankfurt ab, macht einen Hop in Düsseldorf und ist dann im Zielnetz auf dem Weg zu mir.

Ich bin bei der deutschen Glasfaser. Die haben ursprünglich holländische Wurzeln und setzen stark auf Kooperationen mit niederländischen Partnern, u.a. auch beim Transit. Da ist man schnell in Amsterdam.

Aus Sicht von Netcup muss man natürlich das "Große Ganze" im Blick behalten. Vielleicht hat es andere Vorteile, mehr Traffic über Amsterdam zu routen, die wir nicht einschätzen können.

Ich bin im Thema Transit Routing zu wenig drin, um beurteilen zu können, wie einfach es ist, deutsche Kunden über Frankfurt anstatt über Amsterdam zu routen, oder welche Nachteile das vielleicht auch hat. Ich weiß auch nicht, was es für die globalen Routing Tabellen heißt, wenn plötzlich übriggebliebene IPv4 Adressen aus Neuseeland nach Hamburg, Düsseldorf oder Nürnberg geroutet werden müssen.

Deshalb kann ich eure Wünsche da sehr gut nachvollziehen. Wenns schlechter wird, ist immer doof. Aber Ende letzten Jahres wurde ja ein paar mal was am Routing umgestellt, weil es zwischendurch Probleme gab. Ich hatte damals mal eine Zeitlang das Problem, dass der Ping abends zwischen 18 und 22 Uhr schlechter wurde. Nicht dramatisch, aber messbar. Das war ungefähr Ende November weg.

Zitat von nebula76

Für die Versatel-Kunden, für die ein Routing über Amsterdam aus was auch immer für Gründen besser ist, kann der Routing-Algorithmus ja trotzdem die bessere Route wählen.

Wird man das so einfach trennen können? IP-Adressen haben nicht unbedingt einen geografischen Bezug.

Ich würde mich von dem Gedanken verabschieden, dass der kürzeste Weg immer der beste ist. 700km auf Glasfaser sind eine Handvoll Nanosekunden, das macht den Braten nicht fett. Es ist eher die Anzahl der Hops, die sich da niederschlägt.

Klar ist es aus eurer Sicht schlecht gelaufen. Leute mit einer besseren Anbindung an Amsterdam leiden weniger unter der Umstellung.

Von mir zu Hause aus sind es weniger als 20ms auf meinen Netcup Server, und das trotz Amsterdam. Der Weg von mir nach Amsterdam sind 8 ms. Wenn ich einen trace zu Heise mache, geht es über Frankfurt. Bis Frankfurt brauche ich 10 ms. Für mich würde es in der Praxis vermutlich keinen Unterschied machen, ob ich über Frankfurt oder Amsterdam geroutet werde. Nach Frankfurt brauche ich so oder so 10 ms, egal ob über Amsterdam oder direkt.

Wie sieht das über IPv6 aus?

Ein traceroute hat natürlich immer nur begrenzt Aussagekraft, da die ICMP Nachrichten von den Routern mit geringer Priorität erzeugt werden. Das sollte man immer im Hinterkopf haben.

Wenn man zynisch ist, könnte man sagen: Bis zum Eintritt ins Versatel Netz sind es nur 10 ms. Erst ab da treten die Probleme auf. Es ist natürlich denkbar, dass Versatel zu Frankfurt den kürzeren Draht hat, und deshalb auch im Versatel Netz weniger Zeit verbraten wird.

Hast du bei anderen Routen über Amsterdam auch diesen Zeitverlust? Und tritt der Zeitverlust auch bei "echten" Applikationsdaten auf und nicht nur bei traceroutes oder Pings?

Wenn du nicht mehr genau weißt, woher die Route früher ging, ist da natürlich viel Spekulation dabei.

Zitat von mainziman

ssh -w any root@server baut am client und am server ein tun# device auf,

Ja, stimmt, davon hab ich schon mal gehört. Aber bisher nie produktiv eingesetzt. Jetzt hab ich auch das Problem verstanden.

Ggf. kann man über den SSH Tunnel auf der Serverseite automatisiert ein Script ausführen lassen, was die dortige Konfiguration vornimmt. Für den SSH auf Routerseite müsste man mal überlegen, ob man mit nohup oder screen was konstruieren kann, damit die Session erhalten bleibt.

Zitat von mainziman

aber vom SSH oben kehrt er nicht zurück ...

Kommen die Anfrage schon von home-prefix::/56? Dann ist klar, dass er nicht zurückkommt, denn er hat ja plötzlich eine andere Route dafür.

Was ist tun0 für eine Verbindung? Der 6in4 Tunnel?