IPv6 geht mal und geht mal nicht ...

Started by BSAfH42, November 26, 2023, 04:05:59 PM

Previous topic - Next topic
Hab das nochmal auf der anderen Sense nachgestellt, mit einem SLAAC only Setup, vorher hatte ich immer auch DHCPv6 verwendet. Nach einem IP-Wechsel (PPPoE durch die Sense) ist der alte prefix lt. Windows immer noch gültig. Und das ist halt das Versagen der *Sense, denn die Fritzbox kann es wohl besser.

February 21, 2025, 11:40:10 AM #16 Last Edit: February 21, 2025, 05:51:16 PM by meyergru
Ich kann das Verhalten mangels wechselnden Präfixen weder testen noch weiß ich sicher, wie OpnSense das behandelt, aber klar ist, dass ein Wechsel der WAN-IP bei "Track Interface" eine Konfigurationsänderung und Neustart von radvd und dhcpd6 zur Folge haben müsste, damit die neue Interface-IP auch weiterverteilt wird.

Ob das der Fall ist, kannst Du sehen, wenn Du Dir den Inhalt von more /var/dhcpd/etc/dhcpdv6.conf und /var/etc/radvd.conf ansiehst und checkst, ob dort jeweils die entsprechenden, aktuell gültigen Interface-Präfixe drinstehen und ob die Prozesse neu gestartet wurden.

Ein synthetischer Test mit Deaktivieren und Neuaktivieren des WAN-Interfaces ist sinnlos, weil dabei mit Sicherheit die Services neu gestartet werden. Es kommt darauf an, ob das im laufenden Betrieb bei bloßer Änderung des Präfixes auch geschieht.

Wenn Du das Problem diagnostizieren kannst, kannst Du ja im Github einen entsprechenden Request einstellen, das wäre ggf. schon wichtig.



P.S.: Interessant, ich habe eben mal in den Code gesehen und folgendes gefunden:

# more /var/etc/dhcp6c.conf
interface pppoe0 {
  send ia-pd 0; # request prefix delegation
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc pd 0 {
  prefix ::/56 infinity;

Und in /var/etc/dhcp6c_wan_script.sh:

#!/bin/sh

case $REASON in
INFOREQ|REBIND|RENEW|REQUEST)
    /usr/bin/logger -t dhcp6c "dhcp6c_script: $REASON on pppoe0 executing"

    ARGS=
    for NAMESERVER in ${new_domain_name_servers}; do
        ARGS="${ARGS} -a ${NAMESERVER}"
    done
    /usr/local/sbin/ifctl -i pppoe0 -6nd ${ARGS}

    ARGS=
    for DOMAIN in ${new_domain_name}; do
        ARGS="${ARGS} -a ${DOMAIN}"
    done
    /usr/local/sbin/ifctl -i pppoe0 -6sd ${ARGS}

    ARGS=
    for PD in ${PDINFO}; do
        ARGS="${ARGS} -a ${PD}"
    done
    if [ ${REASON} != "RENEW" -a ${REASON} != "REBIND" ]; then
        # cannot update since PDINFO may be incomplete in these cases
        # as each PD is being handled separately via the client side
        /usr/local/sbin/ifctl -i pppoe0 -6pd ${ARGS}
    fi

    FORCE=
    if [ ${REASON} = "REQUEST" ]; then
        /usr/bin/logger -t dhcp6c "dhcp6c_script: $REASON on pppoe0 renewal"
        FORCE=force
    fi

    /usr/local/sbin/configctl -d interface newipv6 pppoe0 ${FORCE}
    ;;
EXIT|RELEASE)
    /usr/bin/logger -t dhcp6c "dhcp6c_script: $REASON on pppoe0 executing"

    /usr/local/sbin/ifctl -i pppoe0 -6nd
    /usr/local/sbin/ifctl -i pppoe0 -6sd
    /usr/local/sbin/ifctl -i pppoe0 -6pd

    /usr/local/sbin/configctl -d interface newipv6 pppoe0
    ;;
*)
    /usr/bin/logger -t dhcp6c "dhcp6c_script: $REASON on pppoe0 ignored"
    ;;
esac

Man beachte den Aufruf von "/usr/local/sbin/configctl -d interface newipv6 pppoe0 ${FORCE}" für den Fall einer IP-Erneuerung. Der "Hook" wäre also vorhanden. Ich habe festgestellt, dass zumindest mit "force" der dhcpd6 neu gestartet wird, radvd hat weiterhin die alte PID und in der Dokumentation wird kein Signal erwähnt. Selbst die Linux-Version von radvd sagt nichts über die Möglichkeit des Neueinlesens der Konfiguration durch ein Signal.

Es kann also tatsächlich sein, dass hier etwas fehlt - andererseits werden die Services eventuell nur dann neu gestartet, wenn sich die IP wirklich ändert. Es gab dazu schon früher Diskussionen: https://forum.opnsense.org/index.php?topic=21682.0

@Franco: Ist das so?
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Quote from: meyergru on February 21, 2025, 11:40:10 AMund ob die Prozesse neu gestartet wurden.

Wenn das hier die richtige Zeile ist, dann hat sich die PID auf der anderen Sense nicht geändert nach einem reconnect.
81367 root         20    0    13M  2824K select   0   0:01   0.00% /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog Die radvd.conf enthält aber ausschließlich den korrekten Prefix. Das Problem ist also nach wie vor, dass der alte nicht korrekt invalidiert wird. Keine Ahnung, ob das so auch noch die OPNsense betrifft. 

Wie gesagt, ich kann es nicht testen - aber bei Dir läuft ja auch "das andere Produkt", nicht OpnSense.
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+