NAT64: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
Zeile 8: Zeile 8:
** Android 7.1.1 macht 464xlat und es funktionieren auch direkte IPv4 Aufrufe. Das Handy stört sich überhaupt nicht daran, das es kein v4 gibt es funktioniert total normal
** Android 7.1.1 macht 464xlat und es funktionieren auch direkte IPv4 Aufrufe. Das Handy stört sich überhaupt nicht daran, das es kein v4 gibt es funktioniert total normal
** Windows 8.1 kommt anscheinend gar nicht wirklich mit klar. WLAN Manager zeigt "begrenzt" an und kein Internet, weder per v4 noch per v6 möglich.
** Windows 8.1 kommt anscheinend gar nicht wirklich mit klar. WLAN Manager zeigt "begrenzt" an und kein Internet, weder per v4 noch per v6 möglich.
** Debian 9 wartet der WLAN Manager etwa 30 Sekunden auf eine IPv4 und dreht sich solang im Kreis. Das Netz funktioniert aber ab erhalt der IPv6 sofort. Nach 30 Sekunden ist auch der WLAN Manager zufrieden und gibt auf mit dem warten auf eine IPv4.
** Debian 9 wartet der WLAN Manager etwa 30 Sekunden auf eine IPv4 und dreht sich solang im Kreis. Das Netz funktioniert aber ab erhalt der IPv6 sofort. Nach etwa 30 Sekunden ist auch der WLAN Manager zufrieden und gibt auf mit dem warten auf eine IPv4.


* Wenn man funktionierendes v4 mit gibt:
* Wenn man funktionierendes v4 mit gibt:

Version vom 31. März 2018, 12:04 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

  • Wenn man kein v4 mitgibt:
    • Android 7.1.1 macht 464xlat und es funktionieren auch direkte IPv4 Aufrufe. Das Handy stört sich überhaupt nicht daran, das es kein v4 gibt es funktioniert total normal
    • Windows 8.1 kommt anscheinend gar nicht wirklich mit klar. WLAN Manager zeigt "begrenzt" an und kein Internet, weder per v4 noch per v6 möglich.
    • Debian 9 wartet der WLAN Manager etwa 30 Sekunden auf eine IPv4 und dreht sich solang im Kreis. Das Netz funktioniert aber ab erhalt der IPv6 sofort. Nach etwa 30 Sekunden ist auch der WLAN Manager zufrieden und gibt auf mit dem warten auf eine IPv4.
  • Wenn man funktionierendes v4 mit gibt:
    • Android 7.1.1 macht kein 464xlat mehr. Dies ist auch logisch da das Handy durch das funktionierende IPv4 nichts vom NAT/DNS64 weiß.

Allgemein müssen noch mehr Beobachtungen gesammelt werden (IOS, ältere Android, Windows, etc.)

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

Benötigte Programme

Ich hab mit folgenden Programmen gearbeitet und sie hier beschrieben, es gibt bestimmt alternativen:

  • bind9
  • tayga

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)

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
post-up ip6tables -A FORWARD -s 2a0b:yy::/32 -d 2a0b:yy:xx:6464::/96 -j ACCEPT #alles was von -s kommt und nach -d soll wird erlaubt
post-up ip6tables -A FORWARD -d 2a0b:yy:xx:6464::/96 -j DROP #alles weitere was nach -d soll wird geblockt

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