Forum: PC Hard- und Software Probleme beim einrichten von IPv6


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

Hallo,

ich bin gerade dabei einen Router von Mikrotik (HAP Lite) einzurichten 
und hänge mal wieder an IPv6.

Gegeben ist ein statisches /48-Netz (2001:af:31::/48). Das Gateway hat 
die (2001:af:31::1).
Das WAN-Interface hat die 2001:af:31:ff00::1 und die Bridge die 
2001:af:31:ff00:234:a34:34b:455/64
1
/ipv6 route
2
add check-gateway=ping distance=1 gateway=2001:af:31::1

In der Firewall sind aktuell alle Regeln deaktiviert.

Der Router kommt per IPv6 in Internet und ist von außen anpingbar, aber 
die Clients dahinter kommen nicht per v6 ins Internet.

Hier die Ausgabe, wenn die Google anpinge:
1
[user@netbook ~]$ ping -6 google.de
2
PING google.de(fra24s04-in-x03.1e100.net (2a00:1450:4001:827::2003)) 56 data bytes
3
Von netbook (2001:af:31:ff00:2344:a3c1:3b4:f555) icmp_seq=1 Ziel nicht erreichbar: Adresse nicht erreichbar
4
Von netbook (2001:af:31:ff00:2344:a3c1:3b4:f555) icmp_seq=2 Ziel nicht erreichbar: Adresse nicht erreichbar
5
Von netbook (2001:af:31:ff00:2344:a3c1:3b4:f555) icmp_seq=3 Ziel nicht erreichbar: Adresse nicht erreichbar
6
Von netbook (2001:af:31:ff00:2344:a3c1:3b4:f555) icmp_seq=4 Ziel nicht erreichbar: Adresse nicht erreichbar
7
Von netbook (2001:af:31:ff00:2344:a3c1:3b4:f555) icmp_seq=5 Ziel nicht erreichbar: Adresse nicht erreichbar
8
Von netbook (2001:af:31:ff00:2344:a3c1:3b4:f555) icmp_seq=6 Ziel nicht erreichbar: Adresse nicht erreichbar
9
^C
10
--- google.de ping statistics ---
11
7 Pakete übertragen, 0 empfangen, +6 Fehler, 100% packet loss, time 6079ms

An was könnte das liegen.

Vielen Dank und viele Grüße

tr0ll

Edit: Falsches Unterforum.

: Verschoben durch Moderator
von Oliver S. (oliverso)


Lesenswert?

Was sagt denn ifconfig bzw. ipconfig auf dem Client? Kennt der den 
Router?

Oliver

von Thomas V. (tomv)


Lesenswert?

Woher hast Du denn das Netz 2001:af:31::/48? Das ist derzeit keinem 
Provider zugewiesen.

Dein Internet-Provider (wenn er IPv6 anbietet) sollte Deinem 
Internetrouter  ein global gültiges Netz per IPv6-Prefix-Delegation 
zuweisen. Dein Internet-Router stellt dann aus diesem Netz die Adressen 
für die Clients im LAN per SLAAC zur Verfügung. Alternativ auch per 
DHCPv6. Je nach Konfiguration.

von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

Oliver S. schrieb:
> Was sagt denn ifconfig bzw. ipconfig auf dem Client? Kennt der den
> Router?
1
[user@netbook ~]$ ip addr show enp2s0
2
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
3
    link/ether 22:35:64:64:cd:42 brd ff:ff:ff:ff:ff:ff
4
    inet 172.30.230.2/24 brd 172.30.230.255 scope global enp2s0
5
       valid_lft forever preferred_lft forever
6
    inet 172.30.230.30/24 metric 100 brd 172.30.230.255 scope global secondary dynamic enp2s0
7
       valid_lft 594970sec preferred_lft 594970sec
8
    inet 172.30.230.31/24 brd 172.30.230.255 scope global secondary dynamic noprefixroute enp2s0
9
       valid_lft 594978sec preferred_lft 519303sec
10
    inet6 2001:af:31:ff00:8740:330a:bae0:f0fb/64 scope global dynamic mngtmpaddr noprefixroute
11
       valid_lft 2591810sec preferred_lft 604610sec
12
    inet6 fd:c0:ff:ee:f59:b461:a64b:4288/64 scope global dynamic mngtmpaddr noprefixroute
13
       valid_lft 2591810sec preferred_lft 604610sec
14
    inet6 2001:af:31:ff00:2225:64ff:fe34:ce08/64 scope global dynamic mngtmpaddr noprefixroute
15
       valid_lft 2591809sec preferred_lft 604609sec
16
    inet6 fd:c0:ff:ee:2225:64ff:fe34:ce08/64 scope global dynamic mngtmpaddr noprefixroute
17
       valid_lft 2591809sec preferred_lft 604609sec
18
    inet6 2001:af:31:ff00:c0:ff:ee:1/64 scope global
19
       valid_lft forever preferred_lft forever
20
    inet6 2001:af:31:ff00::2/64 scope global
21
       valid_lft forever preferred_lft forever
22
    inet6 fe80::2225:64ff:fe34:ce08/64 scope link
23
       valid_lft forever preferred_lft forever

Thomas V. schrieb:
> Woher hast Du denn das Netz 2001:af:31::/48? Das ist derzeit keinem
> Provider zugewiesen.

Ich habe im Beitrag gewollt die IP ein bisschen verändert, weil ich 
nicht die öffentliche IP veröffentlichen möchte. In der Firewall steht 
die passende IP.

Thomas V. schrieb:
> Dein Internet-Provider (wenn er IPv6 anbietet) sollte Deinem
> Internetrouter  ein global gültiges Netz per IPv6-Prefix-Delegation
> zuweisen. Dein Internet-Router stellt dann aus diesem Netz die Adressen
> für die Clients im LAN per SLAAC zur Verfügung. Alternativ auch per
> DHCPv6. Je nach Konfiguration.

Der DHCPv6-Client bekommt nichts zugewiesen.

von (prx) A. K. (prx)


Lesenswert?

Bevor es mir unlängst das Ding beim Update gebrickt hatte, hatte ich 
kein Problem, einen Mikrotik hAP ac² ins Netz einer Fritzbox zu hängen. 
Fritz bekommt vom Provider einen /56 Prefix und vergab per DHCPv6 einen 
/62 an den Mikrotik. Der wiederum machte daraus ein /64 Sekundärnetz. 
Alles ziemlich automatisch.

: Bearbeitet durch User
von Thomas V. (tomv)


Lesenswert?

100Ω W. schrieb:
> Ich habe im Beitrag gewollt die IP ein bisschen verändert, weil ich
> nicht die öffentliche IP veröffentlichen möchte. In der Firewall steht
> die passende IP.

O.k.
Wollte nur sichergehen, dass Du keine Fantasieadressen verwendest.

> Der DHCPv6-Client bekommt nichts zugewiesen.

Dann vielleicht mit SLAAC versuchen?
Einfach mal einen Win10- oder Linux-Rechner in das Netz hinterm 
DSL-Router bringen und IPv6 auf diesem aktivieren. Wenigstens eine 
IP-Adresse sowie das default-Gateway sollte er bekommen.

Wenn das geht, kann man mit dem Mikrotik weitermachen. Der muss ja dann 
nur noch bridge spielen.

von Einer (Gast)


Lesenswert?

100Ω W. schrieb:
> Gegeben ist ein statisches /48-Netz (2001:af:31::/48). Das Gateway hat
> die (2001:af:31::1).
> Das WAN-Interface hat die 2001:af:31:ff00::1 und die Bridge die
> 2001:af:31:ff00:234:a34:34b:455/64

Na, und wie soll das funktionieren?

Dein Router hat (mindestens) zwei physikalische Netze. Einmal in 
Richtung Internet (WAN) und einmal in Dein LAN ("bridge"?!).

Beiden hast Du Adressen mit den gleichen Prefix 2001:af:31:ff00::/64 
zugeteilt. Woher soll der Router denn nun wissen, was er wohin schicken 
soll?

Gib dem LAN-Interface deines Routers einen anderen Prefix, z.B. 
2001:af:31:ff0*1*::/64 und sorge dafür, dass der Router per SLAAC den 
Prefix und sich selbst als Router annonciert.

von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

Einer schrieb:
> Gib dem LAN-Interface deines Routers einen anderen Prefix, z.B.
> 2001:af:31:ff0*1*::/64 und sorge dafür, dass der Router per SLAAC den
> Prefix und sich selbst als Router annonciert.

Okay, ich habe jetzt dem WAN-Interface die 2001:af:31:ff00::1 und der 
Bridge die 2001:af:31:ff01::1 gegeben. Gehen tut es jetzt immer noch 
nicht.

: Bearbeitet durch User
von Einer (Gast)


Lesenswert?

Ist SLAAC aktiviert? Wie ist die Routing-Tabelle? Poste die 
Konfiguration hier so, wie sie vom Router ausgegeben wird, ohne Deine 
eigene Interpretationen.

von Daniel A. (daniel-a)


Lesenswert?

Sowas muss man einfach aufzeichnen. Interpretiere ich dein Setup hier 
richtig?
1
                     ┌──────────────┐
2
                     │ [bridge if1] │ 
3
[internet gw if0] ┈┈┈│┈┈┈┈┈┈┈┈┈┈┈┈┈┈│┈┈┈[if2 (WAN)  router  (LAN) if3]┈┈┈[PCs] 
4
                     │ Transparent  |
5
                     └──────────────┘
6
7
if0: 2001:af:31::1/48
8
if1: 2001:af:31:ff00:234:a34:34b:455/64
9
if2: 2001:af:31:ff00::1/64
10
if3: 2001:af:31:ff00:????/64

Ich bin auch recht neu zu IPv6, und mein Setup ist anders (WAN seitig 
per DHCPv6 und ein mix aus prefix delegation, ULAs und NAT, je nach 
Subnetz & Anwendungsfall). Vielleicht sage ich also auch kompletten 
bullshit.

if2 (WAN) würde ich eigentlich ein /128 erwarten, das /48 Netz ist ja 
nicht dort drüben zu finden, sondern auf die anderen Router Interfaces 
verteilt.
Das 2001:af:31:ff00::/64 netz würde ich beim if3 (LAN) erwarten. Ich 
denke es müsste gehen, if3 die 2001:af:31:ff00::1/64 und if2 die 
2001:af:31:ff00::1/128 zu geben, aber ich bin mir nicht sicher, ich hab 
sowas noch nie ausprobiert.
Bei mir bekomme ich per DHCPv6 eine IP für if2 die in einem komplett 
anderem Netz liegt / nicht im Prefix das ich darüber kriege (also nicht 
mal 2001:af:31:ff00::/48), damit ist es bei mir mit der default route 
abgedeckt. Und diese (if2) bräuchte ich theoretisch eigentlich 
vermutlich auch gar nicht, die link locale Adresse sollte fürs routing 
auch ausreichen, du könntest die dort vermutlich auch nehmen, und das GW 
muss es dann halt dort hin routen. Falls du eine einzelne IP /128 auf 
if2 vergibst die im /64 von if3 ist, brauchen die lan clients eine route 
für die /128 über die IP von if3 als GW.
Die LAN clients sollten auch noch eine default route (::/0) zu if3 
haben.

Die IP von if1 (der bridge) sollte ja eigentlich keine grosse Rolle 
spielen. Der Router muss eine default route (::/0) zu if0 
(2001:af:31::1) haben, und if0 eine netz route für 2001:af:31::/48 zu 
if2 (2001:af:31:ff00::1) (oder alternativ zumindest für netz 
2001:af:31:ff00::/64, falls da noch mehr router sind). Die Bridge ist 
dabei transparent, eigentlich braucht sie gar keine (ausser man will sie 
irgendwie erreichen). Wenn sie eine hat, muss man eventuell dem GW und 
dem Router mit einer route sagen, wo sie ist. Wenn es wie hier mit dem 
subnet 2001:af:31:ff00::/64 überlappt, bräuchten die Clients eigentlich 
auch noch eine route (oder alternativ, der router ein proxy ARP, oder 
was auch immer das IPv6 äquivalent ist.). So oder so, erscheint mir 
extra ungünstig gewählt.

Es stellt sich auch die frage, woher weiss das GW, wo das Netz 
2001:af:31:ff00::/48 oder 2001:af:31:ff00::/64 liegt. Bei mir geht das 
vermutlich über die DHCPv6 prefix delegation, da wird es meinem router 
ja zugewiesen, aber bei dir ist es statisch. Eventuell per ICMP route 
advertisement vom router, so wie man das SLAAC und die routen auch lan 
seitig vergibt? Ich nehme an, dass es ohne die Route einfach bei if0 per 
ICMP fragen wird, wer hat IP so und so, und keiner antwortet, weil 
hinter dem Router.
Vermutlich liegt da dein Haupt Problem. Musst du halt mit tcpdump usw. 
analysieren, was da abgeht.

von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

Einer schrieb:
> Poste die
> Konfiguration hier so, wie sie vom Router ausgegeben wird, ohne Deine
> eigene Interpretationen.
1
/ipv6> export  
2
3
# oct/17/2021 15:24:39 by RouterOS 6.49
4
# software id = XXXX-XXXX
5
#
6
# model = RB941-2nD
7
# serial number = XXXXXXXXXXX
8
9
10
/ipv6 address
11
add address=2001:af:31:ff00::1/48 advertise=no interface=ether1_wan
12
add address=2001:af:31:ff01::1 interface=bridge
13
14
/ipv6 firewall address-list
15
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
16
add address=::1/128 comment="defconf: lo" list=bad_ipv6
17
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
18
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
19
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
20
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
21
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
22
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
23
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
24
add address=::224.0.0.0/100 comment="defconf: other" list=bad_ipv6
25
add address=::127.0.0.0/104 comment="defconf: other" list=bad_ipv6
26
add address=::/104 comment="defconf: other" list=bad_ipv6
27
add address=::255.0.0.0/104 comment="defconf: other" list=bad_ipv6
28
29
/ipv6 firewall filter
30
add action=accept chain=forward
31
add action=accept chain=forward comment="defconf: accept established,related,untracked" connection-state=established,related,untracked disabled=yes
32
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid disabled=yes
33
add action=drop chain=forward comment="defconf: drop bad forward IPs" disabled=yes src-address-list=no_forward_ipv6
34
add action=drop chain=forward comment="defconf: drop bad forward IPs" disabled=yes dst-address-list=no_forward_ipv6
35
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" disabled=yes hop-limit=equal:1 protocol=icmpv6
36
add action=accept chain=forward comment="defconf: accept ICMPv6 after RAW" disabled=yes protocol=icmpv6
37
add action=accept chain=forward comment="defconf: accept HIP" disabled=yes protocol=139
38
add action=accept chain=forward comment="defconf: accept IKE" disabled=yes dst-port=500,4500 protocol=udp
39
add action=accept chain=forward comment="defconf: accept AH" disabled=yes protocol=ipsec-ah
40
add action=accept chain=forward comment="defconf: accept ESP" disabled=yes protocol=ipsec-esp
41
add action=accept chain=forward comment="defconf: accept all that matches IPSec policy" disabled=yes ipsec-policy=in,ipsec
42
add action=drop chain=forward comment="defconf: drop everything else not coming from LAN" disabled=yes in-interface-list=!LAN
43
add action=accept chain=input disabled=yes
44
add action=accept chain=output disabled=yes
45
46
/ipv6 nd
47
set [ find default=yes ] advertise-dns=no advertise-mac-address=no
48
add interface=bridge ra-lifetime=none
49
50
/ipv6 route
51
add distance=1 gateway=2001:af:31::1
52
53
/ipv6 route> print  
54
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable 
55
 #      DST-ADDRESS              GATEWAY                  DISTANCE
56
 0 A S  ::/0                     2001:af:31::1                   1
57
 1 ADC  2001:af:31::/48          ether1_wan                      0
58
 2 ADC  2001:af:31:ff01::/64     bridge                          0

von Daniel A. (daniel-a)


Lesenswert?

Ich kenne mich mit RouterOS nicht wirklich aus.
Die bridge ist wohl etwas anderes, als ich dachte. Ist diese also LAN 
seitig / darin hängen all die clients?

Ich würde das zwar nicht so umsetzen, aber ich denke das sieht 
eigentlich gut aus, so wie es ist.

Es gibt 2 Sachen, die ich prüfen würde. Bekommen die Clients eine 
default route, (::/0) via 2001:af:31:ff01::1? (Kann man auf linux 
clients mit "ip -6 route" oder "route -6" anzeigen, wobei letzteres 
etwas mehr anzuzeigen scheint.)

Und dann stellt sich die Frage, hat das GW eine Route zum Router. Ich 
würde dafür mal auf dem Router die Packete auf ether1_wan aufzeichnen, 
und dann versuchen, vom Client versuchen etwas zu Pingen, oder auf etwas 
im Internet zuzugreifen. Von besonderem Interesse sind dabei die ICMP6 
Nachrichten, sowie die MACs der Pakete. Das ICMP6 ersetzt quasi arp bei 
IPv6. Wenn du in ether1_wan siehst, wie das GW fragt, "wer hat <client 
IP>", dann fehlt ihm die Route. Falls du aber Pakete siehst, wo die Ziel 
MAC die des Routers ist, und die Ziel IP die eines Clients, ist dort 
alles in ordnung. Falls du keins von beiden siehst, hängt es vermutlich 
schon irgendwo vorher, und die Pakete vom Client kommen vermutlich schon 
gar nicht zum GW.

: Bearbeitet durch User
von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

Daniel A. schrieb:
> Es gibt 2 Sachen, die ich prüfen würde. Bekommen die Clients eine
> default route, (::/0) via 2001:af:31:ff01::1? (Kann man auf linux
> clients mit "ip -6 route" oder "route -6" anzeigen, wobei letzteres
> etwas mehr anzuzeigen scheint.)
1
[user@netbook ~]$ ip -6 route
2
::1 dev lo proto kernel metric 256 pref medium
3
2001:af:31:ff01::/64 dev enp2s0 proto ra metric 100 expires 2591536sec pref medium
4
2001:af:31:ff01::/64 dev enp2s0 proto kernel metric 256 pref medium
5
2001:af:31:ff01::/64 dev enp2s0 proto ra metric 1002 pref medium
6
fd42:24:42::250 dev home proto kernel metric 256 pref medium
7
fe80::/64 dev br-5e227d112754 proto kernel metric 256 pref medium
8
fe80::/64 dev veth621ed6a proto kernel metric 256 pref medium
9
fe80::/64 dev veth8a5e09b proto kernel metric 256 pref medium
10
fe80::/64 dev enp2s0 proto kernel metric 256 pref medium
11
default via fe80::a55:31ff:fe37:a347 dev enp2s0 proto static metric 1024 pref medium
12
default dev enp2s0 proto static metric 1024 pref medium

von Daniel A. (daniel-a)


Lesenswert?

Ok, die fe80::a55:31ff:fe37:a347, ist das die link-locale Adresse der 
bridge? Das müsste auch gehen / das wäre auch richtig.

von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

Daniel A. schrieb:
> Ok, die fe80::a55:31ff:fe37:a347,

Ja.

Wenn die den PacketSniffer auf dem Router benutzte, sehe ich auch die 
Packete.

von Daniel A. (daniel-a)


Lesenswert?

Und wenn du dir spezifisch die Pakete ansiehst, die über ether1_wan 
gehen, was siehst du dort?

von 100Ω W. (tr0ll) Benutzerseite


Angehängte Dateien:

Lesenswert?

Daniel A. schrieb:
> Und wenn du dir spezifisch die Pakete ansiehst, die über ether1_wan
> gehen, was siehst du dort?

Siehe Screenshot.

von Daniel A. (daniel-a)


Lesenswert?

Ok, das Paket wird also gesendet. Kommt auch irgend etwas zurück auf 
ether1_wan? Ein Reply, oder eine andere ICMP Nachricht vom GW?

von Einer (Gast)


Lesenswert?

Ach Router-OS...

100Ω W. schrieb:
> /ipv6 address
> add address=2001:af:31:ff00::1/48 advertise=no interface=ether1_wan

Naja, könnte man so machen, ist aber richtig Kacke.

Der Link zum Provider ist Point-To-Point. Man kann ein /64 für den Link 
nehmen, oder ein /127. Ich mag /127.

D.h. für /127 wäre es:
1
add address=2001:af:31::/127 advertise=no interface=ether1_wan

Und falls Du ein (bzw. das schöne...) /64 für den Uplink verwenden 
willst:
1
add address=2001:af:31::2/64 advertise=no interface=ether1_wan


Nun zum LAN:

> add address=2001:af:31:ff01::1 interface=bridge

Wie oft wurde hier im Thread geschrieben, Du sollst SLAAC bzw. 
Advertising einschalten?

Gut, so wie die Schnittstelle konfiguriert ist, ist es natürlich maximal 
falsch...

Richtig wäre:
1
add address=2001:af:31:ff01::1/64 advertise=yes interface=bridge

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Einer schrieb:
> Wie oft wurde hier im Thread geschrieben, Du sollst SLAAC bzw.
> Advertising einschalten?

Offenbar bekommen seine Clients ja die korrekte Route 
(Beitrag "Re: Probleme beim einrichten von IPv6"), SLAAC scheint 
also zu funktionieren, und die Pakete werden vom Client korrekt an den 
Router und dann weiter ans GW gesendet 
(Beitrag "Re: Probleme beim einrichten von IPv6").

Ich vermute eher, dass dem GW eine route zurück um Router fehlt.

von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

🐧 DPA 🐧 schrieb:
> Ich vermute eher, dass dem GW eine route zurück um Router fehlt.

Ja, dann dürfte ich von dem Router aus auch nichts mehr anpingen können, 
oder habe ich da einen Denkfehler drinnen?

Einer schrieb:
> 100Ω W. schrieb:
>> /ipv6 address
>> add address=2001:af:31:ff00::1/48 advertise=no interface=ether1_wan
>
> Naja, könnte man so machen, ist aber richtig Kacke.
>
> Der Link zum Provider ist Point-To-Point. Man kann ein /64 für den Link
> nehmen, oder ein /127. Ich mag /127.

Wenn ich die /48 gegen eine /64 oder /127 austausche kan ich den Router 
von außen auch nicht mehr anpingen.

von Daniel A. (daniel-a)


Lesenswert?

100Ω W. schrieb:
> 🐧 DPA 🐧 schrieb:
>> Ich vermute eher, dass dem GW eine route zurück um Router fehlt.
>
> Ja, dann dürfte ich von dem Router aus auch nichts mehr anpingen können,
> oder habe ich da einen Denkfehler drinnen?

Das kommt drauf an. WAN seitig hat der Router ja auch die 
2001:af:31:ff01::1. Wenn also das GW eine Route für 2001:af:31::/48 auf 
das GW Interface hat, aber die Route nicht via 2001:af:31:ff01::1 läuft, 
dann sollte das GW zwar den Router finden, wenn man dieses anpingt (über 
ICMPv6 Neighbor Solicitation & ICMPv6 Neighbor Advertisement), aber wenn 
es etwas an die Clients im LAN senden wollte, würde es das auch 
versuchen, statt die Pakete an den Router weiterzuleiten, und die LAN 
Clients bekämen von all dem nichts mit.

Wie ich schon sagte, falls es das ist, bin ich mir nicht sicher, wie man 
dem GW die Route bei bringt. Vielleicht könnte es über ICMPv6 Router 
Advertisements gehen. Eins ohne Prefix, aber mit einer Route für 
2001:af:31::/48.

https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol

100Ω W. schrieb:
> Wenn ich die /48 gegen eine /64 oder /127 austausche kan ich den Router
> von außen auch nicht mehr anpingen.

Hier ist mir jetzt auch nicht klar, warum das passieren sollte.
Bei /64 würde ich ja noch verstehen, wenn man nicht von / zu den Clients 
käme (weil auf beide Seiten eine identische gleich grosse Route, womit 
der Router nicht wüste, auf welcher Seite sie sind (bei /48 gewinnt das 
kleinere /64 vom LAN, bei /127 oder gar /128 sollte ja praktisch nur die 
WAN addresse betroffen sein, und ohne müsste es immer noch über die 
link-local addresse gehen.)).
Aber warum das das Anpingen vom Router selbst beeinflussen sollte, keine 
Ahnung.
Was WAN Interface ist nicht teil der bridge, oder?

von Einer (Gast)


Lesenswert?

100Ω W. schrieb:
> Wenn ich die /48 gegen eine /64 oder /127 austausche kan ich den Router
> von außen auch nicht mehr anpingen.

Ich wette 5,- Euro, dass Du nur die Netzmaske und nicht die Adresse 
geändert hast.

Folgendes ist falsch:
1
add address=2001:af:31:ff00::1/127 advertise=no interface=ether1_wan

Und das ist richtig:
1
add address=2001:af:31::/127 advertise=no interface=ether1_wan

Und natürlich pingst Du dann "2001:af:31::" von außen an. Das ist ja 
Deine neue (richtige) Router-Adresse.

von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

Daniel A. schrieb:
> Was WAN Interface ist nicht teil der bridge, oder?

Das WAN-Interface ist nicht teil der Bridge.

von Daniel A. (daniel-a)


Lesenswert?

Einer schrieb:
> Folgendes ist falsch:
> add address=2001:af:31:ff00::1/127 advertise=no interface=ether1_wan
>
> Und das ist richtig:
> add address=2001:af:31::/127 advertise=no interface=ether1_wan

Ersteres ist zwar unüblich, aber ich sehe trotzdem nicht, warum es nicht 
funktionieren sollte. Anders als bei 2001:af:31::/127 und 
2001:af:31:ff00::1/48 ist das GW zwar nicht in dem Subnet, aber es 
müsste ja immer noch die default Route ::/0 zum GW geben, über die der 
Router das GW erreichen können müsste.
Und die IP auf dem WAN interface verschwindet ja auch nicht, nur weil es 
beim LAN Interface eine überlappende Route gibt.

von Einer (Gast)


Lesenswert?

Daniel A. schrieb:
> Anders als bei 2001:af:31::/127 und
> 2001:af:31:ff00::1/48 ist das GW zwar nicht in dem Subnet, aber es
> müsste ja immer noch die default Route ::/0 zum GW geben, über die der
> Router das GW erreichen können müsste.

Nein.

Eine Route "zeigt" nur auf eine IP-Adresse, nämlich das Gateway. Also 
eine Route ordnet einem prefix/länge eine Ziel-Adresse zu.

Nun muss aber der Router noch wissen, wie er das Gateway erreichen kann. 
Und das kann er nur über die Schnittstellen-Adresse inkl. ihrem Prefix.

 - Gateway beim Provider sei 2001:af:31::1
 - Das WAN-Interface hat 2001:af:31:ff00/127
 - Es gibt eine Default-Route ::/0 auf 2001:af:31::1

Aber: Wo, auf welchem Interface ist das Gateway zu finden? Das WAN kann 
es ja nicht sein, denn das geht nur von 2001:af:31:ff00::0 bis 
2001:af:31:ff00::1. Dort ist die 2001:af:31::1 offensichtlich nicht 
dabei. Also geht es so nicht.


(Bezüglich WAN-Adresse 2001:af:31:ff00::1/48):

> Ersteres ist zwar unüblich,

Das funktioniert ja soweit, dass er den Router pingen kann.

Aber:

Ihm (bzw. dem Router) gehört ja das komplette Netz 2001:af:31::/48. Und 
wenn er jetzt ein Paket z.B. für 2001:af:31:1234::/64 hat, aber keine 
Interface mit dieser Adresse, dann schickt sein Router das eigene Paket 
an den Router des Providers. Und dieser Router ist hoffentlich korrekt 
konfiguriert, dass er dieses Paket verwirft und nicht wieder zurück 
schickt, und das solange hin und her geht bis TTL abgelaufen ist...

Darum ist /127 für Provider-Uplinks sinnvoll. Kein unerwartetes 
Ping-Pong und kein Angriffsvektor um Daten abzugreifen.

von Daniel A. (daniel-a)


Lesenswert?

Einer schrieb:
> Aber: Wo, auf welchem Interface ist das Gateway zu finden? Das WAN kann
> es ja nicht sein, denn das geht nur von 2001:af:31:ff00::0 bis
> 2001:af:31:ff00::1. Dort ist die 2001:af:31::1 offensichtlich nicht
> dabei. Also geht es so nicht.

Bei meinem linux PC ist bei "ip -6 route" das Interface bei der default 
route auch noch mit dabei, damit weiss er dann, wo es ist.
Aber OK, das sind wohl eigentlich 2 Routen, in dem Scenario einmal 
"2001:af:31:ff00::1/128 -> ether_wan" und einmal "::/0 -> 
2001:af:31:ff00::1".
Die erste Route fehlte, und deshalb ging es nicht.
Statt dem 2001:af:31::1 könnte man vermutlich auch die link locale 
Adresse des GW nehmen (sofern es eine hat), bei denen gehört das 
Interface ja zwingend dazu.

von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

Daniel A. schrieb:
> Statt dem 2001:af:31::1 könnte man vermutlich auch die link locale
> Adresse des GW nehmen (sofern es eine hat), bei denen gehört das
> Interface ja zwingend dazu.

Ja, aber die habe ich nicht.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ich blicke gerade nicht durch die Menge an Beiträgen, IP-Adressen etc. 
durch.

Nur mal zur Sicherheit: deine Gegenseite routet aber korrekt, ja? D.h. 
sie routet das gesamte /48 zu einer einzelnen IP-Adresse aus einem /64er 
(Sub-)Netz?

Wir hatten das mal mit der Telekom vor einiger Zeit, an einem 
Business-Anschluss. Die liefern ja bei IPv4 ein /29, welches sie aber 
mehr oder weniger als direkt angeschlossenes (also per ARP auflösbares) 
Netz betrachten, sodass man nicht noch irgendwelche Gateway-Netze etc. 
davon abziehen muss, sondern alle 8 Adressen nutzen kann. Nun haben sie 
das dummerweise standardmäßig mit IPv6 genauso gemacht, alle /48 wurden 
also als lokal anliegend betrachtet und hätten am WAN per NDP aufgelöst 
werden müssen. Zwar kann man auch sowas wie ein Proxy-NDP aufsetzen, 
aber das ist natürlich völlig daneben, denn man will ja schließlich eine 
(variable) Anzahl an /64-Netzen hinter dem Gateway/Firewall routen.

Die Lösung hier war, mit der Telekom zu verhandeln, dass sie das Setup 
von "/48 direkt anliegend" auf "/64 direkt anliegend" (mit zwei 
bekannten Adressen auf beiden Seiten) und "/48 darüber geroutet" 
geändert haben. Danach ging alles wie erwartet.

von Robin (Gast)


Lesenswert?

Wie wunderbar dokumentiert warum sich IPV6 nur so zögerlich durchsetzt. 
Die konfigurationsreiche Featuritis die diesen Standard begleitet kann 
man doch nur als Pfusch bezeichnen. Hatte seinerzeit mal eine ganze 
Woche lang versucht, meine Geräte so von außen erreichbar zu machen- und 
bin schließlich doch wieder zu V4 zurückgekehrt...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Robin schrieb:
> Die konfigurationsreiche Featuritis die diesen Standard begleitet kann
> man doch nur als Pfusch bezeichnen.

Selten so einen Quatsch gelesen, sorry.

Wenn (wie im Falle der Telekom) ein ISP per default mit einem 
Sch***-Setup daher kommt (nur, weil sie es bei IPv4 genauso gemacht 
haben), dann ist wer daran Schuld? IPv6?

> Hatte seinerzeit mal eine ganze Woche lang versucht, meine Geräte so von
> außen erreichbar zu machen

Ich habe es eine Stunde lang versucht – seitdem sind sie erreichbar.

von Robin (Gast)


Lesenswert?

Jörg W. schrieb:
> Quatsch

ist das nicht. Sondern ausgesprochen ärgerlich wenn es ohne 
Netzwerkstudium nicht (mehr) geht.

von (prx) A. K. (prx)


Lesenswert?

IPv6 ist kein IP mit mehr Adressbits, sondern geht auch ein paar andere 
Schwächen von IPv4 an. Man kann also nicht alles Wissen aus IPv4 direkt 
weiternutzen. So ist die Branche eben. Ab und zu gibt's Neues, und man 
hat die Wahl zwischen lernen und meckern.

: Bearbeitet durch User
von Daniel A. (daniel-a)


Lesenswert?

Bei mir war das dynamische Präfix etwas lästig (statisch macht mein ISP 
nicht, hab angerufen). Da muss ich alle Einträge auf meinem DNS Server 
dynamisch updaten bei änderungen. (Und für glue records beim Registrar 
kann ich das nicht machen, deshalb sind diese (und nur diese) immer noch 
nur IPv4).

Aber ansonsten gieng alles recht problemlos. Den LAN Clients hab ich ein 
globales prefix weitergegeben. Die Server habe ich analog zum IPv4 Netz 
statisch per ULA konfiguriert, (sind bei mir fc00:4::10.60.N.X/120, 
analog zu den IPv4 10.60.N.X/24), und per NAT in einem Script auf ein 
globales prefix gemappt. Die Protokolle für ARP und DHCP sind zwar 
andere, und ich kann im (W)LAN nicht explizit die addressen vergeben 
(manche Geräte bestehen auf SLAAC), aber DNS, Routen, die meisten 
Firewall regeln, etc. kann ich alles exakt analog aufbauen. Mein eigener 
MITM Proxy brauchte auch noch ein paar Anpassungen (das Ding hat jetzt 
ein eigenes WLAN, weil ich bei meinem iPad das IPv6 Gateway nicht 
manuell setzen kann), aber das war managebar.

Ein paar neue Dinge hab ich auch noch gelernt, wie z.B. wie z.B. die 
diversen ICMPv6 Nachrichten, dass in IPv6 eingebettete IPv4 Adressen von 
vielen Tools nicht richtig behandelt werden, oder auch dass Server ohne 
link-local adresse auskommen, aber router diese zwingend für die router 
advertisements brauchen.

Das lästigste war definitiv herauszufinden, wie man all die 
automagischen autokonfigurationen ausschaltet, dort, wo ich sie nicht 
haben will und nicht brauche. Das, und SLAAC. Dass ich die IPs im LAN 
nicht explizit vergeben kann, gefällt mir gar nicht.

Gelohnt hat es sich nicht wirklich. Meine WebRTC Konnektivität ist nun 
etwas besser, und theoretisch könnte ich jetzt direkt per SSH auf alle 
meine Server / Container zugreifen (frog-dmz.dpa.li, spider-dmz.dpa.li, 
etc.), wenn ich an einen Ort käme, wo es auch IPv6 gibt, aber in der 
Praxis sind das nur Spielereien, die mir nicht wirklich was gebracht 
haben. Die Smartphones / deren Provider, z.B., hier, scheinen kein IPv6 
zu haben...

von (prx) A. K. (prx)



Lesenswert?

Daniel A. schrieb:
> Die Smartphones / deren Provider, z.B., hier, scheinen kein IPv6 zu
> haben...

In D haben mindestens Telekom und O2 auch IPv6. Kann aber gut sein, dass 
man das in den Einstellungen vom APN eigens aktivieren muss.

: Bearbeitet durch User
von Daniel A. (daniel-a)


Lesenswert?

Ich habe hier Sunrise, mein Vater hat beim Arbeitstelefon Swisscom. (CH)

Edit: Danke für die Screenshots, dort musste ich es tatsächlich noch 
einschalten. Jetzt gehts.
Edit edit: Zu früh gefreut. Die IPv6 test Seite geht trotzdem nicht...

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Robin schrieb:
> Sondern ausgesprochen ärgerlich wenn es ohne Netzwerkstudium nicht
> (mehr) geht.

Auch für das Einrichten von IPv4 musste man irgendwie schon ein wenig 
Ahnung haben vom zugrunde liegenden Netzwerkprotokoll. Das ist bei IPv6 
nicht anders.

Daniel A. schrieb:
> Gelohnt hat es sich nicht wirklich.

Lohnen tut es sich vor allem dann, wenn man vielleicht noch hie und da 
VPNs aufbauen möchte. Da kann es bei diesem RFC1918-Krimskrams nämlich 
ganz schnell mal passieren, dass jemand anderes dann doch irgendwo schon 
die gleichen Adressen verwendet, zu dem man eigentlich eine Verbindung 
gern hin bekommen möchte.

Auch ansonsten ist der Wegfall von NAT ein Segen. Hätte halt nur schon 
20 Jahre früher durchgezogen werden sollen, statt überhaupt erst RFC1918 
einzuführen. Da wären vielen Netzwerkern mächtig graue Haare erspart 
geblieben.

> Bei mir war das dynamische Präfix etwas lästig

Kann ich mir gut vorstellen. Ist auch völlig unverständlich, wofür die 
Provider das immer noch machen – natürlich abgesehen davon, dass 
irgendein Marketingfritze meint, dass alles andere halt "business" sein 
müsse, dem man entsprechend mehr Geld abknöpfen kann.

von 100Ω W. (tr0ll) Benutzerseite


Lesenswert?

Der Anschluss ist von der Telekom.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

100Ω W. schrieb:
> Der Anschluss ist von der Telekom.

Dann red mit denen. Hat bei uns geholfen. ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.