Freifunk-Gateway aufsetzen/xlat464

!!Achtung noch ungetestet!!

Erklärung

Mit clatd können den Clients in den Hoods ganz normal Dualstack (IPv4 und IPv6) angeboten werden. In der Freifunk Backbone muss aber nur noch IPv6 geroutet werden. Dazu werden am Gateway die IPv4 Pakete mit xlat464 ins IPv6 übersetzt und auf einen NAT64 Server im Freifunkbackbone (davon gibt es mittlerweile mehrere) wieder in IPv4 übersetzt. Somit ist für die Clients eine ganz normale IPv4 Kommunikation möglich, es gibt für die Clients keinen Unterschied zu normalen Dualstack wie es bisher genutzt wird.

Einrichtung

Zuerst benötigen wir eine weitere ULA IPv6 Adresse. Diese Adresse darf an kein Interface gebunden sein, muss aber ins Babel announced werden. Dies können wir mit einer route in der fff table erledigen:

ip -6 ro replace fd43:5602:29bd:ffff::deine_res_ip/128 dev lo proto static table fff

Für diese IP müssen wir zwingend in die main table gucken da dort später clatd eine route ablegt (priority kann angepasst werden, die rule sollte aber sehr bald greifen!):

ip -6 ru add from all to fd43:5602:29bd:ffff::deine_res_ip/128 lookup main priority 10

Danach installieren wir clatd nach Anleitung https://github.com/toreanderson/clatd:

cd ~
git clone https://github.com/toreanderson/clatd
sudo make -C clatd install installdeps

Wir müssen die config ein klein wenig erweitern:

/etc/clatd.conf

dns64-servers=fd43:5602:29bd:ffff:1:1:1:64
v4-conncheck-enable=no
clat-v6-addr=fd43:5602:29bd:ffff::deine_res_ip

In der ersten Zeile wird der DNS64 Server für das 64:ff9b::/96 Subnetz angegeben (nur nötig wenn dieser DNS Server nicht am Gateway eingetragen werden kann, alternativ kann dieser DNS Server auch direkt am Gateway genutzt werden). In der 2. Zeile wird der IPv4 Check deaktiviert (das Gateway hat in den meisten Fällen eine IPv4 Adresse, so das dieser Check sonst den Abbruch bedeutet) und in der 3. Zeile wird die IP Adresse angegeben die wir oben bereits entsprechend geroutet haben.

Danach kann man clatd starten:

systemctl restart clatd

Den Status ob alles geklappt hat mit

systemctl status clatd

angucken, es sollte etwa so aussehen:

● clatd.service - 464XLAT CLAT daemon
   Loaded: loaded (/etc/systemd/system/clatd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2021-01-19 14:56:27 CET; 13min ago
     Docs: man:clatd(8)
 Main PID: 11764 (clatd)
    Tasks: 2 (limit: 2359)
   Memory: 18.5M
   CGroup: /system.slice/clatd.service
           ├─11764 /usr/bin/perl -w /usr/sbin/clatd
           └─11780 tayga --config /tmp/Tm3kPlgTzD --nodetach

Jan 19 14:56:27 uranus clatd[11764]: Creating and configuring up CLAT device 'clat'
Jan 19 14:56:27 uranus clatd[11764]: Created persistent tun device clat
Jan 19 14:56:27 uranus clatd[11764]: Adding IPv4 default route via the CLAT
Jan 19 14:56:27 uranus clatd[11764]: Starting up TAYGA, using config file '/tmp/Tm3kPlgTzD'
Jan 19 14:56:27 uranus tayga[11780]: starting TAYGA 0.9.2
Jan 19 14:56:27 uranus tayga[11780]: Using tun device clat with MTU 1500
Jan 19 14:56:27 uranus tayga[11780]: TAYGA's IPv4 address: 192.0.0.2
Jan 19 14:56:27 uranus tayga[11780]: TAYGA's IPv6 address: 64:ff9b::c000:2
Jan 19 14:56:27 uranus tayga[11780]: NAT64 prefix: 64:ff9b::/96
Jan 19 14:56:27 uranus tayga[11780]: Note: traffic between IPv6 hosts and private IPv4 addresses (i.e. to/from 64:ff9b::10.0.0.0/104, 64:ff9b::192.168.0.0/112, etc) will be dropped.  Use a translation prefix within your organization's IPv6

Danach müssen noch die Freifunk Netze auf das clat Interface geroutet und genNATet werden:

ip ro replace default dev clat table fff
iptables -t nat -A POSTROUTING -o clat -j SNAT --to-source 192.0.0.1

Es können somit in den Hoods auch IPv4 Adressen verwendet werden, die nicht im Freifunk reserviert sind, z.b. aus dem 192.168.0.0/16 Netz (z.b. für jede Hood ein /23 aus diesem Netz)

Nacharbeiten

Wenn man kein IPv4 mehr routen möchte kann im babeld IPv4 komplett deaktivieren und auf den Gateway alle IPv4 Adressen auf allen peering Interfaces verwerfen. Dies sollte zum aktuellen Zeitpunkt (!!)noch nicht gemacht(!!) werden!

Nachteil

Babelpeers die von einem Abhängig sind, können kein IPv4 mehr über einen routen und sind von der IPv4 Welt abgeschnitten

Lösungsmöglichkeiten

Da 64:ff9b::/96 private IPv4 Adressen nicht umgesetzt werden (siehe letzte Meldung im clatd status) kann ein anderes /96 Netz verwendet werden. Damit werden auch private IPv4 Adressen umgesetzt und man könnte allen peers nur noch eine default route anbieten .

Ergebnis

Eventuell vorhandene Nebeneffekte sind noch nicht wirklich bedacht, zum aktuellen Zeitpunkt sollte daher erstmal IPv4 weiter geroutet werden. Es kann aber durchaus für eigene Hoods bereits xlat464 umgesetzt werden so das man zumindest für eigene Clients kein IPv4 Netz mehr benötigt.