Posts by chrko

    Es ist der feine Unterschied zwischen blockieren und drauf hören/reagieren:

    Im Netcup v6 Setup werden auch vom Router Router Advertisments gesendet. Da dies aber gerne mal zu Problemen führt, sollte man die default route statisch konfigurieren und das Verarbeiten derer deaktivieren, siehe die Empfehlungen sysctl Einstellungen im netcup Wiki.

    Ich bin persönlich der Meinung, dass ICMP in irgendeiner Art abdrehen nicht sinnvoll und ratsam ist. Es fällt in der Regel einfach unter das Konzept "Security by Obscurity" und naja, die meisten Informationen, die man via ICMP bekommen kann, – wenn nicht alle – gibt es auch über andere Wege und Optionen.

    Bei IPv6 MUSST du gewisse ICMPv6 Typen in der Firewall freischalten, sonst kann IPv6 nicht ordentlich funktionieren.

    Der Effekt ist in meinen Anwendungsszenarien analog zu preferred lifetime auf 0 zu setzen. Wenn nicht explizit eine Absenderadresse gesetzt ist, wird beim Nutzen der entsprechen Route diese Adresse genutzt.

    the source address to prefer when sending to the destinations covered by the route prefix.

    Man muss nur verstehen, dass man dort mit einen anderen Mechanismus arbeitet.


    Und nein - der Server antwortet z.B. auf ICMP(v6) Echo Requests nicht immer mit dieser Adresse; ich muss aber gestehen, dass ich erst noch mal nachlesen müsste, mit welcher Priorität das den Source Address Selection Prozess genau beeinflusst.


    Ehrlich gesagt grübel ich gerade auch, wieso ich eigentlich diesen Weg gewählt habe… (und woher ich den initial habe).

    Code: /etc/sysctl.conf
    1. net.ipv6.conf.all.accept_ra=0
    2. net.ipv6.conf.eth-extern.accept_ra=0
    Code: /etc/udev/rules.d/70-persistent-net.rules
    1. SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="b6:db:d5:c8:3c:b1", NAME="eth-extern"


    resultiert in


    Code: ip -6 route
    1. 2a03:4000:6:x::/64 dev eth-extern proto kernel metric 256 pref medium
    2. fe80::/64 dev eth-extern proto kernel metric 256 pref medium
    3. default via fe80::1 dev eth-extern src 2a03:4000:6:x::1 metric 1024 pref medium

    Ich mach die primäre Absender etwas anders:

    Code
    1. post-up ip -6 route change default via {{ network.gateway }} dev {{ network.iface }} src {{ addr | ipv6('address') }}


    Bzgl. der Frage, wie viele IPs an Interface: Bei IPv6 so viel du willst, es nur irgendwann nicht effizient. Man kann aber auch auf ganze Präfixe lauschen - es ist nur nicht ganz trivial. Zusätzlich zu den erwähnten Dingen im Artikel muss man bei netcup beachten, dass das erste IPv6-Netz "geswitched" und nicht geroutet ist, d.h., dass man dem Router via Neighbor Discovery Protocol mitteilen muss, dass es diese Adresse gibt…

    https://blog.cloudflare.com/how-we-built-spectrum/

    https://blog.widodh.nl/2016/04…et-to-your-linux-machine/

    Das ist doch zumindest eine halbwegs erfreuliche Nachricht!

    Gab es eine Begründung, wieso andere Next Header gesperrt sind/waren?

    Mir erschließt sich nämlich nicht der Unterschied Richtung IPv4; also weshalb dort glücklicherweise alles frei ist.

    Prinzipiell schon, wenn man die im Wiki angesprochenen Besonderheiten beachtet. Das kann ich mit einem kleineren Setup bestätigen, bei dem ich es seit einigen Jahren als (mittlerweile dauerhafte) Notlösung in Kauf nehme. Aber von der Performance her kann ich mir kaum vorstellen, dass Du groß dazu gewinnen wirst.


    Wenn ein richtiger Suchindex bei Dir Overkill ist, wäre das eines jener Paradebeispiele, wo ein SSD-Server auf jeden Fall Sinn macht. Ich muss immer schmunzeln, wenn User meinen, dass es bei Mailservern nichts Kritisches gibt, das schnell reagieren muss. Tja… ^^

    Es gibt übrigens eine (meiner Meinung nach) bessere Alternative, wodurch Postfix nicht selbst in die Mailbox schreiben muss: https://wiki.dovecot.org/LDA/Postfix

    Naja, es ist nicht nur eine alternative, dass Postfix nicht direkt ins Maildir kritzelt. Wenn Postfix ins Maildir schreibt, sind die dovecot-Caches und Indizes hinfällig…

    Also via dovecot-lda oder via LMTP (via Unix-Socket oder Port) an Dovecot übergeben.

    Ja, ich habe das eben zwischen zwei Servern bei netcup getestet… Firewall aus und einfach mal mit

    Code
    1. pkt = IPv6(dst='…')/'Random String'
    2. pkt.nh # == 59 (no next header)

    ein Paket zwischen den Server versucht auch zu tauschen. Es ging auf dem sendenden laut tcpdump raus, beim Empfänger kam nichts an.

    The value 59 in the Next Header field of an IPv6 header or any extension header indicates that there is nothing following that header. If the Payload Length field of the IPv6 header indicates the presence of octets past the end of a header whose Next Header field contains 59, those octets must be ignored and passed on unchanged if the packet is forwarded.


    Es sollte also ohne Probleme beim Ziel ankommen - selbst netcup intern mag es aber nicht…

    Ich habe das mal bei mir jetzt auch getestet.

    IPv4 Protos, die ich nicht im tcpdump gesehen habe:

    • 1
    • 6
    • 17
    • 47

    Das kann aber nun auch an anderen Stellen liegen.

    Die Beobachtung, dass bei IPv6 nur Proto 6, 17 und 50 durchgehen – zumindest nicht mehr, mit dem obigen Skript.

    Mir ist zuletzt mal wieder der magische Eintrag nobody.yourvserver.net auf die Füße gefallen.

    Mit der Delegation wäre das für mich persönlich - abseits der anderen Annehmlichkeiten die PTR Einträge automatisiert zu verwalten - mal wieder ein Herzensanliegen, wenn es vielleicht etwas voran geht mit dem Thema :)

    Mir ist das Thema zu Punkt 2 zuletzt mal wieder auf die Füße gefallen und ich habe es auch mal wieder via Support eingekippt.

    Der spezielle Eintrag verschwindet ja auch nicht irgendwann, sondern bleibt auf ewig bestehen. :(


    Vielleicht fällt es auch auf die Füße und dann wird vielleicht endlich mal dieser dämliche Fehler behoben.


    VG


    Christian

    Ja, das SCP ist momentan alles Anderes als performant, egal ob bei VPS 200, VPS 500 oder RS 1000. Nach dem Start eines Servers dreht der Kreisel sich ersteinmal mehrere Minuten.


    Ich habe mich mal an den Support gewandt.

    Und IPv6-Netze (neu)routen lassen dauert auch ewig… zusätzliche v4s, insbesondere Failover habe ich nicht, würde aber zunächst das gleiche Verhalten erwarten. :(

    Das ist meine erste Osteraktion hier. Ich finde es sehr angenehm, dass die Osterangebote heute immer noch aktiv sind, gerade weil ich über Ostern fort war und unterwegs auf meinem Mobilgerät leider keine Ostereier finden konnte. Unglücklicherweise sind die Webhosting Spezial Minis anscheinend inzwischen alle ausverkauft. Dann vielleicht ein anderes Mal.


    P.S. nur zum Verständnis: Die Angebote/Eier springen alle 10 Min. auf andere Seiten, aber wie oft kommen denn neue Angebote hinzu? Auch alle 10 Min. oder jede Stunde oder...?

    Neuer Kram kommt nur von Menschenhand hinzu.

    So manches dürfte jetzt halt bereits ausverkauft sein, und vermutlich wird jetzt auch nichts mehr aufgefüllt sondern nur noch Rückläufer kommen „neu“ hinzu.

    Bei jedem Produkt außer Domains ist doch eine Zufriedenheitsgarantie dabei auch egal welche Laufzeit oder?

    Kurzum: Nein. VPS zB nicht, nur Root Server (RS). Ich bin mir jedoch nicht sicher, wie es nun bei den Angeboten aussieht.

    IPv6 Konnektivität bedeutet nicht, dass ein Ping funktionieren muss.

    D.h. deine ursprünglichen Regeln waren soweit ich es überflogen haben ausreichend, so dass dein Host via IPv6 erreichbar ist, aber ICMPv6 Echo-Requests/Replys hast du in der Firewall schlicht blockiert (was man auch so machen kann).


    Grundsätzlich halte ich die Filterung von ICMP(v6) für nicht nötig, höchstens ein Rate Limit, damit nicht zu viele Ressourcen für diese Pakete verwendet werden. Den auch ohne ICMP(v6) Echo-Requests/Replys (Ping) kann man feststellen, ob ein IP(v6)-Adresse im Netz erreichbar ist.


    IGMP zuzulassen (wie in deinem letzten Post) halte ich für unnötig. Die wenigsten spielen im freien Internet mit Multicast rum und daher wird es dort auch nicht benötigt ;)