NAT64: Unterschied zwischen den Versionen
NiXXda (Diskussion | Beiträge) (→Beobachtungen: add macOS 14.2.1) |
|||
(33 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
Zeile 3: | Zeile 3: | ||
== Aktuelle Probleme == | == Aktuelle Probleme == | ||
* Keine mehr bekannt, aktuell läuft es wie erwartet | * Keine mehr bekannt, aktuell läuft es wie erwartet | ||
== Beobachtungen == | |||
* Android 8.1 und Android 9 funktionieren einwandfrei und machen xlat464 RDNSS tut auch. Android 7.1.1 funktioniert ebenfalls. | |||
* Debian 9 kommt problemlos mit klar, RDNSS tut einwandfrei. Mit clatd https://github.com/toreanderson/clatd funktioniert auch xlat464 problemlos | |||
* Windows 10 funktioniert einwandfrei auch mit RDNSS. xlat464 Funktion unbekannt | |||
* Windows 8.1 macht NAT64 nimmt aber einen per RDNSS ausgelieferten DNS nicht an. Auch DHCPv6 wird der DNS nur angenommen, wenn eine IP mit ausgeliefert wird. Hier muss abgewogen werden, ob man dies noch unterstützen will. | |||
* iPhone/iPad scheint mit 12.1.2 problemlos zu gehen. xlat464 wird auch hier unterstützt. RDNSS geht hier einwandfrei | |||
* div. weitere Geräte keine Erfahrung | |||
{| class="wikitable" style="text-align: center; | |||
! OS !! Version !! SLAAC !! RDNSS !! xlat464 !! Notizen | |||
|- | |||
| Android || 7+ || {{yes}} || {{yes}} || {{yes}} || | |||
|- | |||
| || 5, 6 || {{yes}} || {{yes}} || {{yes}} || Nicht getestet | |||
|- | |||
| Linux || - || {{yes}} || {{yes}} || Mit Software, z.B. clatd | |||
|- | |||
| Windows || 10 || {{yes}} || {{yes}} || nicht default || RDNSS ab Windows 10 Creators Update | |||
|- | |||
| || 8.1 || {{yes}} || {{no}} || ? || | |||
|- | |||
| macOS || 14.2.1 || {{yes}} || {{yes}} || {{yes}} || | |||
|- | |||
| || 10.15.7 || {{yes}} || {{yes}} || {{no}} || | |||
|- | |||
| iOS || 12.1.2 || {{yes}} || {{yes}} || {{yes}} || | |||
|} | |||
Siehe auch: https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems | |||
== Vorraussetzung == | == Vorraussetzung == | ||
Zeile 10: | Zeile 40: | ||
** Bei mir ist es ens9 welches direkt in der Babelbridge über den Host hängt | ** Bei mir ist es ens9 welches direkt in der Babelbridge über den Host hängt | ||
* es wird weder eine public v4 noch eine public v6 auf der VM benötigt (z.b. Hetzneradresse o.ä.) die VM muss nur im Freifunk L3 Netz hängen | * es wird weder eine public v4 noch eine public v6 auf der VM benötigt (z.b. Hetzneradresse o.ä.) die VM muss nur im Freifunk L3 Netz hängen | ||
** Man muss nur im Kopf behalten, das der gesamte NAT64 Traffic über diese VM geht, sie sollte also schnell angebunden sein und genug Traffic haben | |||
== Benötigte Programme == | == Benötigte Programme == | ||
Zeile 15: | Zeile 46: | ||
* bind9 | * bind9 | ||
* tayga | * tayga | ||
== Probleme == | |||
Webseiten die einen AAAA DNS Rekord haben aber damit nicht erreichbar sind (z.b. speedof.me oder fridaysforfuture.de ) sind in einem DNS64/NAT64 System nicht erreichbar. Unter Linux mit clatd funktioniert es aber einwandfrei. Android 8.1 xlat464 funktioniert hier allerdings anscheinend nicht. | |||
== Tayga config == | == Tayga config == | ||
Zeile 33: | Zeile 67: | ||
tayga kann später getestet werden, indem man es manuell mit dem Parameter -d startet dann sieht man was gerade passiert (z.b. zur Fehlersuche) | tayga kann später getestet werden, indem man es manuell mit dem Parameter -d startet dann sieht man was gerade passiert (z.b. zur Fehlersuche) | ||
== radvd config == | |||
folgendes muss in der radvd config zum Interface hinzuegfügt werden: | |||
<pre> | |||
RDNSS 2a06:e881:340a:xxxx::1 # DNS Server | |||
{ | |||
AdvRDNSSLifetime 600; | |||
}; | |||
</pre> | |||
wird ein DHCPv6 Server dahinter betrieben sind evtl. folgende Option(en) sinnvoll auf on zu stellen: | |||
* AdvOtherConfigFlag | |||
* AdvManagedFlag | |||
== Interface config == | == Interface config == | ||
Zeile 45: | Zeile 91: | ||
address 10.83.252.XX # hier muss die eigene priv. v4 Adresse aus dem Freifunknetz drauf | address 10.83.252.XX # hier muss die eigene priv. v4 Adresse aus dem Freifunknetz drauf | ||
netmask 255.255.255.255 | netmask 255.255.255.255 | ||
#iprules v4 setzen | |||
post-up ip rule add from all lookup fff priority 20 # wir biegen den kompletten default Traffic auf Freifunk um. | post-up ip rule add from all lookup fff priority 20 # wir biegen den kompletten default Traffic auf Freifunk um. | ||
#Masquerade aktivieren | |||
post-up iptables -t nat -A POSTROUTING -o $IFACE -j MASQUERADE #da tayga bei mir mit 192.168.X.X arbeitet, muss auf das ens9 ein NAT drauf da Rückroute unbekannt ist | post-up iptables -t nat -A POSTROUTING -o $IFACE -j MASQUERADE #da tayga bei mir mit 192.168.X.X arbeitet, muss auf das ens9 ein NAT drauf da Rückroute unbekannt ist | ||
#IPv6 | |||
iface ens9 inet6 static | iface ens9 inet6 static | ||
address 2a0b:yy:xx:6464::1/128 #v6 Adresse die im Freifunk dann erreichbar ist | address 2a0b:yy:xx:6464::1/128 #v6 Adresse die im Freifunk dann erreichbar ist | ||
#iprules v6 setzen | |||
post-up ip -6 rule add from all lookup fff priority 20 # hier biegen wir den kompletten default Traffic auf Freifunk um | post-up ip -6 rule add from all lookup fff priority 20 # hier biegen wir den kompletten default Traffic auf Freifunk um | ||
</pre> | </pre> | ||
Zeile 59: | Zeile 112: | ||
<pre> | <pre> | ||
#NAT64 | #NAT64 | ||
auto nat64 | auto nat64 | ||
iface nat64 inet static | iface nat64 inet static | ||
Zeile 65: | Zeile 119: | ||
address 10.83.252.53 #hier muss die v4 von Freifunk auch mit dran | address 10.83.252.53 #hier muss die v4 von Freifunk auch mit dran | ||
netmask 255.255.255.255 | netmask 255.255.255.255 | ||
post-up ip addr add 2a0b:yy:xx:6464::1 dev $IFACE #damit PMTU klappt, muss die Adresse auch hier ran | |||
#Routen setzen | |||
post-up ip route add 192.168.xx.x/24 dev $IFACE tab fff #damit die Rückroute von tayga bekannt ist muss diese in die Tabelle rein, es darf/muss kein proto static verwendet werden, da Babel die Rückroute nicht announcen muss da wir NAT machen | post-up ip route add 192.168.xx.x/24 dev $IFACE tab fff #damit die Rückroute von tayga bekannt ist muss diese in die Tabelle rein, es darf/muss kein proto static verwendet werden, da Babel die Rückroute nicht announcen muss da wir NAT machen | ||
post-up ip route add 192.168.xx.x/24 dev $IFACE #die Zeile ist überflüssig oder? | post-up ip route add 192.168.xx.x/24 dev $IFACE #die Zeile ist überflüssig oder? | ||
post-up ip route add 2a0b:yy:xx:6464::/96 dev $IFACE proto static tab fff #die Route muss per Babel announced werden damit auch von außen erreichbar | post-up ip route add 2a0b:yy:xx:6464::/96 dev $IFACE proto static tab fff #die Route muss per Babel announced werden damit auch von außen erreichbar | ||
#Tayga starten | |||
post-up tayga --config /usr/local/etc/tayga.conf #tayga mit der entsprechenden config starten | post-up tayga --config /usr/local/etc/tayga.conf #tayga mit der entsprechenden config starten | ||
post-up ip6tables -A FORWARD -s 2a0b:yy::/32 -d 2a0b:yy:xx:6464::/96 -j ACCEPT # | |||
post-up ip6tables -A FORWARD -d 2a0b:yy:xx:6464::/96 -j DROP | #Firewall | ||
#alles was von -s kommt und nach -d soll wird erlaubt | |||
post-up ip6tables -A FORWARD -s 2a0b:yy::/32 -d 2a0b:yy:xx:6464::/96 -j ACCEPT | |||
#icmpv6 erlauben, damit icmp errors ankommen und PMTU funktioniert | |||
ip6tables -A FORWARD -p icmpv6 -j ACCEPT | |||
#alles andere droppen | |||
post-up ip6tables -A FORWARD -d 2a0b:yy:xx:6464::/96 -j DROP | |||
</pre> | </pre> | ||
Zeile 83: | Zeile 147: | ||
options { | options { | ||
directory "/var/cache/bind"; | directory "/var/cache/bind"; | ||
forwarders { | |||
10.83.252.11; #ein DNS Server aus dem Freifunknetz damit auch fff.community korrekt beantwortet wird | |||
}; | |||
auth-nxdomain no; | auth-nxdomain no; | ||
listen-on-v6 { any; }; | listen-on-v6 { any; }; | ||
allow-query { any; }; # | allow-query { any; }; | ||
allow-recursion { 127.0.0.1/8; 2a0b:yy::/32; }; #nur eigenes Subnetz das auflösen erlauben! | |||
dns64 2a0b:yy:xx:6464::/96 { #die Adresse wo die v4 reingemappt werden | dns64 2a0b:yy:xx:6464::/96 { #die Adresse wo die v4 reingemappt werden | ||
clients { any; }; | clients { any; }; | ||
Zeile 106: | Zeile 174: | ||
</pre> | </pre> | ||
sollte mit der gemappten v6 antworten | sollte mit der gemappten v6 antworten | ||
== DHCPv6 == | |||
Windows 8.1 versteht die RDNSS Option vom radvd nicht. Daher bekommt er keinen DNS Server zugewiesen. EIne Lösung scheint hier DHCPv6 zu sein. Dies ist aktuell noch im Test. | |||
=== Benötige Programme === | |||
* isc-dhcp-server | |||
=== config file === | |||
/etc/dhcp/dhcpd6.conf | |||
(kann evtl. noch optimiert werden, sind erst erste Tests und vieles aus default config übernommen) | |||
<pre> | |||
default-lease-time 2592000; | |||
preferred-lifetime 604800; | |||
option dhcp-renewal-time 3600; | |||
option dhcp-rebinding-time 7200; | |||
allow leasequery; | |||
option dhcp6.name-servers 2a06:e881:340a:xxxx:1; # DNS Server | |||
option dhcp6.domain-search "fff.community"; | |||
subnet6 2a06:e881:340a:xxxx::/64 { #Subnetz des Interfaces | |||
interface bat10; | |||
} | |||
</pre> | |||
=== radvd === | |||
Folgende Optionen sollten sich im radvd näher angeschaut werden: | |||
* AdvOtherConfigFlag | |||
* AdvManagedFlag |
Aktuelle Version vom 26. Dezember 2023, 14:41 Uhr
Ich möchte hier mal grob versuchen das NAT64 Setup für Freifunk zu erklären.
Aktuelle Probleme
- Keine mehr bekannt, aktuell läuft es wie erwartet
Beobachtungen
- Android 8.1 und Android 9 funktionieren einwandfrei und machen xlat464 RDNSS tut auch. Android 7.1.1 funktioniert ebenfalls.
- Debian 9 kommt problemlos mit klar, RDNSS tut einwandfrei. Mit clatd https://github.com/toreanderson/clatd funktioniert auch xlat464 problemlos
- Windows 10 funktioniert einwandfrei auch mit RDNSS. xlat464 Funktion unbekannt
- Windows 8.1 macht NAT64 nimmt aber einen per RDNSS ausgelieferten DNS nicht an. Auch DHCPv6 wird der DNS nur angenommen, wenn eine IP mit ausgeliefert wird. Hier muss abgewogen werden, ob man dies noch unterstützen will.
- iPhone/iPad scheint mit 12.1.2 problemlos zu gehen. xlat464 wird auch hier unterstützt. RDNSS geht hier einwandfrei
- div. weitere Geräte keine Erfahrung
OS | Version | SLAAC | RDNSS | xlat464 | Notizen |
---|---|---|---|---|---|
Android | 7+ | Yes | Yes | Yes | |
5, 6 | Yes | Yes | Yes | Nicht getestet | |
Linux | - | Yes | Yes | Mit Software, z.B. clatd | |
Windows | 10 | Yes | Yes | nicht default | RDNSS ab Windows 10 Creators Update |
8.1 | Yes | No | ? | ||
macOS | 14.2.1 | Yes | Yes | Yes | |
10.15.7 | Yes | Yes | No | ||
iOS | 12.1.2 | Yes | Yes | Yes |
Siehe auch: https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems
Vorraussetzung
- 1 /96 v6 Netz (am besten ein /64 reservieren)
- eine v4 Adresse wo man v4 Traffic los werden kann (geht z.b. auch per Freifunk)
- eine VM die per Ethernet an das Babelnetz angebunden ist
- Bei mir ist es ens9 welches direkt in der Babelbridge über den Host hängt
- es wird weder eine public v4 noch eine public v6 auf der VM benötigt (z.b. Hetzneradresse o.ä.) die VM muss nur im Freifunk L3 Netz hängen
- Man muss nur im Kopf behalten, das der gesamte NAT64 Traffic über diese VM geht, sie sollte also schnell angebunden sein und genug Traffic haben
Benötigte Programme
Ich hab mit folgenden Programmen gearbeitet und sie hier beschrieben, es gibt bestimmt alternativen:
- bind9
- tayga
Probleme
Webseiten die einen AAAA DNS Rekord haben aber damit nicht erreichbar sind (z.b. speedof.me oder fridaysforfuture.de ) sind in einem DNS64/NAT64 System nicht erreichbar. Unter Linux mit clatd funktioniert es aber einwandfrei. Android 8.1 xlat464 funktioniert hier allerdings anscheinend nicht.
Tayga config
/usr/local/etc/tayga.conf
tun-device nat64 ipv4-addr 192.168.xx.1 prefix 2a0b:yy:xx:6464::/96 dynamic-pool 192.168.xx.0/24 data-dir /var/db/tayga
- Erste Zeile gibt das Device an worüber später Tayga arbeitet
- Zweite Zeile ist ein priv. Subnetz das tayga nutzt. Ich hab mich für ein 192.168.x.x entschieden. Man könnte auch ein 10er Subnetz hier im Wiki registrieren und per Babel announcen, dann spart man sich 1x NAT
- Dritte Zeile wird das /96 angegeben worein die v4 Adressen später gemappt werden
- Vierte Zeile ist der Pool den Tayga verwendet (2. Zeile)
- Fünfte Zeile wird angegeben wo Tayga die Datenbank ablegt (Ordner muss vorhanden sein bzw. manuell angelegt werden).
tayga kann später getestet werden, indem man es manuell mit dem Parameter -d startet dann sieht man was gerade passiert (z.b. zur Fehlersuche)
radvd config
folgendes muss in der radvd config zum Interface hinzuegfügt werden:
RDNSS 2a06:e881:340a:xxxx::1 # DNS Server { AdvRDNSSLifetime 600; };
wird ein DHCPv6 Server dahinter betrieben sind evtl. folgende Option(en) sinnvoll auf on zu stellen:
- AdvOtherConfigFlag
- AdvManagedFlag
Interface config
Freifunk
ens9 ist das Interface wo Babel drauf liegt:
#Freifunk auto ens9 iface ens9 inet static address 10.83.252.XX # hier muss die eigene priv. v4 Adresse aus dem Freifunknetz drauf netmask 255.255.255.255 #iprules v4 setzen post-up ip rule add from all lookup fff priority 20 # wir biegen den kompletten default Traffic auf Freifunk um. #Masquerade aktivieren post-up iptables -t nat -A POSTROUTING -o $IFACE -j MASQUERADE #da tayga bei mir mit 192.168.X.X arbeitet, muss auf das ens9 ein NAT drauf da Rückroute unbekannt ist #IPv6 iface ens9 inet6 static address 2a0b:yy:xx:6464::1/128 #v6 Adresse die im Freifunk dann erreichbar ist #iprules v6 setzen post-up ip -6 rule add from all lookup fff priority 20 # hier biegen wir den kompletten default Traffic auf Freifunk um
nat64
nat64 ist das Interface mit dem tayga arbeitet.
#NAT64 auto nat64 iface nat64 inet static pre-up tayga --mktun #zuerst das Interface von tayga anlegen lassen pre-up ip link set $IFACE up #das Interface starten address 10.83.252.53 #hier muss die v4 von Freifunk auch mit dran netmask 255.255.255.255 post-up ip addr add 2a0b:yy:xx:6464::1 dev $IFACE #damit PMTU klappt, muss die Adresse auch hier ran #Routen setzen post-up ip route add 192.168.xx.x/24 dev $IFACE tab fff #damit die Rückroute von tayga bekannt ist muss diese in die Tabelle rein, es darf/muss kein proto static verwendet werden, da Babel die Rückroute nicht announcen muss da wir NAT machen post-up ip route add 192.168.xx.x/24 dev $IFACE #die Zeile ist überflüssig oder? post-up ip route add 2a0b:yy:xx:6464::/96 dev $IFACE proto static tab fff #die Route muss per Babel announced werden damit auch von außen erreichbar #Tayga starten post-up tayga --config /usr/local/etc/tayga.conf #tayga mit der entsprechenden config starten #Firewall #alles was von -s kommt und nach -d soll wird erlaubt post-up ip6tables -A FORWARD -s 2a0b:yy::/32 -d 2a0b:yy:xx:6464::/96 -j ACCEPT #icmpv6 erlauben, damit icmp errors ankommen und PMTU funktioniert ip6tables -A FORWARD -p icmpv6 -j ACCEPT #alles andere droppen post-up ip6tables -A FORWARD -d 2a0b:yy:xx:6464::/96 -j DROP
Mit den ip6tables am Ende wird nur noch NAT64 aus dem eigenen Netz erlaubt.
bind9 config
Die bind9 config ist recht übersichtlich. /etc/bind/named.conf.options
options { directory "/var/cache/bind"; forwarders { 10.83.252.11; #ein DNS Server aus dem Freifunknetz damit auch fff.community korrekt beantwortet wird }; auth-nxdomain no; listen-on-v6 { any; }; allow-query { any; }; allow-recursion { 127.0.0.1/8; 2a0b:yy::/32; }; #nur eigenes Subnetz das auflösen erlauben! dns64 2a0b:yy:xx:6464::/96 { #die Adresse wo die v4 reingemappt werden clients { any; }; }; };
Test
Danach sollte auf der VM ein
ping6 2a0b:yy:xx:6464::8.8.8.8
erfolgreich beantwortet werden. Clients im Freifunknetz müssen jetzt nur eine publicv6 haben und als DNS 2a0b:yy:xx:6464::1 eingetragen bekommen und schon benötigen sie keine IPv4 Adresse mehr und können dennoch z.b. github.com oder twitter.com erreichen.
dig AAAA github.com @2a0b:yy:xx:6464::1
sollte mit der gemappten v6 antworten
DHCPv6
Windows 8.1 versteht die RDNSS Option vom radvd nicht. Daher bekommt er keinen DNS Server zugewiesen. EIne Lösung scheint hier DHCPv6 zu sein. Dies ist aktuell noch im Test.
Benötige Programme
- isc-dhcp-server
config file
/etc/dhcp/dhcpd6.conf (kann evtl. noch optimiert werden, sind erst erste Tests und vieles aus default config übernommen)
default-lease-time 2592000; preferred-lifetime 604800; option dhcp-renewal-time 3600; option dhcp-rebinding-time 7200; allow leasequery; option dhcp6.name-servers 2a06:e881:340a:xxxx:1; # DNS Server option dhcp6.domain-search "fff.community"; subnet6 2a06:e881:340a:xxxx::/64 { #Subnetz des Interfaces interface bat10; }
radvd
Folgende Optionen sollten sich im radvd näher angeschaut werden:
- AdvOtherConfigFlag
- AdvManagedFlag