Beiträge von NaN

Du hast keine Regeln für wichtige Basisprotokolle eingetragen. Die Firewall ist für UDP stateless. Das erfordert etwas mehr Aufmerksamkeit als die übliche Heimrouterfirewall. Lies dir mal den "Spickzettel zur Netcup Firewall" durch. Deine NGINX/NC Regeln sind außerdem zu stark eingeschränkt. Der Source-Port einer HTTPS Verbindung ist praktisch nie 443 sondern ein mehr oder weniger zufälliger Port aus der "Ephemeral Port Range". Dass man bei TCP den Source-Port festlegt, kommt generell fast nie vor.

Wir sollten alle jeweils ein Support-Monitoring aufsetzen, um die Ticketlatenz zu testen. Mit einem Ticket pro Minute sollte sich ein guter zeitlicher Verlauf abbilden lassen. Distributed Determination of Support. Nimmt man dafür Grafana?

Hier ist ein "Forum für Kunden von Kunden"*. Wir andere Kunden können das nicht für dich erledigen. Es gibt zwei Domainverwaltungen, die alte für "Bestanddomains", die auch langsam umgestellt werden, und die neue "CloudDNS" Verwaltung. Du bist mit deiner Domain auf dem neuen System. Die offizielle Hilfe gibt dir vielleicht Hinweise, was du da machen musst.

*) Ich hätte das andersherum formuliert: Forum von Kunden für Kunden. So wie es da steht könnte man es auch für ein Forum für Kunden von Netcups Resellern halten. Kurzgesagt, auch wenn die Moderation, die Technik und die Geschäftsleitung hier lesen und auch schreiben, ist das kein Kanal, der für den alltäglichen Kundensupport durch Netcup gedacht ist. Hier unterhalten sich Kunden untereinander.

Wenn du eine Subdomain in deinem Webhosting angelegt hast, hast du dort auch den Punkt "Passwortgeschützte Verzeichnisse" und kannst "/" als Verzeichnis angeben. Das betrifft dann die ganze Subdomain.

Only the smallest two Lite servers are guaranteed to be provisioned in Nuremberg, because they're not available elsewhere. The other Lite servers are provisioned as Netcup sees fit with no possibility for you to choose a location. If you need a server in a specific location, this isn't the right product for you. You gambled on location and it didn't work out. Yes, a "VLAN only" option is practically useless on a product with a random location, but that's what you get.

"stärker verzögert als gewohnt"

Musste schmunzeln.

Wenn Montag reicht, geht auch (Support per) Mail.

Wenn das alles ist, was du hinzugefügt hast, dann solltest du noch eine Regel für NTP hinterherschieben, denn sonst weicht irgendwann die Uhr deines Servers zu sehr ab. Da du die Adresse per DHCP beziehst, tust du das wahrscheinlich auch mit den Nameservern. Andere als die Netcup-Nameserver kannst du jetzt aber nur per TCP erreichen. Wenn du andere verwendest, funktioniert es jetzt vielleicht, aber besser wäre, du lässt auch DNS über UDP zu. Oben wurde schon der Spickzettel zur Netcup-Firewall verlinkt. Wirf mal einen Blick drauf.

Du kannst über die Webconsole auf den Server zugreifen. Mit tcpdump kannst du sehen, ob Pakete an deinem Server ankommen, also beispielsweise sollte tcpdump -n -i eth0 port 22 ankommende Verbindungsversuche zeigen. Das funktioniert auch, wenn auf dem Server irgendwas schiefläuft, z.B. der SSH-Server die Verbindung nicht annimmt, gar nicht läuft, keine IP-Adresse zugewiesen ist (dann allerdings nicht für Port 22, sondern eher für DHCP und Broadcasts), eine Firewall auf dem Server die Pakete verwirft oder ähnliches. Mit ip address siehst du, ob das Interface eine Adresse hat.

Wahrscheinlich funktioniert irgendetwas auf deinem Server nicht, weil du nicht genug freigegeben hast, dass die Default-Policy auf DROP wechseln kann. Du musst dich dann auch um DNS und ggf. DHCP kümmern. Für UDP ist die Firewall nicht stateful. Es reicht also nicht, dass die Anfragen von deinem Server rausgehen. Die Antworten müssen auch explizit durch die Firewall gelassen werden.

Wenn du es per trial-and-error angehen möchtest, leg eine Policy an, die UDP ohne Einschränkungen reinlässt. Wenn es dann funktioniert, weißt du, dass es an einem geblockten UDP-Protokoll liegt. Dann kannst du das weiter eingrenzen und diese Policy wieder rausnehmen.

Mir scheint das eine "herkömmliche" Sichtweise auf Virtualisierung zu sein, bei der man die VMs nicht als Funktionen sondern als Geräte betrachtet und darauf dann mehrere Sachen laufen lässt, wie z.B. Containeransammlungen (Pods) mit getrennten Netzen. Eine Cloud ist ja eher so gedacht, dass man die VMs schmal hält und die Orchestrierung inkl. Netzwerksegmentierung in der Cloud macht.

Ich missbrauche eine Cloud auch gerne als VM-Provider und lasse den ganzen Rest der Managementfunktionen links liegen, aber im Prinzip sind langlebige VMs mit komplizierten "internen" Setups in einer Cloud ein Fremdkörper.

Soweit das Wort zum Sonntag. Zurück zur Technik...

Port 465 mit SSL ist korrekt. Auf dem Port wird eine verschlüsselte Verbindung (SSL/TLS) geöffnet, dann laufen darüber die Daten. Die Alternative, auf Port 587, ist eine zunächst unverschlüsselte Verbindung, die per unverschlüsseltem STARTTLS Befehl auf Verschlüsselung umgestellt wird, bevor Daten übertragen werden.

Der Port 465 wird oft als "legacy" (überholt, veraltet) bezeichnet, weil er streng genommen nicht standardisiert ist. Bedingungslose Verschlüsselung ist aber nach heutiger Einschätzung der korrekte Ansatz und wird so von Netcup unterstützt. Die Flexibilität von Port 587, u.U. die Verbindung unverschlüsselt nutzen zu können, wenn eine der beiden Seiten keine Verschlüsselung unterstützt, will man nicht mehr haben. Über diese Verbindungen wird das Mailpasswort übertragen. Wenn das nicht verschlüsselt ist, z.B. in Folge eines Downgrade-Angriffs, ist das ein sehr ernstes Problem.

Es kann sein, dass ein Client direktes TLS auf Port 465 nicht unterstützt und nur TLS mit STARTTLS auf Port 587 nutzen kann. Dann ist aber genauestens darauf zu achten, dass bei fehlender Verschlüsselung abgebrochen wird (auf keinen Fall "SSL wenn möglich" auswählen). Es kommt immer wieder vor, dass Clients sich auf Port 587 unverschlüsselte Verbindungen unterschieben lassen. Welcher (Web-)Client ist das?

Die Zahl in der Fehlermeldung "Time out 110" ist verdächtig: 110 ist der (unverschlüsselte) POP3 Port. (Aus der Mottenkiste: Es gab mal die Methode "SMTP after POP". Man hat authentifiziert Mail über POP3 abgeholt und konnte dann im Anschluss per unauthentifiziertem SMTP senden. Nicht dass das sowas ist...)

Wenn du die Domain günstiger haben möchtest, warte auf eine Werbeaktion. Dann gibt es sie vielleicht zu einem Preis, der dir mehr zusagt, und hier dann wirklich auch über das erste Jahr hinaus. Letztens war sie dann auf Dauer billiger als bei deinem Vergleichsangebot.

Zitat von vollkommen_planlos

nur noch Kotzen

Wenn du dazu von einem/r "Offiziellen" aufgefordert wirst, kannst du die Ticketnummer posten (oder wahrscheinlicher, in einer Direktnachricht mitteilen). Wie schon mehrfach erwähnt wurde: Dies ist ein Kundenforum. Die Ticketnummer gehört hier nicht hin, weil damit niemand etwas anfangen kann. Ansonsten: Wie in jedem anderen Forum oder neuen Setting auch, nicht gleich nach ein paar Wortmeldungen den Leuten vor die Füße kotzen. Reiß dich zusammen. Hier gibt es Regeln.

This is a customer forum. We can only help you with things that you can in principle do yourself, because none of us have any administrative access. That said, what makes you believe that the server is located in Germany? Is it IP-address location? Netcup is a company with roots in Germany and Austria. Addresses in use can be recorded as German in ip address location databases and still be used for servers in the US in reality.

You can get a practically definitive answer by measuring the round-trip time to/from known locations. For example, use the Anexia Looking Glass ping tool from locations in Nuremberg (Germany) and Manassas (US). You should see RTTs much less than 10ms from the location where your server actually is and roughly 100ms RTTs from the location on the other side of the ocean.

Wenn es die Nicht-Funktion der API mit Netcup CloudDNS ist, dann ist ein Lösungsansatz (außer der Registrierung der Domain bei einem anderen Hoster), die Nameserver auf einen anderen Betreiber umzustellen, z.B. Cloudflare oder deSEC und die dortige API zu nutzen.

Wenn du die API nur für Letsencrypt brauchst, kannst du auch nur einen CNAME für die _acme-challenge Subdomain anlegen und auf einen Domainnamen zeigen lassen, den du mit einer API bearbeiten kannst. Damit können nicht alle ACME Clients umgehen, aber der Standardclient kann es.

Ich mache das so, also CNAME auf einen Domainnamen bei deSEC und Token bei deSEC hinterlegen, um die Letsencrypt DNS01-Challenge durchzuführen. Die Netcup-API habe ich nie benutzt, obwohl sie bei mir funktionieren würde, weil meine Domains noch nicht auf das neue System migriert sind. Für mich ist das eine Sicherheitsfrage: Die eigentlichen Domaindaten sind durch die Aufteilung nur manuell änderbar. Mit dem Logintoken für deSEC ist nur die _acme-challenge Subdomain erreichbar (via CNAME).

Fascinating. Have you tried telling it what interface to use?

Hast du die DNS-Einstellungen evtl. selbst gemacht?

"mail" ist nicht die selbe IP wie der Webserver sondern typischerweise die IP-Adresse des Webservers plus 2 ("db" ist die Adresse plus 1).

Zitat von ASS

Ich glaube die Anleitung die google Gruppen loszuwerden stammt aus diesem Forum.

Olivetti hat vor ein paar Monaten eine Anleitung für den Sieve Filter gepostet. Der Google Listen Spam war schon mehrfach Thema. Du hattest den Filter (aus einer anderen Quelle) auch schon erwähnt.

Just in case try the rescue system, which is a "cloudinit" configured GRML live Linux system. It should have IPv6 correctly configured and you should be able to connect out and in with IPv6. The Netcup firewall is automatically deactivated while the rescue system is activated, so that's one less thing to worry about. If the rescue system has working IPv6 connectivity, you can be sure that the problem is something under your control.