Beiträge von frank_m

Zitat von wuestenraupe

Mir erschließt sich leider trotz der instructions nicht was ich eingebe bei "Hostname"

@

Zitat von wuestenraupe

ich sehe nicht wo ich eine Priorität bei netcup eingeben kann.

In der Spalte "MX".

Zitat von wuestenraupe

Ich vermute "destination" = "Verweist auf Adresse". Korrekt?

Auf den Zielserver. Ist was mit <domain-tld>.mail.protection.outlook.com.

Zitat von wuestenraupe

TTL steht ja schon in meiner DNS Zone, das lasse ich einfach untouched, richtig?

Das kann man bei vielen Anbietern pro Eintrag einstellen.

pasted-from-clipboard.png

Ich nutze das seit Jahren über Netcup, in Verbindung mit einem RS. Funktioniert völlig problemlos.

Irgendwas mit Fail2ban oder so?

Du musst die DNS Server natürlich da anpassen, wo sich auch darum gekümmert wird. Das kann systemd sein, es gibt aber auch noch andere Tools, die das übernehmen können. Du bist der Sysadmin, du solltest es am besten wissen.

Bist du sicher, dass ein VPS das richtige für dich ist? Die Frage lässt erahnen, dass dir die Grundlagen fehlen. Wie willst du den Server denn absichern gegen Attacken und Hacking? Geh davon aus, dass im Moment auf deinen öffentlichen IP Adressen pro Sekunde ein Angriff erfolgt.

Zitat von tsc23

Aber die Ursache des Problems ist, das netcup kein DynDNS kann, was meiner Meinung heutzutage Standard ist.

Naja, dyndns können sie schon, sie haben halt nur keine klassische Update URL. Haben viele andere ja auch nicht, und ist ggf. auch ein latentes Sicherheitsrisiko, je nach Implementierung, deshalb haben viele andere das auch nicht mehr. Die API ist dokumentiert, Referenzimplementierungen sind verfügbar. Was willst du noch? Dass dein regex nicht funktioniert, ist nicht Netcups Schuld.

Zitat von tsc23

da die netcup API ohne die ID nicht kapiert das der DNS Record schon vorhanden ist.

Das ist mir schon klar. Deshalb hatte ich ja im oben verlinkten Script nachgesehen, wie die das Problem gelöst haben, weil die müssen das ja auch mal gehabt haben. Und die lesen die Einträge aus, modifizieren nur die IP-Adresse im Array und schreiben es zurück.

Wie kam es überhaupt zu dem Missverständnis? Ich hatte ja weiter oben ein paar mal auf dieses Script referenziert, woraufhin Olivetti fragte, welches Script ich denn meine, und ich hab es verlinkt, woraufhin du schriebst, dass das Script nicht funktioniert. Ist natürlich grundsätzlich richtig, aber es funktioniert bei dir nicht, weil dir der LUA Support fehlt, und nicht, weil das Script grundsätzlich falsch implementiert ist. Und deshalb kann man halt mal nachschauen, wie die das Problem gelöst haben, und sich ggf. Impulse für die eigene Entwicklung holen.

Das Script funktioniert nicht, weil dir der LUA Support fehlt. Grundsätzlich funktioniert das schon, und deshalb kann man sich ja ansehen, wie die das Problem gelöst haben, und sich da Anreize holen.

Zitat von mkdr

Server läuft wieder, sowohl ipv4 als auch ipv6, nachdem Netcup das Problem von "magischer Hand" gelöst hat heute.

Was war denn das Problem? Das beschreiben sie ja immer kurz in der Mail.

Es gibt einige Anbieter von IP-Blocklisten im Internet, abuseipdb zum Beispiel. Ich lade mir per Script von einigen solcher Anbieter die Listen täglich herunter und baue mit ipset eine Blockliste daraus, siehe z.B. hier:

https://github.com/trick77/ipset-blacklist

Zitat von mkdr

Ich habe niemals etwas an der ipv6 geändert. das stand da schon immer so drinn seitdem der server läuft und installiert wurde von netcup.

Das kann ich kaum glauben. Netcup nutzt als Default IP immer das zugewiesene Prefix mit der EUI-64 Host-ID des Netzwerk-Interfaces. Im SCP steht ja auch nicht - wie du oben schreibst - die Adresse, sondern nur das Prefix. Die Adressen, die dort auftauchen, hast du selber mal für RDNS eingetragen, damit hat netcup nichts zu tun.

Zitat von bjo

Letztlich ist das doch vollkommen irrelevant, ob die Host-ID nun in der globalen IPv6 ist oder die ::1 - sofern es im selben /64 ist, sollte es gehen.

Ja, sollte, wenn alles richtig läuft. Im Moment sind wir ja noch dabei, einzugrenzen, was eigentlich schiefgeht. Und netcup nutzt die ursprüngliche Server-Adresse mit EUI-64 Host-ID ja für einige Dienste, z.B. als Routing-Ziel für zusätzliche Subnetze. Vielleicht geht was im NDP schief oder so, wer weiß?

Was noch auffällt: In den Screenshots kann man sehen, dass durchaus Daten auf dem Interface empfangen werden, aber nur extrem wenig gesendet wird.

tcpdump zeigt halt an, was auf dem Interface los ist. Da könnte man z.B. sehen, ob Broadcasts ankommen und welche, ob DHCP Datenverkehr im Netz usw. Ich weiß noch nicht, wonach man suchen soll, es geht erst mal darum, zu sehen, was überhaupt da ist. Es heißt hier ja immer, das Interface sei tot, aber danach sieht es ja nicht aus, da ja Daten empfangen werden, wie man auf den Screenshots sieht.

Zitat von Olivetti

zwischenfrage: welches obige script – oder bin ich blind?!

Ich meinte das aus diesem Link:

https://forum.mikrotik.com/viewtopic.php?t=180358

Zitat von mkdr

Natürlich ist das default daran wurde nie was geändert, ist die selbe ip die im scp steht selber gw.

Halte ich für völlig ausgeschlossen, denn die Host-ID ist nicht identisch mit der link-lokalen Adresse, sondern endet mit :1. Das ist praktisch ausgeschlossen bei einer EUI-64 Adresse.

Was sagt denn tcpdump?

Ist das nix standardisiertes, JSON oder so, wo man einfach ne Bibliothek oder ein Executeable drauf loslässt? Den Parser muss man ja nicht selber implementieren.

90% der Arbeit eines guten Entwicklers ist es, zu gucken, ob ein anderer Idiot das Problem schon gelöst hat.

Zitat von tsc23

Das Problem ist nur, man kann nur alle DNS Einträge zusammen auslesen und bekommt dann eine entsprechende Ausgabe.

Genau. In dem Script oben schreibt er die Einträge in ein Array. Dann geht er in einer Schleife durch das Array, und wenn er den passenden Eintrag gefunden hat, aktualisiert er die IP und schreibt den ganzen Krempel zurück. Das wäre die Alternative zu "Suche die ID".

Also wenn ich mir das Script von oben ansehen, dann liest es den DNS Record aus, überschreibt nur die IP und schreibt den kompletten Datensatz wieder zurück. Machst du das genauso? Falls nicht, rate ich mal kühn, dass du einen Parameter in deinem Set anders setzt, als er bei netcup schon gesetzt ist, und das führt dann zur Generierung eines neuen Eintrags.

Ja, und auch die IPv6 Adresse ist nicht die Standard-Adresse. Zwar sollte es auch mit anderen Adressen aus dem /64 klappen, aber im Probleme auszuschließen, sollte man zunächst beim Basis Setup bleiben. D.h. auch, Wireguard zu deaktivieren.

Was auch auffällt: Die Fehler ist "Host unreachable", und nicht einfach nur "Timeout" oder "Packet Loss". D.h., es findet ICMP Kommunikation statt. Es deutet im Moment nichts darauf hin, dass das Interface einfach tot ist. Wie bereits ganz am Anfang schon erwähnt, muss man mit tcpdump analysieren, was genau da abgeht. Das heißt noch nicht, dass es an der Server-Konfiguration liegt, aber so einfach, wie dargestellt, ist es auch nicht.

Irgendwann ist immer das erste Mal. Es wäre so einfach herauszufinden. Jemand, der einen Server betreibt, sollte dazu auf jeden Fall in der Lage sein. Und wenn der Support die Infos bekommt, könnte er auch schneller und zielorientierter agieren.

Und was ist mit den Fragen, die ich oben gestellt habe? Warum tagelang auf den Support warten, wenn ich in 10 Minuten eine Antwort haben kann, ob ich ihn überhaupt brauche? Klar, man kann sich zurücklehnen und abwarten, aber ich werde das nie verstehen.

Eine Update URL gibt es nicht fürs Netcup dyndns, dass muss über die API bedient werden. Von daher scheiden integrierte dyndns Updater üblicherweise aus. Ggf. geht was mit Scripten, was auch immer das RouterOS als Script-Sprache unterstützt. Ansonsten muss man auf externe Updater setzen, wie ddns oder so. Vielleicht gibt es sowas als Addon für den Router. Oder du lässt nur das ddns Update vom Raspi machen, unabhängig vom Router.

Spricht der Mikrotik denn LUA? Sonst bist du auf dem völlig falschen Weg.

Zitat von mkdr

Aber scheinbar zieht er sich die IPv4 nicht mehr automatisch. Woran kann das liegen?

Ist denn nur IPv4 weg, oder auch IPv6? Wenn du im SCP so weit kommst, dich einzuloggen, kannst du das Netzwerkinterface ja mal von Hand konfigurieren und testen. Außerdem kannst du mit tcpdump schauen, was so los ist auf dem Interface (z.B. in Bezug auf DHCP oder Broadcasts aus der Infrastruktur).