Evtl. gibt es da noch Portmappings, so dass die Portnummer nicht passt. Ich würde mir den Datenverkehr mit tcpdump anschauen, wenn die Firewall aus ist. Dann siehst du, was durchkommen muss, und kannst die Firewall entsprechend anpassen.
Beiträge von NaN
-
-
Ins Blaue: Es kam in letzter Zeit mehrmals vor, dass neu registrierte Domains zwar im CCP unter dem neuen CloudDNS System verwaltet werden, aber technisch von Netcup an die Nameserver delegiert wurden, die die Domains im alten System hosten. Die alten kennen die Domain dann nicht, die neuen werden nicht gefragt, und nichts funktioniert. Schau mal, in welchem System deine Domain verwaltet wird und an welche Nameserver sie delegiert wird.
forum.netcup.de/thread/22826/
-
Da du keine ausgehenden Regeln hast, steht die implizite Regel auf "accept", und das sollte alles für Tailscale abdecken, außer der einen eingehenden Regel, die du erstellt hast. Funktioniert es, wenn du die Netcup-Firewall komplett abschaltest? Hast du auf dem Host noch eine Firewall laufen, z.B. ufw?
-
https://tailscale.com/docs/reference/faq/firewall-ports listet noch ein paar andere Sachen.
Wichtig ist, dass die Netcup-Firewall für UDP stateless ist. Du musst immer darauf achten, dass beide Richtungen durch die Firewall kommen. Das kann durch die automatische Regel sein, wenn es keine anderen Regeln für die selbe Richtung gibt, oder du musst eigene Regeln definieren. Anders als bei den Firewalls, mit denen die meisten Nutzer sonst zu tun haben, kommen Antworten auf erlaubte Pakete nicht automatisch durch, nur weil sie zur selben "Verbindung" gehören.
Da Tailscale für die Hauptfunktion und wichtige Nebenfunktionen UDP verwendet, wäre das der erste Instinkt. Wie sehen denn deine Default-Regeln aus?
-
Selbstverständlich gibt es die. RFC 822 von 1997 sagt "is to be valid" über die Postmaster Adresse. Da steht als Grund u.a. "a user may wish to find out a person's correct address, at that site". Ich frag gleich mal den GMX Postmaster, ob der mir eine Adresse raussuchen kann...
Das aktuelle SMTP RFC schreibt aber immer noch "Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox "postmaster" as a case-insensitive local name."Trotzdem: RFCs sind keine Gesetze. Das (inoffizielle) Mantra der Internet Engineering Task Force IETF ist "rough consensus and running code".
-
Nginx ist in erster Linie ein HTTP Proxy, das Spiel läuft aber nicht über HTTP.
Zudem ist fraglich, ob der Proxy so auch Authentifikation ermöglicht, wenn nicht kann jede(r) über Deinen Server proxien und üble Sachen darüber anstellen.
In Nginx kann man natürlich Backends definieren, hier dann einfach nur eins. Das ist kein wilder von überall nach überall Proxy. Im Prinzip kannst du dir das wie eine Portweiterleitung (DNAT) mit zusätzlichem SNAT vorstellen, nur dass es das technisch nicht ist, sondern zwei separate Verbindungen, deren Daten durchgereicht werden. Dafür gibt es etliche praktisch identisch funktionierende Alternativen, bis runter zu socat oder netcat. Ich würde für diesen Anwendungsfall wirklich NAT einsetzen. Das ist die direkteste und schnellste Lösung. Wenn man es mit Nginx kennt und schon mal aufgesetzt hat, ist das aber auch keine schlechte Lösung.
-
Da das wahrscheinlich noch viel mehr betrifft, könnten die Moderatoren das vielleicht direkt an der richtigen (Entwicklungs-)Stelle melden. Der Support kann sich dann um individuelle Störungen kümmern.
-
Ich kann den Fehler reproduzieren. Da ist was kaputt. Als Ausweichmöglichkeit kannst du einen Dateinamen eingeben und eine Upload-URL generieren. Damit kannst du curl benutzen, um eine ISO-Datei hochzuladen. Das funktioniert. Der Befehlsaufruf lässt sich nach der Erzeugung fertig kopieren, oder eben nur die URL.
-
manuell auf die neuen CloudDNS-Server (firstns.cc bis fifthns.com) umbiegen
Im anderen Thema hat das nicht geklappt, aber Versuch macht klug.
-
Das sieht nach diesem Fehler aus. Da du die Domain in deinem CCP im "CloudDNS" siehst, sollte sie auf den neuen Nameservern (netcup.firstns.cc, netcup.secondns.at, netcup.thirdns.de, netcup.fourthns.systems und netcup.fifthns.com) liegen. Du kannst ja mal versuchen, sie darüber aufzulösen. Die werden aber natürlich nicht gefragt, wenn Netcup die Domain an die alten Nameserver delegiert.
Lösungsvorschläge wie im anderen Thema: Zuständig ist der Support. Wenn der zu lange braucht, ist eine Möglichkeit zur Selbsthilfe, die Domain an externe Nameserver zu delegieren, z.B. deSEC.io, und dann entweder davon zurück zu Netcup zu holen, in der Hoffnung dass die Delegation dadurch korrigiert wird, oder sie bei deSEC zu lassen.
-
Hinter "Kündigen" gehört eine zweite Abfrage: Löschen, oder zurück zu denic.
Der Wechsel zu DENICdirect läuft über den Authcode, für den Fall, dass du deine Domain unbedingt für 80€/Jahr hosten möchtest. Dass eine Domain zu DENIC "zurückgeht", also DENIC nachfragen muss, ob die Domain gelöscht oder zu einem anderen Provider übertragen werden soll, ist keine Wahlmöglichkeit sondern immer eine Ausnahme, wenn irgendwas nicht normal gelaufen ist. Auf Dauer hostet die DENIC selbst keine Domains sondern hat dafür die DENIC Services Tochter, die das als DENICdirect anbietet.
-
Und das ist wirklich die einzige Auswahlmöglichkeit?
Du hast da zwei Buttons: "Kündigen" und "Authcode anfordern". Wenn du die Domain nicht löschen lassen willst, hol dir den Authcode und zieh sie einfach innerhalb der bezahlten Zeit um.
Umzug gewünscht: Authcode.
Löschung gewünscht: Kündigung. -
Provider handhaben die Mitteilung von Authcodes unterschiedlich. Bei einigen muss man dafür die Domain kündigen. Das ist bei Netcup nicht der Fall. Wer seine bei Netcup registrierte .de Domain behalten will, sollte sie nicht kündigen: Ein verpennter Umzug mit ungekündigter Domain ist sehr deutlich billiger, als eine Domain aus der RGP herauszuholen, auch wenn letzteres inzwischen nicht mehr horrend teuer ist. Den Umzug leitet man mit der Anforderung des Authcodes und Eingabe beim neuen Provider ein. Mit vollzogenem Umzug fällt die Grundlage für den Domainvertrag bei Netcup weg. Eine separate Kündigung ist dann nicht mehr nötig.
-
Ich halte ja nicht viel vom öffentlichen Posten einmalig verwendbarer Codes. Das lädt geradezu ein, dauernd zu pollen, und das belastet den Forumsserver ganz unnötig. Je mehr Stellen für sowas verwendet werden, desto mehr Stellen werden dauernd abgesucht. Es gibt Leute, die sich Gedanken machen, ob Scraping vertretbar ist, und es gibt Leute, die für ein paar Geldeinheiten jeden Anstand verlieren. Leider muss man für letztere mitdenken.
-
Benutze die generische Adresse. Die Unterscheidung der Mailaccounts funktioniert nicht über die Domain des Webmailers sondern über die Mailadresse, die man da eingibt.
-
DNS Hosting ist Teil des Domaintarifs und das ist alles, was Proton Mail braucht, also brauchst du nichts dazu buchen. Die DNS-Einstellungen findest du im Customer Control Panel. Eine Anleitung dazu gibt es auch:
https://www.netcup.com/de/helpcenter/dokumentation/general/domains-verwalten
Im Moment gibt es zwei verschiedene Verwaltungssysteme für Domains. Die Umstellung vom alten System auf CloudDNS ist noch nicht abgeschlossen. Eine Domain ist entweder im alten oder im neuen System. Die Anleitungen unterscheiden sich etwas, sind aber beide über den Link zu erreichen.
-
Der Grund dafür liegt offensichtlich an Port 25
Vielen Dank für die Information. Mein Tipp wäre, nicht vorschnell Ursachen zu identifizieren.
-
Die Fehlermeldung liegt oft an fehlerhaften DNS-Einstellungen: Konkret muss der A-Record des "mail" hosts auf den Mailserver deines Hostingpakets eingestellt sein. Das ist normalerweise die IP-Adresse des Webservers plus 2. Da mail.deinedomain auch als MX voreingestellt ist, hängt auch der Empfang von der korrekten Konfiguration dieses DNS-Eintrags ab.
-
"iv" are the international versions. You get those if you browse the English language version of the homepage.
-
Der Hauptanwendungsfall für "DNSSEC aus und wieder an*" dürfte sein, den sporadisch auftretenden Fehler zu beheben, dass bei Netcup registrierte Domains irgendwie ihre diesbezügliche Konfiguration vergessen und plötzlich nicht mehr auflösen, wenn der Client DNSSEC verifiziert. DIESEN Fehler könnte man mal beheben, anstatt darüber zu reden, ob das Togglen von DNSSEC schnell oder langsam geht und wodran das liegt. Ich behaupte mal, ohne den Fehler dürfte das so selten vorkommen, dass die Geschwindigkeit des Umschaltens den meisten völlig schnuppe sein wird. Dass man den Fehler nicht mal dann zuverlässig umgehen kann, wenn man externe Nameserver verwendet, disqualifiziert Netcup nicht nur als DNS-Hoster sondern eigentlich auch als Registrar. Ist bei Netcup noch nicht angekommen, wie schwerwiegend dieses Problem ist?
*) have you tried turning it off and on again
