OpenBSD Tekeom IPv6

schorsch_76

FreeBSD Fanboy
Siehe hier
 

Anhänge

  • Screenshot_20210515_222506.jpg
    Screenshot_20210515_222506.jpg
    533,6 KB · Aufrufe: 89

jmt

Well-Known Member
Ja, aber ich benutze zur Einwahl keine Fritzbox sondern OpenBSD. Deshalb schreibe ich das auch hier. :)
 

TCM

Well-Known Member
Ja, aber ich benutze zur Einwahl keine Fritzbox sondern OpenBSD. Deshalb schreibe ich das auch hier. :)
Du willst auch jede Schweinerei genau wissen. ;)

Dafür läuft ein dhcp6c im Debug-Modus, der nichts weiter tut, als DHCPv6-Requests zu schicken und die Antwort zu loggen. An der Interface-Konfig ändert der nichts. Das Log wird dann von einem Script geparst. Das sucht nach update_prefix: create a prefix ...::/56 pltime=1800, vltime=14400. Warum das so ist, kann ich nicht mehr genau sagen. Der dhcp6c hat anscheinend noch zu viel Schnickschnack gemacht oder hatte kein richtiges Hook-System, irgendwie sowas, weshalb er ein reiner Informationslieferant ist.

Code:
PROG=$(basename ${0})

logfile=/var/log/dhcp6c.log
lockfile=/var/run/${PROG}.lock
oldnet=


/bin/sh -us <<-EOF &
        while sleep 5; do
                [ -f /var/run/dhcp6c.pid ] && kill -9 \$(cat /var/run/dhcp6c.pid)
                /usr/local/sbin/dhcp6c -Df pppoe0 >${logfile} 2>&1
        done
EOF

tail -f ${logfile} \
| egrep --line-buffered -o 'update_prefix: create a prefix [[:xdigit:]:]+/56 pltime=[[:digit:]]+, vltime=[[:digit:]]+$' \
| egrep --line-buffered -o '[[:xdigit:]:]+/56' \
| while read net; do
        shlock -f ${lockfile}

        logger -t ${PROG} "detected DHCPv6 delegation: ${net}"

        [ "${net}" = "${oldnet}" ] && continue

        oldnet=${net}

        logger -t ${PROG} "handling new DHCPv6 delegation: ${net}"

        /usr/local/sbin/nat6.sh ${net}
        /usr/local/sbin/dyndns.sh -6 ${net}

        rm -f -- ${lockfile}
done
 

jmt

Well-Known Member
Du willst auch jede Schweinerei genau wissen. ;)
Natürlich, bist ins letzte dreckige Detail :)

Ein großes Problem ist für mich die Zuordnung der Clients auf die verschiedenen Bereiche. Wie weist Du denn den Rechnern eine IP zu. Insbesondere wie stellst Du sicher, welche Clients in das Mapping-Netz kommen und welche nur "raus" dürfen. Machst Du das mit verschiedenen VLANs oder benutzt Du intern DHCP? Vergibst Du das Mapping-Netzt statisch?

Ich würde es wohl über verschiedene VLANs lösen. Aber dann müsste das intnet nicht Teil des sitenet sein. :confused:
 

TCM

Well-Known Member
Hinter dem externen Router kommt erstmal ein Transfer-Netz, wo noch ein paar andere Router stehen und OSPF machen, um u.a. den IPv6-Tunnel anzubinden. Ebenfalls da drin sind dann die internen Firewalls, die einfach statisch Netze auf einzelnen VLANs haben, die sie dann per OSPF announcen. Das kann man auch mit statischen Routen machen. Ich wollte nur mal OSPF lernen. Intern fliegt quasi beliebig alles aus fc00::/7 und dem statischen /48 rum.

Die Firewalls haben dann alle Nutz-VLANs angebunden und verteilen per rad(8) Adressen. Die Zuordnung VLAN <-> /64 ist natürlich statisch und hängt davon ab, ob und wie das Netz Internet haben soll.
 

jmt

Well-Known Member
Ok, dann ist mein Ansatz ähnlich. Ich verwende jetzt intern ein fd00::/8 Netz ( fc00::/8 soll man ja nicht nehmen...:zitter:) mit NAT und habe das von außen erreichbare Netz auf ein eigenes VLAN gerouted. Das klappt dann auch direkt mit dhcpcd. Zusätzlich verwende ich noch NAT64 mit unbound als DNS64 Router. Fallstrick dabei war nur, dass man dann die eigenen DNS-Einträge über einen extra DNS-Server verwalten sollte, da unbound sonst keine DNS64 Umsetzung macht. Aber da brauche ich nach meiner Umstellung des Heimnetzes auf IPv6 wahrscheinlich nicht mehr.
 

PMc

Well-Known Member
So, ich nehm grad anlauf um mir dieses Thema auch mal vorzunehmen.
Glücklicherweise verwende ich momentan NAT auch bei IPv6. Das funktioniert gut und ich kann den Traffic zentral filtern.
Ich dachte, es gibt bei IPv6 kein NAT? Ich hab jedenfalls verzweifelt danach gesucht und keins gefunden.

Und zu der These, man solle auch gar keins verwenden: grau, liebe Freunde, ist alle Theorie...
Die Praxis: 1. ich hab ungefähr 20 Subnetze. Soweit ich bisher verstanden hab, müßte man sich mit router advertisments komplett da durchhangeln, wenn der Prefix sich ändern. Das müßte man dann überall konfiguriert haben, und Ich glaub nicht daß ich das mag.
2. diese Subnetze sind in security zones gegliedert, und dazwischen sind firewalls. Die firewalls müssten sich auch umkonfigurieren, wenn der Prefix sich ändert - und die dynamischen rules sind dann sowieso beim Teufel.

und 3. ein paar von meinen Nodes laufen mit echten statischen IPs. Die hab ich nicht vom Provider, sondern die werden aus der Cloud hergetunnelt - von da wo halt welche übrig sind. Das feine dabei ist: diese Tunnels merken es gar nicht, wenn die dynamische IP des Uplink sich ändert. Die laufen da einfach drüber weg, denn für die ändert sich dabei nichts.
Und genau das geht nur mit NAT. (Der Fehler ist nicht der NAT, sondern die dynamischen Adressen, für die es es bei IPv6 keinen Grund gibt - aber das sehen die Provider offenbar anders.)

Was ich dann beim suchen gefunden hab, ist der letzte Absatz im ipfw Manual: IPv6-to-IPv6 NETWORK PREFIX TRANSLATION (NPTv6) /RFC6296. Wenn ich das richtig verstehe, dann ist das etwa das, was die ganzen Probleme lösen könnte. Man kann dann weiterhin private Adressen verwenden, die nur nach außen in dynamische ersetzt werden.
 

CommanderZed

OpenBSD User
Teammitglied
So, ich nehm grad anlauf um mir dieses Thema auch mal vorzunehmen.

Ich dachte, es gibt bei IPv6 kein NAT? Ich hab jedenfalls verzweifelt danach gesucht und keins gefunden.

Und zu der These, man solle auch gar keins verwenden: grau, liebe Freunde, ist alle Theorie...
Die Praxis: 1. ich hab ungefähr 20 Subnetze. Soweit ich bisher verstanden hab, müßte man sich mit router advertisments komplett da durchhangeln, wenn der Prefix sich ändern. Das müßte man dann überall konfiguriert haben, und Ich glaub nicht daß ich das mag.

Theoretisch kannst du alternativ das einzelne netz das du bekommst auch splitten, das ist glaub ich auch gängige praxis.

2. diese Subnetze sind in security zones gegliedert, und dazwischen sind firewalls. Die firewalls müssten sich auch umkonfigurieren, wenn der Prefix sich ändert - und die dynamischen rules sind dann sowieso beim Teufel.

Vill. muss man hier einfach feststellen das das gebastel mit ipv4 an consumer-grade anschlüssen mit ipv6 einfach noch schwieriger wird.

Eine Lösung wäre es ggf. die komplexität zu reduzieren, also für dich auf den prüfstand zu stellen ob das was du machts generell so sinnvoll ist oder ob man das vereinfachen kann / sollte ;)

Wenn das nicht möglich ist, könnte nat evtl. wirklich irgendwann die einfachere lösung sein - oder man muss ggf. den (oft ja auch nur 30,40 eur) teureren Businessanschluss mit festen Addressen halt doch bezahlen.

Soweit ich


interpretiere kannst du einfach anstelle von ipv4 ipv6 nehmen und das ding macht nat, aber ob ich das ganz 100% richtig interpretiere weiß ich nicht.

und 3. ein paar von meinen Nodes laufen mit echten statischen IPs. Die hab ich nicht vom Provider, sondern die werden aus der Cloud hergetunnelt - von da wo halt welche übrig sind. Das feine dabei ist: diese Tunnels merken es gar nicht, wenn die dynamische IP des Uplink sich ändert. Die laufen da einfach drüber weg, denn für die ändert sich dabei nichts.
Und genau das geht nur mit NAT. (Der Fehler ist nicht der NAT, sondern die dynamischen Adressen, für die es es bei IPv6 keinen Grund gibt - aber das sehen die Provider offenbar anders.)

Was ich dann beim suchen gefunden hab, ist der letzte Absatz im ipfw Manual: IPv6-to-IPv6 NETWORK PREFIX TRANSLATION (NPTv6) /RFC6296. Wenn ich das richtig verstehe, dann ist das etwa das, was die ganzen Probleme lösen könnte. Man kann dann weiterhin private Adressen verwenden, die nur nach außen in dynamische ersetzt werden.

Warum machst du nicht deine Cloud-Tunnel-Lösung mit festen ipv6 addressen genauso mit ipv6? Oder nutzt halt Dyndns mit all seinen nachteilen.
 

PMc

Well-Known Member
Theoretisch kannst du alternativ das einzelne netz das du bekommst auch splitten, das ist glaub ich auch gängige praxis.
Das scheint zu gehen:
Bash:
$ ifconfig tun0
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1492
        options=80000<LINKSTATE>
        inet 91.4.226.97 --> 62.155.246.183 netmask 0xffffffff
        inet6 2003:e7:17ff:4a2f::1 prefixlen 64 autoconf
        inet6 fe80::1%tun0 prefixlen 64 scopeid 0x4
        groups: tun
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
        Opened by PID 20352
auto_linklocal abschalten, manuell eine linklocal Adresse konfigurieren (hier fe80::1%tun0), und die zugewiesene /64 nutzt dann denselben Suffix. Die ünrigen 18 Trillionen kann man dann wohl beliebig verteilen.
Allerdings löst das hier noch kein Problem, weil die sich ja auch bei jeder neuen Einwahl ändern.
Wenn das nicht möglich ist, könnte nat evtl. wirklich irgendwann die einfachere lösung sein - oder man muss ggf. den (oft ja auch nur 30,40 eur) teureren Businessanschluss mit festen Addressen halt doch bezahlen.
Genau so weit bin ich auch mit meinen Überlegungen. :)
Dynamische IPs mögen für private selbstkonfigurierende IoT-Häuser funktionieren (und da ein bischen mehr "privacy" liefern), aber für alles was server-grade ist, sind sie eher schmerzhaft.

Soweit ich


interpretiere kannst du einfach anstelle von ipv4 ipv6 nehmen und das ding macht nat, aber ob ich das ganz 100% richtig interpretiere weiß ich nicht.
Da lese ich nichts substanzielles über ipv6, außer dass es angeblich geht. Müßte man mal genauer anschauen. In Linux geht es angeblich auch, also hat wohl mal jemand einen normalen NAT (oder die libalias) für IPv6 umgeschrieben.

Warum machst du nicht deine Cloud-Tunnel-Lösung mit festen ipv6 addressen genauso mit ipv6? Oder nutzt halt Dyndns mit all seinen nachteilen.

Die statischen IP sind ja nicht das Problem, sondern der hiesige Tunnel-Endpunkt. Der ist momentan eine statische private Adresse wie 192.168.37.5, und die ändert sich nie. Der andere Endpunkt ist die statische routable Adresse des Cloud-Servers, die sich auch nicht ändert. Wenn sich meine dynamische Telekom-IP ändert, dann übersetzt der NAT einfach die 192.168.37.5 in die neue dynamische IP, und dann kommen die Päckchen oben halt mit einem anderen Absender an - den UDP-Tunnel juckt das nicht, solange der Inhalt sich entschlüsseln läßt (option --float in openvpn ist serverseitig default).
Wenn sich nun aber die client-seitige Endpunkt-IP ändert, dann muss der Client den Socket neu aufmachen.

Das ganze ist inzwischen eher akademisch, weil die Telekom von ihrer Seite aus die IP nicht mehr alle 24 Stunden ändert, wegen VoIP. Und ich überlege, ob ich das Tunnel-Konstrukt überhaupt so lasse oder lieber Tunnels von HurricaneElectric nehme, die über IPv4 laufen. Wahrscheinlich erstmal "von allem ein bischen" um zu schauen wie es geht. Und dann kann man mit IPv6 offenbar auch einige neue Schweinereien machen...
 

jmt

Well-Known Member
NAT mit IPv6 funktioniert zumindest in OpenBSD analog zu IPv4. Einfach die entsprechende PF-Regel einfügen und fertig. Ich habe so mein internes Netz Komplettlösung der Telekom entkoppelt.
 

PMc

Well-Known Member
So, ich kann nun, nach einiger Anstrengung, einen Erfolg berichten.
Vill. muss man hier einfach feststellen das das gebastel mit ipv4 an consumer-grade anschlüssen mit ipv6 einfach noch schwieriger wird.
Jo, es ist schwieriger, aber machbar.

Meine Tunnels sind hierbei erstmal aussen vor geblieben, für die werde ich erst noch was überlegen (vielleicht fd00:: mit rfc6296, vielleicht auch was ganz anderes).

Sondern jetzt war erstmal die Fragestellung, ob man eine komplexe Site mit ausgeprägtem Subnetting verläßlich mit dynamisch vergebenen global-unicast Adressen betreiben kann, und ob das mit vertretbarem Aufwand geht.

Und die Antwort ist: ja, in 16 Sekunden.
(Das meint: es dauert 16 Sekunden, um eine verschachtelte Hierarchie von Subnetzen mit beliebig vielen Clients automatisch auf eine neue Adresse umzuwerfen, nachdem der Uplink disconnectet hat.)

Fürs erste gibt es hier den authentischen Zeitverlauf. Da sind drei Parteien im Spiel: der Router der den Uplink macht ("outbound"), der Router an dem der untersuchte Client hängt ("backbone") und der Client selber.
Details werden folgen, falls das jemand nachbauen will.
 
Oben