OpenBSD Tekeom IPv6
- Ersteller jmt
- Erstellt am
schorsch_76
FreeBSD Fanboy
Das ist dhcpv6 Prefix Delegation. Mit OpenBSD hab ich keine Erfahrung aber das scheint es abzudecken.
Native IPv6 Router with OpenBSD - lipidity
A sequel to the OpenBSD PF FAQ; adds native dual-stack IPv6 support.
lipidity.com
Du willst auch jede Schweinerei genau wissen.Ja, aber ich benutze zur Einwahl keine Fritzbox sondern OpenBSD. Deshalb schreibe ich das auch hier.
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
Natürlich, bist ins letzte dreckige DetailDu willst auch jede Schweinerei genau wissen.
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.
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.
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...
) 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.
) 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.So, ich nehm grad anlauf um mir dieses Thema auch mal vorzunehmen.
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.
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.
Theoretisch kannst du alternativ das einzelne netz das du bekommst auch splitten, das ist glaub ich auch gängige praxis.
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.
Warum machst du nicht deine Cloud-Tunnel-Lösung mit festen ipv6 addressen genauso mit ipv6? Oder nutzt halt Dyndns mit all seinen nachteilen.
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 20352Allerdings löst das hier noch kein Problem, weil die sich ja auch bei jeder neuen Einwahl ändern.
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.
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.
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...
So, ich kann nun, nach einiger Anstrengung, einen Erfolg berichten.
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.
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.