IPv6 manuell starten

  • Moin

    IPV4 manuell im Terminal zu starten, ist ja ne einfach Übung... mit gesetzter resolv.conf reichen 2 Befehle:

    Code
    ip link set dev eth0 up
    dhclient eth0

    Weiss jemand, ob man das mit IPv6 auch machen kann? Also... der IPv4-Stack und IPv6-Stack sind beide enabled, aber es wird beim Systemstart kein Netzwerk gestartet. Ich habe das deaktiviert, um das mal von Hand nachzuvollziehen. Mit IPv4 (s.o.) ist das kein Problem, mit IPv6 krieg ich das nicht hin... selbst dann nicht, wenn ich vorher eine korrekte (passend zum IPv6-Netz im Router) Unique Local Adresse (fd00:10.10.10::100/24) zuweise. Irgendwie muss man ja SLAAC und das Router Advertisement anstoßen.... ich weiss nur nicht, ob man das überhaupt manuell machen kann. Hat das schon mal jemand erfolgreich getan...?... wenn ja, wie?

  • Eigentlich hätte spätestens deine erste Codezeile SLAAC auslösen müssen.

    Es kann aber durchaus sein, dass, wenn du Netzwerk beim Systemstart deaktiviert hast, auch der Kernel sich nicht mehr für RAs interessiert, nachprüfbar mit sysctl -a

    u.a.

    Code
    net.ipv6.conf.eth0.accept_ra = 1
    net.ipv6.conf.eth0.autoconf = 1
  • ... das Router Advertisement anstoßen.... ich weiss nur nicht, ob man das überhaupt manuell machen kann.

    Das sollte man mit einem rs machen können:

    Code
    tcpdump -vvveni <Interface> ip6
    ndptool -v -i <Interface> -t rs send

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • thomasschaefer

    Genau das war das Problem... und genau darauf wäre ich die nächsten 5 Wochen nicht gekommen, weil ich das schlichtweg ausgeschlossen habe. :wallbash:

    Ich bin davon ausgegangen, dass "all" und "default" natürlich auch "enp2s0" umfasst.... so wars nämlich gesetzt, aber offensichtlicht fummelt systemd-networkd drin rum, denn tempaddr und accept_ra waren disabled.... für mich völlig unverständlicherweise.

    rpi444

    ntptool war nicht installiert, und weil ich zunächst weitergekommen bin, habe ich erstmal auf die Installation verzichtet.

    Danke für die 2 Ratschläge. Aber dennoch... jetzt habe ich ein Folge-Problem, dass ich nicht interpretieren oder verstehen kann. Dazu mal meine kleinen Schritte, ich hoffe, mir gelingt es so aufzubereiten, dass man nicht genervt die Augen verdreht:

    1. Alle Netzverbindungen schließen und alles schön "sauber" machen ... dann gucken ob's sauber ist.

    Code
    systemctl stop systemd-resolved systemd-networkd
    ip link set dev enp2s0 down
    ip addr flush dev enp2s0
    
    ip -6 a
    ip -6 r s

    2. Checken, was networkd wieder gemacht hat und korrekt neu setzen... Ergebnis:

    Code
    sysctl -a | grep conf.enp2s0 | egrep "tempaddr|autoconf|accept_ra ="
    net.ipv6.conf.enp2s0.accept_ra = 1
    net.ipv6.conf.enp2s0.autoconf = 1
    net.ipv6.conf.enp2s0.use_tempaddr = 2

    3. Interface öffnen und lokale IP setzen, passend zum Netz im DSL-Router

    Code
    ip link set dev enp2s0 up
    ip addr add dev enp2s0 fd00:1:1:1::200/64

    4. Routen setzen... für den Prefix-Kram, und für die lokalen Adresse auf die lokale Adresse des Routers (deswegen LLA plätten)

    Code
    ip route add 2003::/16 via fd00:1:1:1:8e28:ff6z:fe11:z17 dev enp2s0 proto ra metric 1024 dev enp2s0
    ip route del default via fe80::8e28:ff6z:fe11:z17
    ip route add default via fd00:1:1:1:8e28:ff6z:fe11:z17

    5. Kontrolle (sieht genauso aus, als hätte es systemd-networkd gemacht)

    Code
    # ip -6 r s
    2003:17:3yz:b211::/64 dev enp2s0 proto kernel metric 256  expires 7187sec pref medium
    2003::/16 via fd00:1:1:1:8e28:ff6z:fe11:z17 dev enp2s0 proto ra metric 1024  pref medium
    fd00:1:1:1::/64 dev enp2s0 proto kernel metric 256  pref medium
    fe80::/64 dev enp2s0 proto kernel metric 256  pref medium
    default via fd00:1:1:1:8e28:ff6z:fe11:z17 dev enp2s0 metric 1024  pref medium

    6. Kontrolle 2 (sieht auch alles gut aus)

    7. Kontrolle 3 (Namensauflösung = klappt auch)

    Sieht doch wirklich alles gut aus... ein reines IPv6-Netzwerk.... es funktioniert.... aber nur fast... denn mit Palemoon gehts nur teilweise:

    debian-forum OK

    raspberry-pi-forum OK

    ubuntu-users OK

    linux-mint nicht ereichbar

    google OK

    qwant nicht ereichbar

    startpage nicht ereichbar

    GMX nicht ereichbar

    Thunderbird lokaler Mailerserver =OK, gmx nicht erreichbar,

    Und an dem Punkt bin ich jetzt überfordert.... warum geht nur ein Teil, ein anderer nicht? Ich dachte immer, die ISPs würden dafür sorgen, dass auch reine IPV6-Clients IPv4-Hosts erreichen können... was bei mir aber nur teilweise gelingt. Kann das noch eine lokale Ursache haben?

    2 Mal editiert, zuletzt von WinterUnit16246 (20. August 2018 um 17:52)

  • Ich dachte immer, die ISPs würden dafür sorgen, dass auch reine IPV6-Netze Ipv4-Hosts erreichen können...

    Ich denke, das ist nur dann möglich, wenn Du lokal (neben dem IPv6-Netz) auch ein IPv4-Netz hast.

    EDIT:

    Z. B.:

    Code
    :~ $ mtr -6nr -c 2 -i 2 193.99.144.80
    Failed to resolve host: Address family for hostname not supported

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (20. August 2018 um 17:59)

  • Ich denke, das ist nur dann möglich, wenn Du lokal (neben dem IPv6-Netz) auch ein IPv4-Netz hast.

    Mir ist im Nachgang noch mein Fehler aufgefallen.... ein Begriff... den ich dann oben noch korrigiert habe. "...die ISPs würden dafür sorgen, dass auch reine IPV6-NetzeClients IPv4-Hosts erreichen können." Mein PC war zwar nach diesem "Eingriff" ein reiner IPv6-PC, aber der Router selber hatte natürlich noch seine IPv4s für WAN und LAN.

    Ist es richtig, wenn ich Deine Antwort so interpretiere, dass das Verhalten zwischen meinem IPv6-Client und den IPv4-Hosts trotzdem ok ist...?... wenn IPv4-Hosts dann nicht erreichbar sind? Ich gehe mal davon aus, dass meine Fritte noch keine 6to4-Translation macht/kann.

  • Ist es richtig, wenn ich Deine Antwort so interpretiere, dass das Verhalten zwischen meinem IPv6-Client und den IPv4-Hosts trotzdem ok ist...?... wenn IPv4-Hosts dann nicht erreichbar sind?

    Ja, ich denke, dass das Verhalten richtig ist. Was Du mit einem reinen IPv6-Internetanschluss dann brauchst, ist m. E. 4in6-Tunneling. Aber das wird ohne lokalen IPv4-Client nicht funktionieren.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!