Beiträge von voja

    Vielen Dank für die Erklärung Herr Preuß. Ich bin halt Fan von monatlicher Zahlungsweise. Aber die würde in manchen Fällen dann natürlich zu höheren Preisen führen, was dann aber auch wieder schlecht für das Produkt wäre.

    Wenn jetzt unsere Mitbewerber auch für bestehende Produkte die Preise erhöhen, lohnt sich ein Wechsel zu uns sicherlich. Wenn genügend wechseln möchten, planen wir diesbezüglich gerne eine weitere Aktion, um die Preise unserer HerbstAktion länger halten zu können.

    Interessant ist hier auch noch der Kostenfaktor der IPv4-Adressen und des monatlichen Lastschrift Einzugs. Bei letzterem habe ich mich schon immer gefragt warum manche Produkte nicht mit monatlicher Laufzeit angeboten werden.

    Der Webserver muss nicht neustarten, sondern nur ein reload durchführen. Dadurch werden keine Verbindungen getrennt und die alten Verbindungen nutzen weiter die ausgehandelten Keys.

    Ich dachte da was im Bezug auf die neuen Plesk basierten Webhosting Pakete gelesen zu haben. Die certbot Beispiele für die nginx pre/post hooks zeigen auch stop/start, aber er macht bei nginx in der Tat nur einen reload, wenn man im Code nachschaut. Nur im Output steht überall restart, das macht er aber in der Tat nicht, deswegen aber leicht misszuverstehen.

    Ich möchte noch anmerken dass nur alte Zertifikate von dem Vertrauensentzug betroffen sind. Reissue und gut ist. Es entsteht also eigentlich gar kein Problem da bis dahin die Zertifikate entweder abgelaufen sind oder neu ausgestellt wurden.

    LE läuft erst mit den neueren certbot Versionen problemlos. Bei den älteren fehlte öfter mal der Cron. Monitoring ist bei LE noch wichtiger, da zu vorher nicht unbedingt ersichtlichen Zeitpunkten der Webserver neu startet. Das führt zu einem kurzen Ausfall.

    Bei manuellem Austausch hat man darüber mehr Kontrolle.

    Wenn Du eine https only Seite willst, musst Du in Wordpress die siteurl mit https Prefix einstellen. Wenn dort http drin steht, schickt Dich Wordpress auf http und Cloudfare auf https usw.

    Alternativ gibt es auch Plugins mit denen Du steuern kannst welche Teile der Webseite https sein sollen und welche nicht. Das muss aber mit den Cloudflare Einstellungen zusammen passen.

    Danke für die Denkanstöße


    Durch das tcpdump bin ich drauf gekommen dass das KVM wirklich nur mit der ens3 MAC-Adresse redet. Die Container hängen wie oben besprochen an der Bridge von ens3. Vom Container aus wird IPv4 auf die Haupt-IP der VM geroutet, damit die Pakete mit der MAC vom ens3 Device zum Router geschickt werden. So weit so klar.

    Im Bezug auf IPv6 heisst das: die proxy ndp Einstellungen vom Linux Kernel helfen hier nicht weiter. Die Container können zwar auf die Frage welche MAC Adresse zu einer IPv6-Adresse gehören antworten. Die kommen aber von der Container MAC und erreichen damit den Router gar nicht.

    Ohne den ndppd kommt man an der Stelle dann also nicht weiter. Das schöne ist, dass die aktuelle ndppd Version in Ubuntu 16.04 eine neue Option static hat. Darüber können dann für Einzel IPv6 (/128) oder auch kleine Netze die NDP Anfragen mit der ens3 MAC beantwortet werden, ohne dass das komplette Subnetz mit allen IPs aufgelöst werden kann. Das könnte ja die internen Tabellen sprengen.

    Wenn man den ndppd verwendet muss man aber trotzdem noch proxy ndp im Kernel für alle Devices erlauben. Ich habe nicht verstanden wieso, aber nur mit der Option klappt es.

    Generell habe ich noch nicht verstanden ob mit der Methode irgendwelche Pakete doppelt im Container ankommen können. Auf jeden Fall war ich mit der Erreichbaren Datenrate im Container ganz zufrieden.

    Und wo ich noch drüber gestolpert bin: in ufw muss man natürlich die Default Regeln für die FORWARD Queue auf ACCEPT stellen, sonst geht auch kein Traffic durch.

    Insgesamt funktioniert nun LXD prima in dem Root-Server. Ich werde nun die Container mit meinen Diensten aufsetzen und dann mal weiter sehen wie der Root-Server so läuft.

    Folgendes gibt das tcpdump aus, wenn ich versuche von extern eine SSH-Verbindung auf den Container (anonymisiert als 2a03:4000:A:B::C) aufzubauen:

    Code
    23:27:17.496502 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::f21c:2d00:797d:40c0 > ff02::1:ff00:53: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a03:4000:A:B::C
    23:27:17.496858 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2a03:4000:A:B::C > fe80::f21c:2d00:797d:40c0: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2a03:4000:A:B::C, Flags [solicited, override]
    23:27:18.495848 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::f21c:2d00:797d:40c0 > ff02::1:ff00:53: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a03:4000:A:B::C
    23:27:18.496153 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2a03:4000:A:B::C > fe80::f21c:2d00:797d:40c0: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2a03:4000:A:B::C, Flags [solicited, override]
    23:27:19.528440 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::f21c:2d00:797d:40c0 > ff02::1:ff00:53: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2a03:4000:A:B::C
    23:27:19.528573 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2a03:4000:A:B::C > fe80::f21c:2d00:797d:40c0: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2a03:4000:A:B::C, Flags [solicited, override]


    Das sieht für mich wie das richtige Frage/Antwortspiel vom NDP aus.