Beiträge von oliver.g

    Ok das klappt bei mir nicht. Bei mir kommt irgendwas von API-RECTIFY. Weiss aber nicht weshalb. Muss mich da mal mit Beschäftigen. Auf die schnelle habe ich nichts gefunden. Ggf hast ja du eine Idee?

    Hast du dich an die Anleitung von GitHub gehalten (nGinx, Gunicorn)?

    Wie gesagt, Setup ist seit kurzem nicht mehr aktuell, aber es war wie folgt:

    1. Ja, 1 Hidden Primary Master und 3 Slaves. Der Hidden Primary Master (ns0) ist der Master Server, auf dem die Zonen verwaltet werden. Dieser ist nur aus dem VLAN erreichbar und daher nicht öffentlich zugänglich. Dieser sendet Zonenupdates per AXFR an meine 3 Slaves (ns1, ns2 und ns3), die public erreichbar und bei meiner Domain als Nameserver eingetragen sind.

    2. Jeweils PowerDNS drauf, ja. Der ns0 ist als Master konfiguriert, die anderen als Slave

    3. Alle Server bei netcup 8)

    4. Eine MySQL DB für den Master, die Slaves hatten ihre lokale SQLite DB

    5. PowerDNS Admin nur auf dem Master, auf den Slaves kann man in den logs prüfen ob die AXFRs reinkommen. Ansonsten merkt man auch schnell, wenn was kaputt ist. In der ganzen Laufzeit gab es aber keine Sync issues.

    6. Wie gesagt, die Domains werden auf dem Master verwaltet. Die Slaves sind schnell konfiguriert. Die bekommen in die supermasters Tabelle in ihrer DB einen Eintrag, wer als Supermaster zugelassen ist und fertig. Der Rest läuft über AXFR, die Records für DNSSEC werden also ebenfalls darüber auf die Slaves transferiert und damit public gemacht.

    Hi, so ein Setup hatte ich auch.

    1. Als GUI hat sich bei mir PowerDNS-Admin etabliert. Ist leicht zu installieren, lässt sich an LDAP anbinden (kein muss) und du kannst DNSSEC mit einem Klick pro Domain aktivieren.

    2. Mit AXFR hatte ich noch nie Probleme. In meinem Setup gibt es immer einen Hidden Primary Master und 3 Slaves, die per AXFR versorgt werden.

    DNSSEC gilt immer für die Hauptdomain und alle Records darunter, also auch die Subdomains.

    Zu 2.: Du musst für den SMTP Dane natürlich auch einen Record a la _25._tcp.mail.example.de angelegt haben.

    Wieso lauscht dein SMTP nicht auf 25? Dann ist ein Mail Empfang nicht möglich.

    Zu 3.: Du kannst für jede Subdomain einen Record anlegen ja, bei einem Wildcard Cert bietet sich aber auch ein Wildcard Record an.

    Ja das mit den Limits ist wirklich so eine Sache. Beziehen die sich pro IP oder pro E-Mail die man angibt bei der ersten generierung auf dem Server?

    Ich meine die Limits sind pro CN des Zertifikats.

    Ich lasse das alles einmal pro Monat meinen Hidden Master NS per DNS Challenge machen und pushe sie auf den Storagespace, von dem die Server, die die Certs benötigen, diese dann runterziehen und die entsprechenden Dienste neu starten.

    Mir ist nur aufgefallen (Debian Stretch minimal Image), dass mein Außeninterface als ens3 bekannt aber als eth0 konfiguriert wurde. Mein VLAN Interface war als eth1 bekannt und nicht konfiguriert (wie auch erwartet). Das führte allerdings dazu, dass ens3 unkonfiguriert blieb.

    Sicherste Installation ist also weiterhin von ISO. Da weiß man genau, was wie eingerichtet ist.

    Hallo, da denkt man ja, gleiche Systeme verhalten sich auch gleich, leider tun sie das bei mir nicht. Folgende Konstellation:

    - "Alter" VPS: Neu installiertes Debian 9 minimal Image. Nach Installation dem VLAN Interface 192.168.100.201 zugewiesen. Dann ein Domainjoin auf meinen DC (192.168.100.100):

    Code
    realm --verbose join verioweb.loc

    Resultat: "* Successfully enrolled machine in realm"

    - Neuer RS2000 Neujahrskracher: Neu installiertes Debian 9 minimal Image. Nach Installation dem VLAN Interface 192.168.100.202 zugewiesen. Dann ein Domainjoin auf meinen DC (192.168.100.100):

    Code
    realm --verbose join verioweb.loc

    Resultat: "! Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot contact any KDC for realm 'VERIOWEB.LOC')

    adcli: couldn't connect to verioweb.loc domain: Couldn't authenticate to active directory: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot contact any KDC for realm 'VERIOWEB.LOC')

    ! Insufficient permissions to join the domain

    realm: Dem Bereich konnte nicht beigetreten werden: Insufficient permissions to join the domain"


    Wohlgemerkt: Identische Vorgehensweise. Falsches Passwort für den Domain Admin, DC nicht erreichbar/pingbar kann ich ausschließen, alles getestet. Pings laufen fröhlich hin und zurück. Auch ein MTR sieht unauffällig aus. Dennoch scheinen die Kerberos Anfragen ins leere zu laufen (vielleicht irgendein Filter auf den Hostsystemen im Weg...). Das passiert auf den beiden von mir bestellten Neujahrskrachern. Die restlichen Server von mir funktionieren ohne Probleme in dieser Domain.

    Hat jemand ähnliche Probleme? Wie ich in einem anderen Thread gelesen habe gab es ja auch schon Probleme mit hängen gebliebenen Installationen von Images. Evtl. läuft da also etwas nicht ganz rund. Alleine ein Support Ticket zu schreiben macht m. E. noch keinen Sinn, da wahrscheinlich die Standardantwort kommen wird. Aber falls noch jemand Probleme hat, ist die Chance größer, dass dem nachgegangen wird.

    AHA, da haben wir den Fehler doch: Das Routing im SCP alleine reicht nicht aus, der Server selbst muss die Zieladresse auch konfiguriert haben. Du musst deinem Netzwerkinterface also noch die angegebene Adresse aus dem 2a03:4000:32:112:: Subnet zuweisen. Erst dann kommen die Pakete eben auf dieser Adresse an (Siehe die Adresse mit der roten Umrandung oben in meinem Screenshot).

    Hi, nein, das hast du schon richtig verstanden. Der einzige Unterschied zwischen Failover IPv6 und Zusatz IPv6 ist, dass du das Failover jederzeit ohne Zusatzkosten auf einen anderen Server routen kannst, wohingegen das Zusatzsubnet einmal einem Server zugewiesen wird. Willst du es anschließend auf einen anderen Server routen musst du eine Bearbeitungsgebühr bezahlen.

    Mal ein evtl. ganz dummer Hinweis: Die Zieladresse aus deinem Standard IPv6 hast du deinem Server als Zieladresse für das Routing zugewiesen oder? Ohne die funktioniert das Routing nämlich nicht:

    pasted-from-clipboard.png

    Port verlegen bringt dir Ruhe im log ;) Die wenigsten Bots machen sich die Mühe und scannen alle Ports ab.

    P. S.: Ich will jetzt nicht wieder die Diskussion zum Thema "Portverlegung führt zu keinem Sicherheitsgewinn" lostreten, das wurde oft genug durchdiskutiert. Aber es bringt eben Ruhe ins log.