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:
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
Alles wie es sein soll.
ipv6 global
Auch alles wie es sein soll.
Aber dann, ipv6, lokal
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
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
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
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
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