Beiträge von NaN

    Der Fehler ist in den Ausgaben nicht zu sehen, da sie nur die Konfiguration des Server zeigen. Ziemlich sicher hast du dem iPhone als AllowedIPs des Peers nur die IP-Adressen des WG-Servers angegeben. Dann wird auf dem iPhone auch nur dafür eine Route angelegt, und die umfasst dann nicht die Adressen in deinem Heimnetz. Das iPhone weiß also nicht, dass dein Heimnetz über den WG-Tunnel erreichbar sein soll. Umgekehrt wird das gleiche Problem auch bei der Fritzbox bestehen.

    Die AllowedIPs eines Peers sind nicht die Adressen, die der Peer ansprechen darf, sondern die, die er selbst verwenden darf, die also als Source-Adresse in Paketen vom Peer durch den Tunnel kommen dürfen. Was der Peer diesseits des Tunnels ansprechen darf, begrenzt Wireguard nicht. Das musst du mit einer Firewall machen.

    Transportsicherheit ist diesseits von Shops und Banken egaler als Google behauptet

    Vor dem flächendeckenden Einsatz von HTTPS waren Eingriffe der Netzbetreiber in die übertragenen Daten fast schon der Normalfall. Deswegen ist HTTPS absolut notwendig und die Unterscheidung in schützenswerte und nicht schützenswerte Daten völliger Unfug.

    auch jeglicher andere client der TLS machen will

    Natürlich dauert es, bis sowas so umgesetzt ist, dass man die alten Zöpfe abschneiden kann, aber das ist ja bei anderen Standards auch so.

    ob ich das zertifikat jetzt über eine CA oder lokal erneuere hat ja keinen einfluss auf die folgeprozesse der verteilung, reloads und verifikation?

    Mit direkt domainvalidierten Schlüsseln brauchst du nicht ständig neue Zertifikate, sondern änderst den DNS-Eintrag, wenn du den Schlüssel änderst, z.B. weil der kompromittiert wurde. Wenn du den alten Eintrag löschst, ist der alte Schlüssel unbrauchbar, nicht erst nach einem Jahr, drei Monaten oder einem Monat. Die Zertifikate könnten also problemlos viel länger laufen, bzw. man bräuchte eigentlich gar keine Zertifikate mit Ablaufdatum im klassischen Sinn. Man kann das weiterhin automatisieren, aber die Notwendigkeit wäre deutlich reduziert.

    Dass heute fast das ganze Web davon abhängt, ob und wie Letsencrypt Zertifikate ausstellt, ist ein Unding.

    was Du beschreibst ist doch DANE-EE?

    Dass ich nicht der erste oder einzige bin, der auf die Idee gekommen ist, ist mir klar. Solange sich die Browserhersteller weigern, das umzusetzen, spielen Standards keine Rolle.

    nicht nur

    Ja, schon. Kommt eben drauf an, was man unter Automatisierung versteht. Ist ja auch nicht nur Netcup, wo sowas passiert. Meine Bank hatte das schon und das hier (Netcup nutzt in der Werbung "Socialhub", und deren Linkshortener, sohub.io, hat ein abgelaufenes Zertifikat*) ist auch nicht Netcup's Schuld. Diese Rube-Goldberg-Konstruktionen, die man heute in der Systemadministration überall sieht, weil niemand Lust, Zeit oder Geld hat, irgendwas grundsätzlich zu lösen, sondern immer nur eine Abstraktion obendrauf geschaufelt wird, sind eben nicht einfach zu managen. Daraus entstehen dann solche Forderungen, dass man Zertifikate stündlich auf Ablauf überprüfen soll. Naja, wenn's Spaß macht.

    *) Deren Monitoring sagt übrigens "All Systems Operational".

    Bei den ganzen abgelaufenen Zertifikaten

    Wenn's nach mir ginge, würden die Schlüssel längst im DNS hinterlegt. DNSSEC wäre Voraussetzung, dass der Browser kein Ausrufezeichen dranmacht. Fast alle Zertifikate sind heute domainvalidiert. Was ist auch domainvalidiert? Die DNS-Einträge! Dieser ganze Eiertanz mit Zertifikaten ist ein völlig überflüssiger Kropf, der nur einen Single-Point-of-Sabotage erzeugt und nichts zur Sicherheit beiträgt. Aber: Solange die Browserhersteller nicht vernünftig werden, muss man den Kram eben automatisieren, und dann ist es egal, ob das Zertifikat drei Monate hält oder einen.

    Was wäre denn der tiefere Sinn dahinter? Die netcup Nameserver komplett vermeiden? Oder wird die Domain dadurch billiger? Schnellere Auflösung?

    Die Netcup Nameserver kann man auch mit einer Delegation zu einem anderen DNS-Provider vermeiden. Die Domain wird dadurch nicht billiger (aber auch nicht teurer). Schnellere Auflösung wäre ein Grund. Ausfallsicherheit könnte ich noch als Motivation anbieten: Wo weniger Server abgefragt werden müssen, kann weniger schiefgehen. DNSSEC ohne Keys irgendwo anders würde ich auch als Pluspunkt werten. Die Nachteile sind natürlich auch ziemlich gewichtig: Besonders MX ohne die Möglichkeit für TXT-Records ist ja praktisch sinnlos.

    Andere Hoster unterstützen es teilweise, aber auch da wohl nur über den Support.

    Afair gilt das nur für Domains die über Denicdirekt registriert sind.

    Eine kurze Suche hat gezeigt, dass es mindestens einen Domainprovider gibt, der das im normalen Webinterface anbietet. Das scheint also keine Spezialität von Denicdirekt zu sein und Handarbeit setzt das wohl auch nicht prinzipiell voraus. Hat das hier wirklich noch niemand versucht?

    Du könntest mal die Ausgabe von ufw status verbose posten, wenn du Schritt-für-Schritt Hilfe brauchst. Mit "verbose" bekommst du auch zu sehen, was passiert, wenn keine Regel zutrifft. Sonst gibt ufw status nur die Regeln aus. Die Regeln werden der Reihe nach abgearbeitet. Was du verboten hast, kannst du mit einer späteren Regel nicht wirksam erlauben.

    sieht solider aus

    Solider finde ich das nicht, und es ging ja darum, das Abmahnrisiko zu senken. Wer weiß, wofür man heutzutage schon datenschutztechnisch die Hosen runterlassen muss. Es ärgert mich jedenfalls bei einem Konkurrenten von Netcup, dass man dort die Webseite nicht abschalten kann. Hier geht es, wenn man will. Aber man kann ja mal die Reaktionen auf sowas testen, wenn man Spam mag:

    Code: .htaccess
    RewriteEngine On
    RewriteRule . "mailto:email@example.com?subject=Dies ist ein Test" [L,R=302]

    Sonst würde ich eher davon abraten, Email-Adressen auf Webseiten zu schreiben, wenn man nicht unbedingt muss.

    Du kannst die A und AAAA DNS Records für die Domain und ggf. die www Subdomain entfernen, ohne den Mailbetrieb zu beeinträchtigen. Welche Records das genau sind, kommt darauf an, ob es Wildcard Records gibt. Die Einträge für "@" sind für die Domain selbst, "www" oder "*" für die Subdomain bzw. für alle Subdomains. DNS-Einstellungen machst du im CCP bei der Domain. Wenn du Wildcard Einträge hast und behalten möchtest, kannst du für "www" andere Records festlegen. Wenn "www" z.B. einen TXT Record mit beliebigem Inhalt hat, dann gilt ein Wildcard-A-Eintrag nicht für "www". Das ist etwas sauberer, als eine nicht funktionierende IP-Adresse zu hinterlegen.

    Wer die typische Konfiguration von Netcup kennt, kommt auch ohne die DNS-Einträge an deine Webseite, also betrachte die nicht als unzugänglich sondern nur als versteckt. Eine Alternative könnte sein, eine .htaccess Datei im Hauptverzeichnis der Seite abzulegen und darüber eine Passwortabfrage für die Webseite zu verlangen, wenn du noch selbst die Seite aufrufen können möchtest, oder den Zugriff komplett zu verweigern. Beide Varianten zeigen gar keine Inhalte an: Die Passwortabfrage macht der Browser, nachdem er einen 401 "Unauthorized" Status Code vom Server bekommen hat, oder er zeigt eben eine Zugriff verweigert Fehlermeldung an, wenn er 403 "Forbidden" bekommt.

    Falls es auf htm(l) beschränkt sein soll, braucht es noch zusätzliche Regeln

    Nö:

    Apache Configuration
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*\.html?)$ DESTINATION/$1 [L,R=301]

    Der \ macht den . zum normalen Zeichen. Das ? macht das l optional. 301 ist der Code für eine dauerhafte Umleitung, die die alte URL ersetzt. 302 wäre für eine temporäre Umleitung, bei der die alte URL quasi noch existiert (aber im Browser wird bei beiden die URL angezeigt, zu der umgeleitet wird). Ohne R ist es eine interne Umleitung und die Zielseite wird unter der URL der nicht vorhandenen Seite ausgegeben.

    .htaccess im kuv Verzeichnis:

    Code
    ErrorDocument 404 /

    Die Seite wird dann aber als Fehlerdokument mit dem Statuscode 404 übertragen. Du kannst dir auch was mit mod_rewrite bauen. Da gibt es einen Test, ob eine Datei existiert, den du in einer RewriteCond vor eine RewriteRule setzen kannst. Je nachdem, was man will, wäre das besser oder schlechter. Die Dokumentation hat die nötigen Informationen.

    Der Provider vermittelt dir nicht nur die Leistung der Registry sondern hostet die Domain auch. Das tut er dann länger, als du ihn für die Domain bezahlst, wenn er sich mit der Ein-Jahres-Zahlung bis zum Ende der schon bezahlten Zeit bei der Registry plus ein Jahr zufrieden gibt. Im Prinzip kann das auch viel mehr als ein paar Monate extra sein: Einige TLD-Registries kann man bis zu 10 Jahre im voraus bezahlen.

    Ich kenne beides, auch dass Provider das bei der gleichen TLD unterschiedlich handhaben. Man kann die Laufzeit bei einigen TLDs im Whois sehen. Da steht dann z.B. bei einer .org Domain, bis wann die aus Sicht der Registry bezahlt ist. Wenn man zu einem Provider wechselt, der die Vertragslaufzeit ab sofort zählt, obwohl noch Restlaufzeit vorhanden war, dann zeigt die Registry an, dass die Domain länger bezahlt ist, als der Vertrag beim Provider läuft. Die Restlaufzeit ist dann nicht weg, sondern taucht bei einem weiteren Wechsel zu einem Provider, der erst ab der nötigen Registry-Verlängerung berechnet, wieder auf. Der Provider wird dann zwar nur für 12 Monate bezahlt, muss aber natürlich gewisse Leistungen für eine längere Zeit bereitstellen. Deswegen machen das nicht alle so kundenfreundlich.

    Geht es dir um's Prinzip, weil du das Attachment nicht sehen kannst (ich auch nicht), oder interessiert dich der Inhalt? Das wird ein Screenshot gewesen sein, wie man in einer Fritzbox eine GRE-Freigabe macht. Nicht schwer: Im selben Dialog wie TCP und UDP Freigaben, nur als Protokoll GRE auswählen. Weitere Einstellungsmöglichkeiten gibt es nicht. Alle GRE-Pakete gehen dann an das Gerät, für das die Freigabe eingerichtet wird. Es ist nur eine solche Freigabe möglich.