Gibt's hier ipv6 Spezialisten? Routing Problem inside...

R

Rosendoktor

Well-Known Member
Hallo,

ich habe seit langem ipv6 in meinem recht heterogenen Netz am Laufen. Bis auf ein paar kleinere Problemchen funktioniert es soweit prima. Eines dieser Problemchen wollte ich kürzlich mal angehen, und bin dabei auf ein für mich äusserst seltsames Verhalten des Netzwerks gestossen.

Ich dachte mir ich frag' jetzt einfach mal hier, da ja auch FreeBSD Clients beteiligt sind und ich ausserdem in keinem Linux Forum angemeldet bin und es sich meiner Meinung nach sowieso eher im ein generelles ipv6 "Feature" handelt.

Ich habe mal herausdestilliert worum es geht und was da seltsam ist. Also, zentraler Router im Netz ist ein Linux Debian 8 System, das als DSL, LAN und WLAN Router agiert. Es gibt mehrere WLAN Netze mit unterschiedlichen SSIDs und Konfigurationen. Das LAN und die WLANs haben alle unterschiedliche Subnetze mit einem vom Provider gelieferten ::/48 Präfix. Im WLAN hängen Clients aller Art (Win, Linux, OSX, FreeBSD, Android, IOS)

Sieht so aus:

Code: 
 DSL (ppp)
 88.123.123.123
 2001:470:abc:def:1
    |
Router---LAN-------------------------------------Server LAN
    |    192.168.0.251                           192.168.0.252
    |    2001:470:abc:def::<int-id-router-LAN>   2001:470:abc:def::<int-id-server-LAN>
    |    fd10:aaa:bbb:ccc::<int-id-router-LAN>   fd10:aaa:bbb:ccc::<int-id-server-LAN>
 WLAN
 192.168.1.251
 2001:470:abc:123::<int-id-router-WLAN>
 fd10:aaa:bbb:123::<int-id-router-WLAN>
    |
    |
    |
 Notebook WLAN
 192.168.1.40
 2001:470:abc:123::<int-id-notebook-WLAN>
 fd10:aaa:bbb:123::<int-id-notebook-WLAN>


Die ipv4 Adressen werden per DHCP verteilt und per DDNS im Nameserver eingetragen. Die globalen ipv6 Adressen werden per RA verteilt. Die lokalen ipv6 Adressen fd::/8 werden per DHCPv6 verteilt und per DDNS im Nameserver eingetragen.

Ich hoffe es ist einigermassen klar wie das Netz aufgebaut ist.

Das komische passiert, wenn ich vom Notebook auf den Server zugreife. Und zwar das:

ipv4
Code: 
rsenger@angetenar:~$ ping 192.168.0.252
PING 192.168.0.252 (192.168.0.252): 56 data bytes
64 bytes from 192.168.0.252: icmp_seq=0 ttl=63 time=1.096 ms
64 bytes from 192.168.0.252: icmp_seq=1 ttl=63 time=1.038 ms
64 bytes from 192.168.0.252: icmp_seq=2 ttl=63 time=1.387 ms
^C

root@pherkad:~# tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:13:38.261970 IP 192.168.1.40 > 192.168.0.252: ICMP echo request, id 13363, seq 0, length 64
23:13:38.262059 IP 192.168.0.252 > 192.168.1.40: ICMP echo reply, id 13363, seq 0, length 64
23:13:39.265284 IP 192.168.1.40 > 192.168.0.252: ICMP echo request, id 13363, seq 1, length 64
23:13:39.265352 IP 192.168.0.252 > 192.168.1.40: ICMP echo reply, id 13363, seq 1, length 64
23:13:40.267127 IP 192.168.1.40 > 192.168.0.252: ICMP echo request, id 13363, seq 2, length 64
23:13:40.267214 IP 192.168.0.252 > 192.168.1.40: ICMP echo reply, id 13363, seq 2, length 64
Alles wie es sein soll.

ipv6 global
Code: 
rsenger@angetenar:~$ ping6 2001:abc:def:101:20d:b9ff:fe0d:c9c0
PING6(56=40+8+8 bytes) 2001:470:abc:123:91d8:3d01:439a:71a5 --> 2001:470:abc:def:20d:b9ff:fe0d:c9c0
16 bytes from 2001:470:abc:def:20d:b9ff:fe0d:c9c0, icmp_seq=0 hlim=63 time=1.222 ms
16 bytes from 2001:470:abc:def:20d:b9ff:fe0d:c9c0, icmp_seq=1 hlim=63 time=1.158 ms
16 bytes from 2001:470:abc:def:20d:b9ff:fe0d:c9c0, icmp_seq=2 hlim=63 time=1.136 ms
^C

root@pherkad:~# tcpdump -n -i eth0 icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:19:19.115387 IP6 2001:470:abc:123:91d8:3d01:439a:71a5 > 2001:470:abc:def:20d:b9ff:fe0d:c9c0: ICMP6, echo request, seq 0, length 16
23:19:19.115479 IP6 2001:470:abc:def:20d:b9ff:fe0d:c9c0 > 2001:470:abc:123:91d8:3d01:439a:71a5: ICMP6, echo reply, seq 0, length 16
23:19:20.117024 IP6 2001:470:abc:123:91d8:3d01:439a:71a5 > 2001:470:abc:def:20d:b9ff:fe0d:c9c0: ICMP6, echo request, seq 1, length 16
23:19:20.117093 IP6 2001:470:abc:def:20d:b9ff:fe0d:c9c0 > 2001:470:abc:123:91d8:3d01:439a:71a5: ICMP6, echo reply, seq 1, length 16
23:19:21.134059 IP6 2001:470:abc:123:91d8:3d01:439a:71a5 > 2001:470:abc:def:20d:b9ff:fe0d:c9c0: ICMP6, echo request, seq 2, length 16
23:19:21.134133 IP6 2001:470:abc:def:20d:b9ff:fe0d:c9c0 > 2001:470:abc:123:91d8:3d01:439a:71a5: ICMP6, echo reply, seq 2, length 16
^C
Auch alles wie es sein soll.


Aber dann, ipv6, lokal
Code: 
rsenger@angetenar:~$ ping6 fd10:aaa:bbb:ccc:20d:b9ff:fe0d:c9c0
PING6(56=40+8+8 bytes) fd10:aaa:bbb:123:5d32:abf3:7de2:5ec --> fd10:aaa:bbb:ccc:20d:b9ff:fe0d:c9c0
16 bytes from fd10:aaa:bbb:ccc:20d:b9ff:fe0d:c9c0, icmp_seq=0 hlim=63 time=1.424 ms
16 bytes from fd10:aaa:bbb:ccc:20d:b9ff:fe0d:c9c0, icmp_seq=1 hlim=63 time=1.170 ms
16 bytes from fd10:aaa:bbb:ccc:20d:b9ff:fe0d:c9c0, icmp_seq=2 hlim=63 time=1.143 ms
^C

root@pherkad:~# tcpdump -n -i eth0 icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:26:11.468390 IP6 fd10:aaa:bbb:ccc:20d:b9ff:fe0d:84b0 > fd10:aaa:bbb:ccc:20d:b9ff:fe0d:c9c0: ICMP6, echo request, seq 0, length 16
23:26:11.468493 IP6 fd10:aaa:bbb:ccc:20d:b9ff:fe0d:c9c0 > fd10:aaa:bbb:ccc:20d:b9ff:fe0d:84b0: ICMP6, echo reply, seq 0, length 16
23:26:12.472722 IP6 fd10:aaa:bbb:ccc:20d:b9ff:fe0d:84b0 > fd10:aaa:bbb:ccc:20d:b9ff:fe0d:c9c0: ICMP6, echo request, seq 1, length 16
23:26:12.472808 IP6 fd10:aaa:bbb:ccc:20d:b9ff:fe0d:c9c0 > fd10:aaa:bbb:ccc:20d:b9ff:fe0d:84b0: ICMP6, echo reply, seq 1, length 16
23:26:13.482244 IP6 fd10:aaa:bbb:ccc:20d:b9ff:fe0d:84b0 > fd10:aaa:bbb:ccc:20d:b9ff:fe0d:c9c0: ICMP6, echo request, seq 2, length 16
23:26:13.482310 IP6 fd10:aaa:bbb:ccc:20d:b9ff:fe0d:c9c0 > fd10:aaa:bbb:ccc:20d:b9ff:fe0d:84b0: ICMP6, echo reply, seq 2, length 16
^C
Am Notebook scheint hier auch alles wie es soll. Im TCPDUMP auf dem Server aber sieht's hier ganz anders aus: Die fd10:aaa:bbb:ccc:20d:b9ff:fe0d:84b0 ist die Adresse der Routers, nicht die des Notebooks. Das ist anders als ich es von ipv4 und von ipv6 mit globalen Adressen gewohnt bin.

Die Pings mit ipv6 lokalen Adressen gehen also zwischen Router und Server hin und her, anstatt zwischen Notebook und Server wie mit ipv4 und ipv6 globalen Adressen. Der Router scheint hier nicht einfach zwischen den Subnetzen hin und her zu routen wie gewohnt, sondern agiert hier irgendwie als eine Art "Proxy".

???

Was passiert hier? Ich habe schon alle Interfacekonfigurationen und Routingtabellen geprüft, auf allen drei beteiligten Maschinen sind die vollkommen identisch für die globalen und lokalen ipv6 Adressen.

Warum werden die fd::/8 Adressen anders behandelt/geroutet als die globalen 2001:usw... Adressen?

Ist das Absicht, also prinzipbedingt? Oder habe ich doch irgendeinen Knoten im Netz?

Der Punkt ist dass nicht nur icmp6 betroffen ist, sondern alle Verbindungen, auch ein SSH Login von Notebook zum Server scheint für den Server vom Router zu kommen statt vom Notebook. Das kann (und tut's auch) problematisch sein.

Danke für Hilfe und/oder Aufklärung, Falls noch ifconfig Ausgaben und Routingtabellen der Rechner nötig sein sollten liefere ich die gerne, wollte Euch nur nicht gleich damit zuschmeissen da es wie gesagt vielleicht eine einfache Erklärung dafür geben könnte.

Gruss, Robert
 
Von deiner ULA Adresse aus macht der Router NAT ins "Internet". Dass das Internet an dieser Stelle ein Netz bei dir ist, spielt keine Rolle. Verhält sich genau so wie IPv4 mit privaten Adressen.
 
Danke erst mal, jetzt wird's klarer.

derOliver schrieb:
Von deiner ULA Adresse aus macht der Router NAT ins "Internet".
Zum Vergrößern anklicken....

Ja, das ist soweit klar und funktioniert auch, wenn ein Gerät nur eine ULA hat.

derOliver schrieb:
Dass das Internet an dieser Stelle ein Netz bei dir ist, spielt keine Rolle. Verhält sich genau so wie IPv4 mit privaten Adressen.
Zum Vergrößern anklicken....

Hm, ja, aber... Zwischen den 192.168.0.0/24 und 192.168.1.0/24 Netzen wird ganz normal geroutet. Warum nicht auch zwischen den fd10:aaa:bbb.ccc::/64 und fd10:aaa:bbb:123::/64 Netzen? So hätte ich das jetzt ganz naiv mal erwartet.

Er macht also NAT zwischen den Subnetzen. Okay, das erklärt das ganze Verhalten natürlich. Ist halt nur doof wenn man z.B. auf dem Server ein bestimmtes fd::/8 Gastnetz per Firewall aussperren will, geht so nicht.

Über Sinn und Unsinn der ULAs kann man ja nun streiten, ich hab' sie deswegen eingeführt, weil per SLAAC konfigurierte Clients auch für Verbindungen zwischen internen Subnetzen die per Privacy Extensions generierte Adresse als Quelladresse verwenden, was zur Folge hat dass z.B. SSH Verbindungen (z.B. Notebook zu Server) durch das regelmässige Erneuern ebendieser Adresse nicht dauerhaft stabil sind. Dachte ULAs wären da eine gute Lösung...
 
ich kann dir jetzt auch nicht direkt sagen, wie du das lösen kannst. Kommst wahrscheinlich auch darauf an, wie der Router konfiguriert ist.

Für dein Anliegen ist SLAAC auch die falsche Methode, da würde ich schon DHCPv6 machen. Auch sollten sich die Clients genauso verhalten, egal ob du eine ULA nimmst oder nicht. Das müsste ich aber nachlesen. Die Privacy Extensions sind IMHO eh Blödsinn, weil Browser fingerprinting mittlerweile einfach viel zu gut ist.
 
derOliver schrieb:
Die Privacy Extensions sind IMHO eh Blödsinn, weil Browser fingerprinting mittlerweile einfach viel zu gut ist.
Zum Vergrößern anklicken....

Weil es irgendeinen Quatsch auf Schicht 7 in einem Protokoll gibt, soll man jedem freiwillig auf Schicht 3 eine wahrscheinlich ewig eindeutige 128bit-ID präsentieren? Denkst du eigtl. vorher nach?
 
derOliver schrieb:
Für dein Anliegen ist SLAAC auch die falsche Methode, da würde ich schon DHCPv6 machen.
Zum Vergrößern anklicken....

In dem ganzen Zoo an Clients der hier herumschwirrt sind manche dabei, die DHCPv6 (noch nicht | nicht mehr) können. Namentlich Android :grumble:, Windows 10 nach dem tollen Anniversary Update :mad:, und OS X Snow Leopard (okay, alt, entschuldigt). Ohne SLAAC können die leider gar kein ipv6...
 
hi

ich könnte mir vorstelle ndas das ein tcp/ip ipv6 stack problem ist.
ein ping via den public 2001:: netz funktioniert ja .

das thema fdxx netz und das zwingen 6to6 nat ist gross .
siehe auch
https://tools.ietf.org/html/rfc4193

ggf. mal testen ohne die öffentlichen addressen.

holger
 
KobRheTilla schrieb:
Es gibt neben WWW auch noch andere Anwendungszwecke für IPv6.
Zum Vergrößern anklicken....
Sind wir mal ehrlich: der weitaus meiste "interessante" Datenverkehr läuft heute über einen Browser. Wenn du etwas über jemandes herausbekommen willst, dann darüber. IP Adressen brauchst du dazu nicht anzuschauen.

TCM schrieb:
Weil es irgendeinen Quatsch auf Schicht 7 in einem Protokoll gibt, soll man jedem freiwillig auf Schicht 3 eine wahrscheinlich ewig eindeutige 128bit-ID präsentieren?
Zum Vergrößern anklicken....
Ich hätte das vielleicht anders formulieren sollen. Privacy Extensions bringen etwas, wenn man dynamisches Präfix hat. Wenn das Präfix statisch ist, bist du trotz Privacy Extension zu tracken. Gut vielleicht kann man dich nicht von deiner Familie unterscheiden, aber das wars auch schon. Und das ist rauschen, dass die Tracking Algorithmen eh miteinbeziehen, weil ja heute immer noch häufig ein Rechner von mehreren Personen genutzt wird.

Ich habe es so verstanden, dass das /48 statisch ist. Wenn es dynamisch ist, mea culpa.

TCM schrieb:
Denkst du eigtl. vorher nach?
Zum Vergrößern anklicken....
Ja. Und deshalb kann ich solche Unterstellungen gar nicht leiden.

Können wir dann wieder dem @Rosendoktor helfen oder geht's euch nur darum, wegen einer Randbemerkung hier stunk zu machen?

Rosendoktor schrieb:
In dem ganzen Zoo an Clients der hier herumschwirrt sind manche dabei, die DHCPv6 (noch nicht | nicht mehr) können. Namentlich Android :grumble:, Windows 10 nach dem tollen Anniversary Update :mad:, und OS X Snow Leopard (okay, alt, entschuldigt). Ohne SLAAC können die leider gar kein ipv6...
Zum Vergrößern anklicken....
Okay. Also zumindest ein aktuelles macOS holt sich mehrere IPv6 Adressen. Eine, die gleich bleibt, damit man den Rechner "finden" kann und mehrere, die für ausgehenden Verkehr genutzt werden. Möglicherweise passiert das mit einem ULA Präfix nicht, aber du könntest dies ggf. durch öffentliche Präfixe ersetzen und entsprechende Paketfilterregeln auf dem Router bauen um das Netz "dicht" zu bekommen. Wenn du am Server nicht einzelne Hosts, sondern nur Netze aussperren willst, könnte dir das helfen.
 
derOliver schrieb:
Ich hätte das vielleicht anders formulieren sollen. Privacy Extensions bringen etwas, wenn man dynamisches Präfix hat. Wenn das Präfix statisch ist, bist du trotz Privacy Extension zu tracken. Gut vielleicht kann man dich nicht von deiner Familie unterscheiden, aber das wars auch schon. Und das ist rauschen, dass die Tracking Algorithmen eh miteinbeziehen, weil ja heute immer noch häufig ein Rechner von mehreren Personen genutzt wird.
Zum Vergrößern anklicken....

Mein Verständnis der Privacy Extensions bezieht sich vor allem auf mobile Geräte. Denn ohne PE ist so ein Gerät immer und überall über die Interface ID identifizierbar, egal ob Zuhause, im ICE, im Hotel, beim AG, beim Kunden, im Café oder wo auch immer. Die PEs machen eben dies unmöglich.

Ich hab' den Fehler übrigens jetzt gefunden, es lag an den Maskierungsregeln in der Firewall.

ipv4
Code: 
iptables -t nat -A POSTROUTING -o ppp+ -j MASQUERADE

Hier wird nur maskiert wenn Pakete über ppp+ Interfaces nach draussen gehen.

ipv6
Code: 
ip6tables -t nat -A POSTROUTING -s fc00::/7 -j MASQUERADE

Hier wird nun aber immer maskiert. Mit Beschränkung auf Pakete die nach draussen gehen, z.b. so...

Code: 
ip6tables -t nat -A POSTROUTING -s fc00::/7 -d 2000::/3 -j MASQUERADE

...funktionieren die ULAs intern nun so wie ich es erwartet habe. Ohne NAT bzw. Maskierung.

Danke nochmal, der Hinweis auf NAT hat mich auf die richtige Spur gebracht!

Gruss,

Robert
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben