Kategorie: Netzwerke & Protokolle (Seite 4 von 5)

Nur damit ich es bei der nächsten Anfrage zu diesem Thema schön verlinken kann, denn es scheint ein Standardproblem zu sein….

Wenn jemandem also auffällt dass in seinem Kernel oder Syslog Meldungen aufschlagen wie:

Oct 24 16:34:12 hostname kernel: [786717.368688] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:35:30 hostname kernel: [786795.230542] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:36:11 hostname kernel: [786836.309684] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:36:45 hostname kernel: [786870.407123] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:36:45 hostname kernel: [786870.628257] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:39:09 hostname kernel: [787014.210067] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:40:15 hostname kernel: [787080.322571] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:41:41 hostname kernel: [787166.667404] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:30 hostname kernel: [787275.473179] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:32 hostname kernel: [787277.498606] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:32 hostname kernel: [787277.498613] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:32 hostname kernel: [787277.584353] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:39 hostname kernel: [787284.396245] rt6_redirect: source isn't a valid nexthop for redirect target

Dann hast du das RFC nicht gelesen! Für das normale Next Hop Routing ist bei IPv6 IMMER die link-local Adresse des Routers zu benutzen und NICHT die Global Unicast IP.

Kontrolle Kontrolle….. Ganz einfach wenn euch folgender Befehl etwas anderes als die fe80 Adresse eures lokalen Router auswirft, dann ist es in 99% der Fällt falsch:

$ ip -6 route show default
default via fe80::20c:42ff:fe72:2ba6 dev eth0 proto static metric 1

Kennt man die Adresse des Routers nicht, hat man die Möglichkeit sie recht einfach zu erfragen, denn Router antworten auf einen ping einer bestimmten Adresse. Möchte ich als wissen, welcher Router hinter meinem eth0 steht:

$ ping6 -c 5 ff02::2%eth0
PING ff02::2%eth0(ff02::2) 56 data bytes
64 bytes from fe80::1: icmp_seq=1 ttl=64 time=40.8 ms
64 bytes from fe80::1: icmp_seq=2 ttl=64 time=24.1 ms
64 bytes from fe80::1: icmp_seq=3 ttl=64 time=0.602 ms
64 bytes from fe80::1: icmp_seq=4 ttl=64 time=0.542 ms
64 bytes from fe80::1: icmp_seq=5 ttl=64 time=0.578 ms

--- ff02::2%eth0 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.542/13.344/40.848/16.508 ms

Um das eigentliche Problem besser zu verstehen hilft es den Redirect Punkt besser zu verstehen. Zuerst ICMP Redirect gab es auch bereits bei IPv4… Es ist nichts weiter als eine GAAANZZ alte Version eines Routing „Protokolls“. Über diesen Weg teilt einem der Router eine „bessere“ Route zu einem Ziel mit. Bei einem Router ist es verständlicherweise witzlos bei mehreren „kann“ es helfen. Ich denke aber sauber konfiguriert wäre besser. Wie kommt es nun zu diesem Logeintrag? Ganz einfach…. Ist die IPv6 default Route zum Next Hop nicht, wie vorgeschrieben, die fe80 Adresse des Routers (bei nicht Next Hop Routing natürlich nicht) erreicht der Client den Router und somit die gerouteten Netze (Internet)… Vorausgesetzt der Client hat bereits eine Adresse, welche es ihm ermöglicht den Router überhaupt zu erreichen. Eine fest eingestellt öffentliche IPv6 Adresse zum Beispiel (wenn man hier weiter denkt wird einem schnell klar, dass es schon falsch sein muss nicht die fe80 zu nehmen). ABER wenn der Client nun so seinen Weg über den Router nimmt und dieser dann versucht einem eine „bessere“ Router per ICMP Redirect zu übermitteln, wird der Router hier nicht die fe80 eintragen, sondern die Angesprochene öffentliche. Dieses ist falsch, wird vom Client erkannt und ins Logfile geschrieben!

Nun lassen sich diese Logmeldungen natürlich abschalten, wenn man seinem Client mitteilt, dass er bitte alle ICMPv6 Redirect Messages ignorieren soll, korrekt konfiguriert ist das eigenen Next Hop Routing damit leider noch immer nicht 😀 OK ok… Angreifen könnten natürlich versuchen die ICMP Redirect Messages zu nutzen um einen Angriff zu fahren, denn jeder kann diese Meldungen senden. Damit dieser greift müsste dieser Angreifer im gleichen fe80 (denn nur diese würden vom Client ja genutzt) sitzen. Was bedeutet „am gleichen“ Switch. Ist der Angreifer dort hat er noch 10000 andere Möglichkeiten, gegen welche man sich absichern sollte. Dieses zur Vollständigkeit, da es gerade im speziellen um die Logmeldung geht, gibt es dazu ein anders mal genaueres 😀

Mehr zum Abschalten bis dahin hier:

http://askubuntu.com/questions/118273/what-are-icmp-redirects-and-should-they-be-blocked

So long….

Prefix delegation per DHCPv6 ist ja nichts neues. Das eine FritzBox dieses bietet war mir aber neu. Vielleicht „unterschätze“ ich das Teil? Nein… 😛

Ich bekomme ein /48 zugeteilt, die FirtzBox bietet die (nicht weiter konfigurierbare) Möglichkeit ein /62 per Prefix delegation an einen weiteren Router im Netzwerk weiter zu geben.

Ich habe also mal meinen Mikrotik über den DHCPv6 Client mit einem Prefix füttern lassen. Der Mikrotik arbeitet als Hotspot und Trenner fürs Wlan usw.. Nun schiebt dieser das per Prefix delegation zugewiesene IPv6 /64 auch ins Wlan durch 🙂

Damit ist im Wlan nun über die FritzBox und über den Mikrotik auch IPv6 angekommen. Leider lässt sich an der FirtzBox kaum etwas hinsichtlich Netzwerk konfigurieren. Ist halt alles Zielgruppengerecht. Ich muss zugeben, hier hat mich die Kiste von AVM überrascht. Vielleicht schreibe ich sogar noch ein kleines HowTo zusammen… Vielleicht… 😛

Nun arbeite ich schon seit einigen Jahren, privat wie im Berufsleben, mit IPv6. Was mir bei vielen Schulungen, Einführungen, Netzumstellungen usw… auffällt ist dass es vielen Admins schwer fällt zu verstehen wie der Client nun an seine Netzwerkkonfiguration kommt. Da in der letzten Zeit immer mehr Fragen zu dem Thema bei mir landen (scheinbar müssen viele jetzt noch „auf den letzten Drücker“ IPv6 lernen), versuche ich es hier mal grob aufzuschlüsseln.

Im Grunde ist es ganz einfach:
–    Bei IPv6 verteilt der DHCPv6 Server keine Default Route, das macht der Router!
–    Der DHCPv6 kann DNS Server, NTP-Server usw. verteilen und für eine automatische Eintragung des Clients am DNS Server sorgen. Er kann natürlich auch zusätzliche IPv6 Adressen verteilen.
–    Der Router verteilt sein Präfix per RA (Router Advertisment).
      o    Der Client kümmert sich um die Generierung einer IP-Adresse.
      o    Im RA kann der Client aufgefordert werden einen DHCPv6 Server nach weiteren Informationen zu fragen.
      o    Im RA kann ein DNS Server an den Client übergeben werden (RDNSS)

Erst einmal ist also für eine vollständige Autokonfiguration des Clients kein DHCPv6 Server mehr nötig. Denn der Client hat immer und direkt eine IPv6 Adresse vom scope link (fe80:….). Diese Adresse hat der Client sobald er einen Netzwerklink hat und wird aus der eigenen MAC-Adresse per EUI (Extended Unique Identifier) erstellt. Nun sendet der Client im einfachsten Fall ein RS (Router Solicitation) an die Multicast Adresse, auf welche ALLE Router hören, ins Netzwerk (ff02::2). Der Router antwortet dann mit einem RA und übermittelt dem Client das IPv6-Präfix. Der Client baut dann aus diesem Präfix und EUI wieder eine Adresse vom scope global. Sowie bei aktivierten Privacy Extensions eine gewürfelte Adresse. Der Client hat nun mindestens zwei IPv6 Adressen bei aktivierten Privacy Extensions sogar bereits drei IPv6 Adressen, sowie eine Default Route über den Router welcher uns den RA verpasst hat.

Ist am Router die Option RDNSS gesetzt wird dem Client zum Präfix auch noch ein DNS Server übergeben. Dieses ~verstehen~ leider noch nicht alle Clients. Damit wäre der Client schon in der Lage vollständig am „Internetleben“ teil zu nehmen.
Ist am Router das Other Config Flag gesetzt, wird der Client angewiesen einen DHCPv6 Server nach weiteren Einstellungen/Informationen zu fragen.

Nun kommt der DHCPv6 Server ins Spiel. Wird dieser vom Client nach weiteren Einstellungen/Informationen gefragt wird er die gewünschten Informationen an den Client übermitteln. Was nicht bedeutet dass der Client damit eine weitere IPv6 Adresse bekommen muss. Es ist auch möglich nur wins, ntp, dns usw.. an die Client zu übermitteln. Der Client muss dazu über einen DHCPv6-Client verfügen. Dieser ist bisher noch nicht bei allen Clientsystemen per Default vorhanden bzw. aktiviert!

Natürlich kann man seinen DHCPv6 Server auch so konfigurieren dass er zusätzlich noch eine dritte bzw. vierte (oder mehr) IPv6 Adresse an den Client übermittelt. Damit wäre der DHCPv6-Server zusätzlich in der Lage diese IPv6 Adressen einem DNS Server bekannt zu machen.

Wie auch beim Thema NAT bei IPv6 gibt es Vorschläge dem DHCPv6 Server wieder die Option Route zu spendieren, ich denke es ist nicht nötig / sinnvoll… Hier kann man sich streiten!

Die Idee bei IPv6 möglichst viel Arbeit auf den Client zu verlagern ergibt meist erst auf den zweiten Blick Sinn. Bei IPv4 war es bisher so dass der Client als erstes ins Netzwerk herumbrüllt ob den ein DHCP Server da ist, dann gab es einen regen Austausch zwischen diesen Systemen und am Ende hatte der Client alle seine Informationen. Denkt man aber nun daran dass im größten IPv4 Netzausbei maximal (24^2)-2 Hostadressen herausspringen und beim IPv6 im kleinsten Netzausbau minimal (64^2)-2 Hostadressen herausspringen… Ja dann ahnt man schon, wenn sich hier ein Router noch ums Popo abwischen kümmern muss, dann ist nicht mehr viel mit Netzwerk.

Noch Fragen? Dann fragen….

RIPE ist in Sachen IPv4 Adressen nun soweit leer dass sie nun auf ein „erweitertes“ Vergabeverfahren wechseln. Soll bedeuten dass nun ganz super streng (bla bla bla) kontrolliert wird warum und wo die Adresse hingeht und ob die auch wirklich gebraucht wird…..

Wie auch immer! Damit man sich besonders gut anschauen kann was noch übrig ist gibt es von den Jungs selbst eine kleine Grafik (http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph).

Dass ich ein großer Freund davon bin, mal endlich mit IPv6 aus dem Arsch zu kommen, muss ich ja keinem mehr erzählen. Wenn ich mir andere Hochrechnungen anschaue (http://www.potaroo.net/tools/ipv4/index.html) dann haben wir aktuelle noch bis zum 24.09.2012 (das ändert sich noch mal) IPv4 Adressen 😛

Ja ja… IPv4 ist ab dem Tag nicht tot (Dualstack für die nächsten Jahre..) und unsere Provider und Hoster haben auch noch Reserven. Zusätzlich kann man ab dem Moment beginnen seine IPv4 Adressen zu verkaufen *lach*…..  AAAABBBER, warum der ganze Stress? Warum nicht einfach mal mit IPv6 beschäftigen? Nein nein, ich meine wirklich beschäftigen, nicht nur so tun als ob 😛