[freifunk-public] Autoupdater über IPv6

[Patrick Peisch]

Hallo,
>
>>>> Ich habe jetzt manuell die öffentliche IPv6 des Node
>>>> (die bekommt er per RA von meinem Router) entfernt
>>>> und schwupps hat er den Update-Server per unique-local Adresse
>>>> über den fastd-Tunnel erreicht.
>>>>
>>>> Ein Ping an eine IPv6 Adresse funktioniert nicht.
>>>> Ein Ping an eine IPv4 Adresse funktioniert,
>>>> traceroute zeigt auch, dass er das IPv4 Internet direkt erreichen kann.
>>>
>>> Offenbar klappt also IPv6 ins Freifunk-Netz, aber nicht ins Internet.
>> Das ist bekannt. Öffentliche IPv6 Adressen kann man aus dem Freifunk
>> heraus nicht erreichen, man bekommt ja nur unique-local Adressen und
>> die werden m.W. nicht genNATet.
>
> Ja klar, die *Clients* kommen per IPv6 nicht raus. Aber die Knoten haben
> ja Zugang zu beiden Netzen, also deinem lokalen Netz und dem Freifunk-Netz.
>
> Wenn auf den Knoten IPv4-Traffic im Bereich 10.24.192.0/18 anfällt, geht
> der über den fastd-Tunnel an das GW (und wird dort nicht geNATet, da der
> Traffic ja an lokale Adressen geht). Alles andere geht über das
> WAN-Interface an den lokalen Router.
> Per IPv6 sollte das wohl ähnlich laufen, und die erste Hälfte klappt
> auch (lokaler Traffic ins FF-Netz), aber die zweite Hälfe eben nicht.
Gemäß Routing Tabelle sollte das auch genau so laufen.
>
> Was sagt denn "ip -6 route show"?

ip -6 r
2001::/64 dev br-wan  metric 256
default via fe80::(mein lokaler Router) dev br-wan  metric 512
unreachable default dev lo  metric 65535  error -128
unreachable default dev lo  metric -1  error -128
unreachable default dev lo  metric -1  error -128
fd4e:f2d7:88d2:ffff::1 dev local-node  metric 256
fd4e:f2d7:88d2:ffff::/64 dev br-client  metric 256
fd4e:f2d7:88d2:ffff::/64 dev br-client  metric 1024
unreachable fd8c:f25b:42ea::/48 dev lo  metric 2147483647  error -128
fe80::/64 dev mesh-vpn  metric 256
fe80::/64 dev bat0  metric 256
fe80::/64 dev br-client  metric 256
fe80::/64 dev local-node  metric 256
fe80::/64 dev br-wan  metric 256
fe80::/64 dev client0  metric 256
fe80::/64 dev ibss0  metric 256
default via fe80::6c38:69ff:fef1:19ed(gw1) dev br-client  metric 512
unreachable default dev lo  metric -1  error -128
ff00::/8 dev local-node  metric 256
ff00::/8 dev mesh-vpn  metric 256
ff00::/8 dev bat0  metric 256
ff00::/8 dev br-client  metric 256
ff00::/8 dev br-wan  metric 256
ff00::/8 dev client0  metric 256
ff00::/8 dev ibss0  metric 256
unreachable default dev lo  metric -1  error -128


>>> Hast du mal andere IPv6-Adressen versucht?
>> Keine Chance, komme nicht raus.
>>
>>> Insbesondere solche bei dir im lokalen Netz?
>> Ebenfalls keine Verbindung.
>> Wobei ich die Node auf ihrer öffentlichen IPv6 pingen kann.
>> (aus meinem LAN heraus)
>
> Der Node bei uns im Space hat sich übrigens neulich automatisch
> aktualisiert (soweit ich das sehe), obwohl er eine öffentliche
> IPv6-Adresse hat. Also prinzipiell sollte der Auto-Updater durchaus klappen.
Gut zu wissen, dann sollte es beim nächsten Update keine Probleme geben,
ich werde das mal im Auge behalten.
>
>>> Was ist mit Pingen an die unique-lokalen Adressen?
>> klappt.
>
> Sorry, ich meinte hier link-lokale Adresse, also "fe80::...". Eine
> uniq-lokale Adresse ("fd...") haben Rechner in "normalen"
> Endnutzer-Netzen üblicherweise nicht.
>
>>> Klappt letzteres auch, *bevor* du die öffentliche IPv6 des Nodes
>>> gelöscht hast?
>> mais oui
>
> Okay... dann macht das vielleicht auch Sinn, dass du die öffentliche
> IPv6 des Knotens von einem anderen Rechner in deinem LAN aus anpingen
> kannst: Die Pings haben die link-lokale Adresse des Rechners in deinem
> LAN als Absender. Könntest du das prüfen, indem du sowohl "ping -I
> <link-lokale client-adresse> <öffentliche knoten-adresse>"
das klappt nicht, 100% packet loss
ping6 -I fe80::%eth0 2001::(Node)
als auch
> "ping -I <öffentliche client-adresse> <öffentliche knoten-adresse>"
> probierst?
das funktioniert
ping6 -I 2001::(Rechner) 2001::(Node)

>
>>> Was wir im Prinzip machen könnten ist, die öffentliche IPv6-Adresse
>>> des Update-Servers rauszunehmen. Wobei er die interne Adresse eh
>>> vorziehen sollte, sie steht zumindest zuerst in der Liste.
>> Dann geht man dem Problem aber eher aus dem Weg, als es zu lösen.
>
> Stimmt ;-) . Das wäre der Patch, damit wenigstens der Auto-Updater klappt.
>
>> Nochmal kurz zusammengefasst:
>> - Internetanschluss mit IPv6
>> - Node bekommt eine öffentliche IPv6, über die sie auch erreichbar ist
>> (zumindest pingbar, SSH geht nach wie vor über v4)
>> - IPv4 von der Node ins Internet geht über WAN direkt raus
>> - IPv6 von der Node ins Freifunk Netz geht über den fastd Tunnel ans GW
>> - IPv6 von der Node ins Internet geht anscheinend auch über den Tunnel,
>> bleibt aber am GW hängen, da kein NAT gemacht wird.
>
> NAT will man sowieso nicht machen bei IPv6. Statt dessen werden Clients
> irgendwann per RA auch eine öffentliche Freifunk-IPv6 zugewiesen
> bekommen, und die wird dann geroutet auf den GWs.
>
> Clients sollten normalerweise gar nicht erst versuchen, globale
> IPv6-Adressen zu erreichen mit einer uniq-lokalen Adresse. Und das
> scheint auch zu klappen; mein Laptop z.B. bekommt zwar eine uniq-lokale
> IPv6-Adresse; wenn ich habe mit "ralfj.de" reden will, versucht er gar
> nicht erst, das perIPv6 zu machen. Clients "verstehen" also, dass man
> per uniq-lokaler Adresse nur andere uniq-lokale Adressen ansprechen kann.
Das sollte so sein, zumindest steht es ja auch so in der Routing Tabelle
>
>> Gemäß der IPv6 Routing Tabelle ist mein Router das Default GW für IPv6,
>> die unique-local Adressen gehen über br-client raus.
>> Ich nehme an, dass die ebtables ausgehendes IPv6 an br-wan blockieren,
>> der fastd verbindet sich auch über v4, obwohl das GW v6 kann.
>
> Naja, so ganz blockiert kann es ja nicht sein, wenn du den Knoten aus
> deinem LAN heraus auf IPv6 anpingen kannst. So weit ich weiß wird über
> ebtables nur jede Menge Broadcast-Traffic innerhalb des Freifunk-Netzes
> rausgefiltert, damit der nicht das ganze Netz überschwemmt. Aber der
> WAN-Traffic sollte nicht angefasst werden.
>
>> Ich hoffe du oder ihr könnt das im Space nachvollziehen
>> und vielleicht dahinter kommen, was hier abgeht =)
>
> Ich werde am Mittwoch mal schauen ;-) (wenn jemand da ist, der mir
> SSH-Zugang auf den Knoten da geben kann)
Ich bin gespannt, ob du etwas herausfindest.
Wäre wirklich schade, wenn die Node nicht mehr funktioniert,
wenn ich irgendwann auf IPv6-only umstelle,
falls das mal passiert :D

Danke dir,
Gruß Patrick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4230 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.hacksaar.de/pipermail/freifunk-public/attachments/20160220/40d2a136/attachment.bin>