IPv6 mal wieder - OpenBSD

  • Ich habe seit zwei Jahren eine VPS mit OpenBSD laufen, bei der IPv6 meistens funktioniert hat, aber derzeit mal wieder nicht.


    Im Moment kann ich noch nicht mal fe80::1 anpingen, und der neighbor-Eintrag dafür wird mir auch immer als "expired" angezeigt:


    # ndp -a

    Neighbor Linklayer Address Netif Expire S Flags
    fe80::1%vio0 00:00:5e:00:02:02 vio0 expired D R

    Umgekehrt scheint das Gateway meine Adresse nicht zu lernen, denn es fragt dauernd neu danach:


    # tcpdump -l -n -i vio0 icmp6
    tcpdump: listening on vio0, link-type EN10MB
    23:16:50.683080 fe80::1 > ff02::1:ff00:ad15: icmp6: neighbor sol: who has 2a03:4000:6:f0d6::ad15 [class 0xc0]
    23:16:50.683354 fe80::5eb6:9ee7:4948:92bb > fe80::1: icmp6: neighbor adv: tgt is 2a03:4000:6:f0d6::ad15
    23:16:51.684370 fe80::1 > ff02::1:ff00:ad15: icmp6: neighbor sol: who has 2a03:4000:6:f0d6::ad15 [class 0xc0]
    23:16:51.684583 fe80::5eb6:9ee7:4948:92bb > fe80::1: icmp6: neighbor adv: tgt is 2a03:4000:6:f0d6::ad15

    Mir fehlt gerade die Idee, was da nicht stimmen könnte - ich kann mich nicht erinnern, die Konfiguration in letzter Zeit geändert zu haben (ich weiss, das sagt jeder ;) ...)


    Fällt jemand was dazu ein?

  • Passt diese Störungsmeldung?

    Leider nein - funktioniert immer noch nicht wieder. Auch wenn lustigerweise ein ping von außen schon am Decix hängen bleibt, aber andererseits weiss ich nicht, wie es ohne das Problem aussehen würde...


    PING 2a03:4000:6:f0d6::ad15(2a03:4000:6:f0d6::ad15) 56 data bytes
    From 2001:7f8::3:3a4:0:1 icmp_seq=5 Destination unreachable: Address unreachable

  • Hm, ich habe zwar kein Monitoring auf die Adresse - aber wenn ich mir mein Nameserver-Log so anschaue, dann funktioniert das seit ca. 17. Juli, 12:21 Uhr nicht mehr. Da fangen die Meldungen mit nicht per IPv6 erreichbaren Nameservern an. Vorher lief das (und bei dem Datum kann ich definitiv sagen, selber Kernel, selbe Konfiguration).


    Im tcpdump-Schnipsel oben sieht man ja auch, dass meine VM die neighbor solicitations beantwortet.

  • Hm ok. Ich behaupte ja weiterhin, an der VM nichts geändert zu haben, bevor es nicht mehr funktioniert hat... Aber ich habe zumindest rausgefunden, wie es wieder geht...


    Ich hatte testweise den Adaptertyp auf e1000 geändert (statt virtio) und dann debugging für Neighbor Discovery aktiviert (sysctl -w net.inet6.icmp6.nd6_debug=1). Bei der manuellen Konfiguration des Interfaces ist mir dann folgende Meldung im Kernel-Log aufgefallen:


    Jul 19 23:03:12 vm /bsd: em0: got Semantically Opaque Interface Identifier


    Die ifconfig - Manpage sagt dazu:


    soii Enable persistent Semantically Opaque Interface Identifiers
    (SOIIs), as per RFC 7217, for link local and SLAAC addresses on
    the interface. The purpose of these identifiers is to make
    discovery of hosts by scanning a whole prefix more difficult.


    Also "-soii" zu den inet6 - Interface-Optionen hinzugefügt, und schon geht's wieder (auch nachdem der Netzwerkadapter wieder als virtio läuft).


    Das muss mindestens seit dem Upgrade auf OpenBSD 6.3 vor einiger Zeit so gewesen sein, lief dann aber - bis vor kurzem - trotzdem erstmal?

  • Zitat

    Also "-soii" zu den inet6 - Interface-Optionen hinzugefügt, und schon geht's wieder


    Vielen Dank für den Hinweis, darüber bin ich auch gestolpert! Ich hab zwar nach wie vor nicht ganz kapiert was soii macht, aber ohne Deinen Hinweis hätte ich das nicht herausgefunden. Viele Grüße! :thumbup:

  • Moin,


    hier die Konfiguration die Stand 2022 mit Netcup VPS und OpenBSD 7.1 funktioniert - vio0 ist in diesem Fall das "Haupt-Interface":


    Änderung von Interface Optionen (sooi o.ä.) ist nicht mehr nötig. Aber slaacd scheint erforderlich zu sein (rcctl enable slaacd && rcctl start slaacd).


    Das %vio0 in der Standardroute für IPv6 scheint theoretisch nicht nötig zu sein, wenn nur ein einziges Interface vorhanden ist, schadet aber nicht (ich hatte es erst ohne %vio0, und mich dann beim Starten eines zusätzlichen Interfaces gewundert, warum IPv6 Konnektivität nicht mehr funktioniert - klar wenn die Standardroute eine Interfaceroute ist, muss das System wissen zu welchem Interface).

  • Beim Update von OpenBSD 7.1 auf OpenBSD 7.2 ging bei mir irgendwo die IPv4-Konfiguration hops - lustigerweise nur auf einem meiner Server, der andere tut mit derselben Netzwerkkonfiguration auch weiterhin problemlos seinen Dienst. Das äußert sich dann darin, dass ifconfig aussieht, als würde alles gehen, aber der Server komplett vom Netz abgeschnitten ist. Schön.


    Der Beitrag von AutoYaST löst auch dieses Problem bei mir. Ändern musste ich, dass die IPs hartkodiert sind, statt mich auf autoconf zu verlassen, und die ICMP-Freigabe war bis dato auch nicht vorgesehen (ging ja auch ohne). Ohne slaacd habe ich es nicht getestet, aber das ist mein Mailserver, den lasse ich nicht länger instabil als nötig.


    Jedenfalls: Danke!

    Intelligente Menschen sind manchmal gezwungen, sich zu betrinken, um Zeit mit Narren zu verbringen.
    (E. Hemingway)

    3 Mal editiert, zuletzt von tuxproject.de ()

    Gefällt mir 1