Beiträge von chrko

  • IPv6 Problem

    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.

  • IPv6 best practices

    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.

    Zitat von ip-route(8)

    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).

  • IPv6 best practices

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

    resultiert in

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

  • IPv6 best practices

    Ich mach die primäre Absender etwas anders:

    Code
    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/anyip-…-linux-machine/

  • Firewall vor Root Servern?

    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.

  • Hohe Festplatten-IO bei der Suche von E-Mails (Dovecot-IMAP)

    Zitat von killerbees19

    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.

  • Firewall vor Root Servern?

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

    Code
    pkt = IPv6(dst='…')/'Random String'
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.

    Zitat von RFC 8200 - Internet Protocol, Version 6 (IPv6) Specification - 4.7. No Next Header
    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…

  • Firewall vor Root Servern?

    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.

  • Reverse DNS Deligation für IPv6

    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 :)

  • Fehler bei der rDNS-Verwaltung

    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

  • Das längste Thema

    Zitat von rerdmann

    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. :(

  • Ostern 2019

    Zitat von ninguem

    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.

  • Ostern 2019

    Zitat von Maxi.2k02

    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.

  • nftables IPv6 Regeln: ICMPv6 nicht möglich

    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 ;)

  • Zusätzliche IP-Interface ohne Sicherheitsabfrage

    Zitat von mlohr

    Ich verstehe, dass Netcup Dinge optimieren muss, um die wirklich günstigen Preise auch so anbieten zu können. Was ich allerdings nicht verstehe ist, wieso das Routen eines Subnetzes/einer IP per SCP automatisiert und kostenlos geht und das loslösen von einem Server nicht. Wäre das auch komplett automatisiert, hat der Support dadurch auch keine Arbeit - und es wäre möglich, das zumindest günstiger anbieten zu können. Nach meinem Verständnis wird beim Zuweisen irgendwo ein "route add" o. Ä. ausgeführt. Könnte man nicht genauso einfach ein "route del" automatisieren?

    Das gibt es ja auch automatisiert, aber eben zu einem höheren Preis (5€ pro anstatt 1€).

    Eine kurze Abfrage bevor eine IPv4 bzw. ein v6-Netz fest gebunden wird, finde ich sinnvoll. Für das Failover-Pendant finde ich es jedoch wiederum unnötig.

    Das loslösen finde ich mit 25€ auch ziemlich teuer. Falls das zB für 12€ (also die Jahresgebühr einfach, aber man behält die gleiche IP) möglich wäre, würde ich das sehr begrüßen :)