IPv4 - einfach mal abschalten

oder

NAT64 mit dem Raspberry Pi4

Vorwort

Es gibt viele Wege IPv4 Lebewohl zu sagen. Einer der einfachsten ist es, sich an einem Netzwerk anzumelden, in dem kein IPv4 mehr vorhanden ist. Das geht beispielsweise im Mobilfunknetz der Deutschen Telekom (APN: internet.v6.telekom) aber auch beim WLAN im Einzugsbereich des LRZ. (SSID: eduroam-IPv6only)

Alternativ kann man sich durch Nutzung von öffentlichen DNS64/NAT64-Gateways in die neue Welt versetzen.

https://nat64.xyz/

https://nat64.net/public-providers

Wenn man seine Daten nicht kreuz und quer durch die Welt schicken will, sollte man DNS64/NAT64 selber machen. (sofern es der ISP noch nicht anbietet).
Eine ausführliche Beschreibung von NAT64 und DNS64 findet man auch bei Apple, allerdings mit einem abweichenden Testszenario.

Mein Testfeld ist einfach beschrieben: Sowohl PC als auch der Raspberry Pi, der als Sondergateway dient, sind direkt an der Fritzbox angeschlossen. NAT64 besteht eigentlich aus einem stateless NAT64(tayga) und einem stateful NAT. Um doppeltes NAT bei IPv4 zu vermeiden, überlasse ich das stateful NAT allein der Fritzbox.

Insgesamt entstehen fünf verschiedene Adressbereiche bzw Subnetze.

64:ff9b::/96 - der reservierte Adressbereich für NAT64

2001:db8:548:301:dea6:32ff:feb7:f781/64 - der vom ISP bzw. von der Fritzbox verteilte Adressbereich

fd00::/64 - der lokal von der Fritzbox verteilte Adressbereich

192.168.178.1/24 - der üblicherweise bei der Fritzbox verwendete Adressbereich nach RCF1918

192.168.178.224/28 - ein Subnetz davon, welches via proxy arp zu tayga geleitet wird.

Zu NAT64 gehört in der Regel auch DNS64. Hier verweise ich auf die DNS64-Konfiguration mit unbound oder auf dns64.dns.google.

Vorbereitung

Lauffähiger Raspberry Pi 4 mit tayga Paket.

Durchführung

Einige Änderungen an der Fritzbox.
Eintragen des oben erwähnten DNS-Resolvers.

alternativer DNS-Server
in Fritzbox, hier mit mit DNS64 von google via DoT

Verhindern, dass die Fritzbox den ausgewählten Netzbereich für DHCP verwendet.

Das NAT64-Präfix von der Fritzbox zum Raspberry Pi routen.

NAT64-Präfix
Route in Fritzbox eintragen

NAT64-Präfix in der
Fritzbox als IPv6-Route eintragen

Nun zum eigentlichen NAT64-Teil, der Einrichtung von Tayga. Hierzu die Daten aus der Konfigurationsdatei /etc/tayga.conf



        tun-device nat64

        

        ipv4-addr 192.168.178.224

        

        ipv6-addr fd00::dea6:32ff:feb7:f781

        

        prefix 64:ff9b::/96

        

        dynamic-pool 192.168.178.224/28

        

        data-dir /var/spool/tayga

Kurz zu Erläuterung:

nat64 ist das Interface zwischen Kernel und Tayga. Die Adressübersetzung findet im "Userspace" von Tayga statt.
64:ff9b::/96 ist das IPv6-Präfix, in das die weltweiten IPv4-Adressen hinein gemappt werden
192.168.178.224/28 ist das Präfix, welches Tayga ausgehend nutzt, Tayga reserviert für jeden IPv6-Host im lokalen Netz eine Adresse aus diesem Pool (data-dir)
fd00::dea6:32ff:feb7:f781 braucht Tayga der Vollständigkeit halber

Damit nicht zweimal NAT bei IPv4 betrieben wird, eignet sich der Raspberry-Pi bzw. Tayga den Adressbereich via proxy arp an.

Der große Moment:



      

        #!/bin/bash

        

        # statische IPv4-Konfiguration, da dhcp auf pi ausgeschaltet

        

        /sbin/ip addr add 192.168.178.223/24 dev eth0

        /sbin/ip route add default via 192.168.178.1

        

        /usr/sbin/tayga --mktun

        

        /sbin/sysctl net.ipv6.conf.all.forwarding=1

        /sbin/sysctl net.ipv4.conf.all.forwarding=1

        

        /sbin/ip addr add 192.168.178.224/27 dev nat64

        /sbin/ip link set nat64 up

        /sbin/ip -6 route add 64:ff9b::/96 dev nat64

        

        /sbin/sysctl net.ipv4.conf.eth0.proxy_arp=1

        

        /usr/sbin/tayga



      Created persistent tun device nat64

      net.ipv6.conf.all.forwarding = 1

      net.ipv4.conf.all.forwarding = 1

      net.ipv4.conf.eth0.proxy_arp = 1

      

      journalctl -f

      -- Logs begin at Thu 2019-02-14 11:11:58 CET. --

      Feb 06 21:23:26 raspi64 avahi-daemon[359]: Registering new address
      record for 192.168.178.223 on eth0.IPv4.

      Feb 06 21:23:26 raspi64 kernel: tun: Universal TUN/TAP device
      driver, 1.6

      Feb 06 21:23:26 raspi64 tayga[814]: starting TAYGA 0.9.2

      Feb 06 21:23:26 raspi64 tayga[814]: Using tun device nat64 with
      MTU 1500

      Feb 06 21:23:26 raspi64 tayga[814]: TAYGA's IPv4 address:
      192.168.178.224

      Feb 06 21:23:26 raspi64 tayga[814]: TAYGA's IPv6 address:
      fd00::dea6:32ff:feb7:f781

      Feb 06 21:23:26 raspi64 tayga[814]: NAT64 prefix: 64:ff9b::/96

      Feb 06 21:23:26 raspi64 tayga[814]: 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 address space instead of 64:ff9b::/96 if you need your IPv6
      hosts to communicate with private IPv4 addresses.

      Feb 06 21:23:26 raspi64 tayga[814]: Dynamic pool:
      192.168.178.224/28

      Feb 06 21:23:26 raspi64 kernel: IPv6: ADDRCONF(NETDEV_CHANGE):
      nat64: link becomes ready

Auf dem PC in der Zwischenzeit:



      /usr/sbin/traceroute6 www.tagesschau.de

      traceroute to www.tagesschau.de (64:ff9b::1736:6a3d), 30 hops max,
      80 byte packets

       1  fritz.box
      (2001:db8:548:301:9a9b:cbff:fe05:4241)  1.309 ms  1.842
      ms  2.430 ms

       2  raspi64.fritz.box
      (2001:db8:548:301:dea6:32ff:feb7:f781)  3.649 ms  3.789
      ms  4.137 ms

       3  raspi64.fritz.box (fd00::dea6:32ff:feb7:f781) 
      4.811 ms  5.160 ms  5.455 ms

       4  raspi64.fritz.box (fd00::dea6:32ff:feb7:f781) 
      6.059 ms  6.291 ms  6.561 ms

       5  * * *

       6  host-62-245-142-137.customer.m-online.net
      (64:ff9b::3ef5:8e89)  14.888 ms  7.126 ms  17.201
      ms

       7  host-62-245-142-136.customer.m-online.net
      (64:ff9b::3ef5:8e88)  17.180 ms  17.246 ms  17.232
      ms

       8  ae0.rt-inxs-2.m-online.net
      (64:ff9b::5287:10b1)  17.322 ms  17.397 ms  17.488
      ms

       9  inxs-muc.netarch.akamai.com
      (64:ff9b::c23b:be3b)  27.290 ms  27.281 ms  27.352
      ms

      10  * * *

      11  * * *

      12  * * *

      13  * * *

      14  * * *

      15  * * *

      16  * * *

      17  * * *

      18  * * *

      19  * * *

      20  * * *

      21  * * *

      22  * * *

      23  * * *

      24  * * *

      25  * * *

      26  * * *

      27  * * *

      28  * * *

      29  * * *

      30  * * *

      

      

      ping -c 3  www.tagesschau.de

      PING
      www.tagesschau.de(a23-54-106-61.deploy.static.akamaitechnologies.com
      (64:ff9b::1736:6a3d)) 56 data bytes

      64 bytes from a23-54-106-61.deploy.static.akamaitechnologies.com
      (64:ff9b::1736:6a3d): icmp_seq=1 ttl=56 time=5.80 ms

      64 bytes from a23-54-106-61.deploy.static.akamaitechnologies.com
      (64:ff9b::1736:6a3d): icmp_seq=2 ttl=56 time=4.05 ms

      64 bytes from a23-54-106-61.deploy.static.akamaitechnologies.com
      (64:ff9b::1736:6a3d): icmp_seq=3 ttl=56 time=4.15 ms

      

      --- www.tagesschau.de ping statistics ---

      3 packets transmitted, 3 received, 0% packet loss, time 2003ms

      rtt min/avg/max/mdev = 4.050/4.670/5.809/0.806 ms

Nachwort

Es funktioniert bei mir jetzt einige Monate beschwerdefrei. Aufgrund der Verwendung des speziellen NAT64-Präfixes und der lokalen IPv6-Adresse für das NAT64-Gateway ist dieses Setup relativ immun gegenüber Präfixwechsel von Seiten des ISP.
Das Routing ist nicht ganz optimal (Umweg über Fritzbox) . Trotzdem werden 300Mbit/s geschafft(Limit meines Anschlusses).

Diese Anleitung entstand auf Anregung dieses Videos vom Meeting der RIPE und der Ankündigung Googles neuer public DNS64-Resolver zur gleichen Zeit.

Nachwort zum Nachwort

Tayga ist schon relativ alt und erfährt auch keine aktive Pflege mehr. Es lohnt sich auch nach Alternativen umzuschauen. Eine sehr bekannte Alternative ist Jool. Jool hat einen Nachteil und einen Vorteil: Es läuft im Kernel.

Im einfachsten Fall lässt man es gleich stateful NAT64 machen. Sofern Kernel, Kernelmodul und die Werkzeuge zueinander passen, kann das sogar mit einem Zweizeiler erfolgen:

modprobe jool

/usr/bin/jool instance add "default" --netfilter
        --pool6 64:ff9b::/96

Die Route 64:ff9b::/96 muss dabei nach wie vor von der Fritzbox umgeleitet werden. Ansonsten steckt viel Magie in diesem Aufruf. Damit man sieht, was dabei vorgeht, hat der Entwickler ein paar Abfragemöglichkeiten geschaffen. Zum Beispiel:

jool bib display

jool global display

jool stats display

jool session display

Jool enthält auch ein siit-Modul mit dem die clientseitige Rückübersetzung (clat) von 464xlat erfolgen kann.

Eine recht junge NAT64-Implementation ist tundra-nat64. Diese arbeitet ähnlich wie tayga im Userspace und kann auch sowohl für NAT64 als auch für CLAT verwendet werden. Das CLAT-Beispiel habe ich auch auf opensuse(tumbleweed Oktober 2022) erfolgreich nutzen können. (modrobe ip6_tables muss ggf. zusätzlich aufgerufen werden)

DNS64

RaspberryPI OS/Debian 11 mit unbound

Verhindern des automatischen Updates der Forwarder in der Datei /etc/resolvconf.conf

# unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

Entfernen der Datei

rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

Ergänzen der eigenen Konfiguration unter:

/etc/unbound/unbound.conf.d/local-change.conf

# /etc/unbound/unbound.conf.d/local-change.conf server: verbosity: 1 interface: fd00::dea6:32ff:feb7:f781 ip-freebind: yes # interface: ::0# interface-automatic: yes# access-control: fd00::/64 allow# access-control: 2001:a61::/32 allow module-config: "dns64 validator iterator" #dns64-prefix: 64:ff9b::/96 # well-known prefix (default) local-data: "fritz.box IN AAAA fd00::9a9b:cbff:fe05:4241"# static manual setting#forward-zone: name: "." forward-addr: fd00::9a9b:cbff:fe05:4241

Je nach Firewalleinstellungen auf dem Raspi bzw. dem Router hat man etwas Gestaltungsspielraum beim Schutz vor fremden Ge/Missbrauch.
Ich habe mich vorläufig für die Verwendung von ULA entschieden.
Während nun der Raspi seine Anfragen an die Fritzbox schickt, kann man in dieser einstellen, dass der raspi als Resolver verwendet werden soll:

lokaler
Resolver in Fritzbox