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.

dhcp Bereich
      einschränken


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 Tage beschwerdefrei. Aufgund 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. Lediglich der Mappingpool könnte dadurch schneller voll werden. (Abhilfe regelmäßiges Löschen)
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.





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