[freifunk-public] Autoupdater über IPv6

[Ralf Jung]

Hi,

>>> 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.

Was sagt denn "ip -6 route show"?

>> 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.

>> 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>" als auch
"ping -I <öffentliche client-adresse> <öffentliche knoten-adresse>"
probierst?

>> 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.

> 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)

Viele Grüße,
Ralf