Herald: Hallo und herzlich willkommen auf dem FEM Kanal und zu unserem ersten Talk
heute von margau. Margau hat irgendwann mal angefangen bei Freifunk und ist dann
irgendwann immer professioneller geworden und inzwischen beim C3 Infrastructure Team
angekommen. Kümmert man sich also jetzt genau gerade um die RC3 World und das
ganze was es dahinter gibt. Aus genau dem Grund gibt es heute auch kein Q&A bei dem
Talk, denn der Talk ist aufgezeichnet. Margau ist busy mit dem Betrieb, so. Es
geht um IPv6 und zwar nicht wie sonst immer mit ... v4 zusammen, sondern
standalone. Also quasi das, was der Traum eines jeden Netzwerkers unter 40 Jahren
ist. Er wird ein paar Erfahrungen weitergeben und Tipps, falls wir das auch
alle mal machen wollen, dann... for the English speaking viwers, there will be a
translation. To listen to it, select on the language selection select the first
translated option to hear the english translation. Und jetzt viel Spaß beim Talk
mit Margau. [placeholder remove me in amara]
margau: Ja hallo, ich bin margau. Schön, dass ihr eingeschaltet habt zu meinem Talk
"Legacy IP gibt es nicht mehr, aber kein Netz ist auch keine Lösung" hier beim RC3
2021. Genau. Worum geht es bei meinem Talk heute? Wie betreibe ich ein richtiges Netz
mit IPv6-Focus oder soweit es geht IPv6-Only. Bisschen, meine Erfahrungen.
Welche Probleme habe ich gefunden, welche Lösungen und natürlich auch ein bisschen
Inspiration, was ihr für eure Netze für eure Dienste mitnehmen könnt, damit
vielleicht auch ihr dann in der Lage seid IPv6-Only zu sprechen, wenn ihr es noch
nicht macht. Vorher, bevor wir loslegen aber erst mal ein Disclaimer. In dem Talk
und auch bei meinem Netz geht es um, ich sage mal, echtes Internet. Das heißt, wir
haben einen AS, wir haben IP-space der BGP mit dem Rest des Internets spricht. Das
ganze ist kein Spielzeug! Betrieb eines AS's ist deutlich mehr als einfach nur
irgendwo eine virtuelle Maschine klicken und da einen Linux drauf zu installieren
und einen Webserver hochzuziehen oder so. Also überlegt euch wirklich gut, ob ihr
das könnt, ob ihr die Verantwortung tragen könnt und ja, ob ihr das auch braucht, an
der Stelle. Passt auf, dass ihr wisst was ihr tut. Weil, wenn es erst mal nur ums
Üben und ums Spielen mit BGP, mit Internet, mit Routing geht, gibt z.B. das
den DN42, das ist ein virtuelles Overlay- Netz und das ist dafür sehr gut geeignet.
Aber das sollte man nicht direkt produktiv im Internet tun. Genau, dann nachdem der
Formalkram geklärt is, machen wir mal weiter mit der Terminologie. Ich werde in
dem Talk ein paar Begriffe häufig nutzen, nämlich IP oder richtiges IP meint
natürlich IPv6, das Moderne die 128 Bit Variante und wenn ich von Legacy IP
spreche, meine ich damit IPv4, die alter 32 Bit Variante. Genau. Aber wie hat das
ganze eigentlich angefangen? Irgendwann in 2020 habe ich mir gedacht, so
Infrastruktur betreibe ich eigentlich schon lange genug, mehrere Jahre. Das DN42
und auch bei anderen Möglichkeiten, Routing etc. auch schon einiges an
Erfahrung gesammelt. Es hat sich in ein ganzer Zoo an Diensten angesammelt, der
mal einen ordentlichen Neubau brauchte. Von daher so langsam lohnt sich eigentlich
ein richtiges Netzwerk, oder? Was brauche ich denn für ein richtiges Netzwerk? Ich
brauche erst mal ein Autonomes System. Das kann ich, wenn ich nicht selbst RIPE-
Mitglied werde, von einem Sponsoring LIR bekommen. Ich brauche Konnektivität. Also
irgendwie muss ich ja meine IP Adressen meines Autonomen Systems ins Internet
bringen. Da gibt es virtuelle Maschinen mit IXP, also Internet Exchange Points
Anbindung. Es gibt virtuelle Maschinen mit BGP Upstream. Also auch das ist nicht das
Problem. Zuletzt brauche ich natürlich im Netz noch IP Adressen. Richtiges IP, also
IPv6, auch kein Problem. Gibt es zu Hauf, von RIPE bekommt man /48 PI als Provider
Independent und das ist an einen selbst oder an die Organisation gebunden, aber
nicht an den Provider, der jemandem das bereitstellt. Genau. Also v6 Adressen
haben wir. Legacy IP-Adressen oder auch IPv4 Adressen genannt. Jetzt wird es
langsam interessanter, gibt es nämlich nicht mehr. Wenn man mal auf die Seite der
RIPE guckt, wie die RIPE-Mitglieder auf neue IPv4-Adressen warten, sieht man der
Graph, die Warteliste steigt stetig an. Und ja, vermutlich hat es heute einen
neuen Höchststand wie gestern, wie vorgestern, wie letzte Woche etc. Und auch
der Gebrauchtmarkt, nenne ich es mal, für IPv4-Adressen ist jetzt nicht gerade so
toll, da bezahlt man definitiv einen zweistelligen Betrag in mittlerer Größe
für eine IPv4-Adresse, natürlich auch je nach Präfixgröße etc. Aber IPv4 ist
eigentlich für so ein privates Best Effort Projekt allein aus finanzieller Sicht
schon keine wirkliche Lösung mehr. Was macht man also? Einfach nur IPv6? Weil
IPv6 haben wir ja. Ist kein Problem oder ist kein Problem, das zu bekommen. Machen
wir IPv6 only. Als nächstes habe ich mir überlegt, was soll mein Netz eigentlich
machen? Ich habe dann so eine kleine Liste an Diensten, die ich betreibe, die auch in
dieses Netz dann umziehen sollen. Natürlich ein klassischer Webserver mit
einem Blog dahinter, eine Nextcloud, einen Hedgedoc, über den übrigens gerade diese
Präsentation hier läuft. Mailserver, kommen wir später noch zu und auch noch
das eine oder andere, je nachdem wie gerade Bedarf ist. Aber wenn man sich
diese Liste anguckt, merkt man das nutzen tatsächlich Menschen. Also es ist nicht
nur für mich, um es zu haben, da greifen tatsächlich Menschen drauf zu und wollen
vielleicht das eine oder andere Mal mit diesen Diensten interagieren. Was macht
man jetzt aber, wenn die Nutzer der Dienste nur Legacy IP haben? Wir haben ja
eben gesagt, wir machen ein IPv6 only Netz. Kann man in mehreren Stufen lösen.
Step 1, so mittelmäßig ernst gemeint, Awareness schaffen. Ihr seht hier diese
schönen Banner auf meinem Blog. Falls ihr das nicht lesen könnt, da steht drin: Du
besuchst diese Seite mit einem veralteten IPv4-Internetzugang. Möglicherweise treten
in Zukunft Probleme mit der Erreichbarkeit und Performance auf. Bitte frage deinen
Internetanbieter oder Netzwerk- Administrator nach IPv6-Unterstützung. Was
ist die Idee dahinter? Wenn das genug Leute machen, wirds zu einem Marketing
Problem wenn ein Netz oder ein Provider kein IPv6 kann, also kein richtiges IP
anbieten. Und damit wird sich das Problem lösen, weil dann hoffentlich mehr
richtiges IP anbieten etc. Das ist eine schöne Diskussion für Twitter, wenn ich
ehrlich bin. Wie gesagt, ist nicht so ganz ernst gemeint, aber falls ihr das auch
machen wollt, wie habe ich das Ding gemacht? nginx hat eine Weiche drin. Ob
der Request per richtigem IP oder per Legacy IP kam. Und wenn er herausfindet,
dass der Request per Legacy IP kam, ersetzt er den schließenden Body-Tag mit
diesem Banner und natürlich einem schließenden Body-Tag. Aber in Summe ist
eine nette Spielerei, hilft aber nichts, solange das nicht sehr sehr viele
Webseiten etc. machen. Naja, also Step 1 naja. Brauchen wir also doch Legacy IP
überall? Nein, weil dafür gibt es Step 2, den Layer 4 Proxy. Und da ist die Idee,
dass eine geringe Anzahl an Kisten doch noch eine Legacy IP Adresse bekommt. Bei
mir heißen die Gateways, kann man nennen wie man will. Genau. Und auf diesen Kisten
läuft dann ein nginx und der verteilt quasi die Anfragen an die Legacy IP
Adresse nach Port. Heißt, wenn eine Anfrage an TCP Port 80 kommt, über Legacy
IP weiß nginx, schickt es an an den und den Server mit richtigem IP etc. weiter.
Nachteil ist dann natürlich, man braucht für jeden Dienst der einen auf dem schon
belegten Port was macht, eine neue IP Adresse oder neue Public V4 Adresse, weil
sonst kann man es ja nicht, sondern auseinander sortieren. Heißt natürlich
besonders für http und https, dass ich mir da ein zentrales Reverse Proxy Gateway
gebaut habe, weil ich sonst viel zu viele Gateways brauche, um das auseinander zu
sortieren. Ich habe da auch mal ein Beispiel-Config. Man sieht hier den nginx
stream Block, das ist nicht der standard nginx http Teil, sondern eben auf Layer 4,
also TCP oder UDP. Man spezifiziert dann hier ein upstream DNS-UDP-Backend in dem
Beispiel. Also hier geht es um DNS. Ein Server, in dem Fall v6-only natürlich, mit
einem Port, wo das ganze hingeschickt werden soll und sagt dem nginx dann: Hier
bitte auf dieser IP Adresse UDP und Port, hört, das ist in dem Fall natürlich die
public v4, sollte das sein. Die 10.1.2.3 ist einfach nur ein Example und das ganze
andere, das dann an das entsprechende Backend weiterleitet. Das ganze gibt es
hier drunter noch mal für die TCP Variante, genau. Also, eigentlich auch
kein Hexenwerk, das ganze zu machen. Wie sieht das praktisch aus? Interne Dienste,
die nicht von außen erreichbar sein sollen oder müssen, haben bei mir generell nur
eine Public V6 Adresse. Das heißt, wenn wir beim DNS bleiben, ein hidden Primary
hat nur eine einzige V6 Adresse. Das ist auch die drauf konfigurierte, darunter ist
er erreichbar, aber er brauch ja kein V4, wenn keine Endnutzer von V4, die nur V4
haben, von außen drauf zugreifen müssen. Nehmen wir mal ein Beispiel den Secondary,
der von Endnutzern erreichbar sein soll. Der Hostname und die IP, die die Kiste
selbst hat, ist weiterhin v6 only, wie man hier im oberen Beispiel erkennen kann. Die
Endnutzer kriegen dann aber einen anderen Hostnamen, hier z.B. ns1.example.com. Und
der geht für richtiges IP einmal direkt auf die konfigurierte Adresse. Da hängt
kein Gateway mehr dazwischen etc. Das ist natürlich direkte Ende zu Ende
Kommunikation. Genau. Und die V4 Adresse geht an dieses nginx stream Gateway, was
wir eben gesehen haben, was dann natürlich entsprechend konfiguriert sein muss, dass
es auf Port 53 eingehende Anfragen entsprechend behandelt. Das Thema Wie
sprechen Endnutzer mit den Servern ist jetzt gelöst. Wie sprechen aber jetzt die
Server nach außen? Das Problem ist, manche Endpunkte haben kein richtiges IP. Da gibt
es nur sehr sehr bekannte GIT Webseite, die aktuell noch nicht per IPv6-only
bedienbar ist oder erreichbar ist. Was macht man also? The same procedure as
every time. Wenn man ein Netzwerkproblem hat und insbesondere ein
Adressierungsproblem macht man natürlich NAT. Diesmal nur nicht ganz so schlimm.
Wir machen nicht NAT 44, sondern wir machen NAT 64. Das heißt wir NATen im
Prinzip Adressen zwischen dem IPv6-Adressraum und dem IPv4-Adressraum.
Das ganze will ich jetzt nicht im Detail erklären. Das ist ein eigener Talk. Da
gibt es auch mehr als genug Infos und Literatur dazu, wie dieses NAT 64
eigentlich funktioniert. Zumindest wenn ihr im Telekom-Mobilfunknetz seid, ist die
Chance, dass ihr das unwissentlich schon benutzt relativ groß, weil meines Wissens
macht die das Telekom das per Default oder bietet das per default an. Genau, die
Realisierung bei mir ist: Ich habe diesen Common Präfix, diesen V6 Präfix, wo der
gesamte IPv4 Adressraum drin abgebildet werden kann. Dieser /96 Präfix wird im
internen Netz von den 64-Gateways announced um quasi den Devices die Routen
dahin anzubieten, also per ITP genau. Und wenn eine IPv6-only Kiste jetzt auf eine
IPv4-only Resource im Internet zugreifen will, macht sie eine Anfrage an einen
entsprechend konfigurierten DNS resolver, der genau eine Adresse in diesem Range
zurückgibt. So Resolver gibt es haufenweise, kann man selbst hosten.
Google hat da was, Cloudflare hat da was, das ist auch alles ein gelöstes Problem,
einfach mal DNS 64 resolver googlen, da findet man was. Also sind wir eigentlich
fertig. Wir können von innen nach außen kommunizieren und von außen nach innen.
Gucken wir uns die Übersicht noch mal an. Von erstmal unten haben wir unser großes
IPv6-only-Netzwerk. Bei mir läuft es mit OSPF und IBGP. Wir haben den ganz normalen
Edge-Router, der die Adressen ins Internet routet und umgekehrt. V6 Enduser gehen
direkt über diesen Edge-Router Ende zu Ende zu dem Dienst unten auf der rechten
Seite. Oben sehen wir noch Legacy End User. Der muss den Umweg über unser TCP
UDP Legacy to V6 Proxy nehmen. Das ist die nginx stream Config, die wir eben gesehen
haben. Auf der linken Seite nochmal zusammengefasst das, was ich eben kurz
erklärte, wie Native V6 only Services mit Legacy only Ressourcen kommunizieren,
nämlich über ein Nat64 Gateway, was quasi auch an der Kante des IPv6-only Netzes
steht. Und vorher müssen sie noch einen DNS64-Resolver natürlich fragen, um erst
mal die Adresse zu bekommen. Wäre natürlich zu schön, wenn das ganze out of
the box funktioniert und man nicht den ein oder anderen problematischen Dienst an der
Stelle hätte. Womit hatte ich Probleme? Wie habe ich die gelöst? Mail ist an sich
kompliziert, weil Reverse-DNS etc., das muss alles passen, sonst werden E-Mails
abgelehnt. Gleichzeitig ist E-Mail für mich ein sehr kritischer Dienst. Von da
habe ich einfach von Anfang an gesagt Der lebt nicht IPv6-only, der kriegt eine
eigene V4 und oder läuft sogar ganz außerhalb. An der Stelle noch mal,
überlegt euch gut, ob ihr einen eigenen Mailserver betreiben wollt. Wenn ihr das
noch nicht macht, das ist administrativ nicht ganz einfach, wenn nicht sogar das
Komplizierteste an der ganzen Geschichte hier, einen verfügbaren funktionierenden
Mailserver zu betreiben. Ein weiteres Problem, was ich hatte mit der netten
Software Matrix Synapse, ein Home Server für Matrix, also Instant Messaging. An
sich läuft das Ding IPv6 only. Es gibt da nur eine komische Library, die E-Mails
verschickt und die kann kein Happy Eyeballs. Das heißt, wenn die versucht
sich zu diesem SMTP Server, der eine V4 oder V6 Adresse hat zu connecten, ähm aber
den über Legacy nicht erreichen kann, weil eine V6-only Kiste natürlich keine
default route für eine legacy IP-Adresse hat, hört die einfach auf zu
funktionieren. Also es gibt ein Timeout, sie kann es nicht erreichen. Habe ich noch
nicht gelöst. Gibt ein GitHub issue dazu, müsste man wahrscheinlich mal etwas viel
Zeit rein investieren und dann ist auch das Thema gefixt. Aber aktuell ist es noch
kaputt. Docker ist auch so ein Thema. Wenn man das entsprechend konfiguriert und die
Zeit reinsteckt, läuft es dann per V6, per Default nicht so wirklich, ist eher
anstrengend, sich um Docker in V6-only zu kümmern, geht aber wenn man will. Weniger
toll ist das ganze mit Gitlab Runnern. Ich habe mal versucht ein GitLab Run in dieses
V6-only Netz zu stellen. Die Kommunikation zwischen Containern klappte dann irgendwie
nicht, wenn man Docker in Docker gemacht hat und dann noch irgendwie docker Service
containern brauchte. Eventuell muss ich das Ding auf V4 only zurückbauen und dann
irgendwie so eine CLAT da hinstellen. Also ohne jetzt ins Detail zu gehen. Alles ganz
schrecklich. Ist aktuell weiterhin kaputt. Noch so ein Thema, wenn ich per https ins
Heimnetz will, aber das eben nicht über einen Dyn-DNS machen will, sondern über
einen direkt angebundenen, über VPN angebundenen Jumphost, nenne ich es mal,
ist das ein bisschen kompliziert, je nachdem, wie man sein Netz aufbaut. Mein
OpenVPN-Server steht im IPv6-only Teil. Das funktioniert auch. Kam trotzdem nicht
drumrum, ein Reverse Proxy Channing, also quasi ein NAT für HTTP zu bauen. Ist nicht
schön, ginge bestimmt anders. Anders wäre das halt deutlich zeitaufwändiger. Dann
kommen wir mal zum letzten wichtigen Teil: Konnektivität, Routing und Administration.
Das ist jetzt nicht mehr so stark auf IPv6-only bezogen. Eher generell. Ich habe
zwei Standorte mit BGP-Konnektivität nach außen, eine IXP-VM in Frankfurt und einmal
eine VM nur mit Transit. Transit für V6 ist relativ günstig. Gratis v6-Transit ist
zumindest für kleine Projekte auch verfügbar. Und dann habe ich noch weitere
Projekte, weitere Standorte mit billigem Compute. Also die ganze Rechenleistung
steht, wo ich aber leider kein BGP habe, zum Beispiel Hetzner. Heißt ich muss
irgendwie zwischen diesen beiden Standorten kommunizieren können. Da musste
ich mir, weil ich nichts besseres habe, einen Wireguard, also ein VPN-Overlay
bauen. WAN-intern, läuft da getrennt über Policy Based Routing. iprule is your
friend. VRFs wären besser, um quasi die Sicht des eigenen Netzes und die Sicht des
Hetzner-Netzes zu trennen. Es gibt da auf der wireguard-Mailingliste eine
Diskussion, die ist aktuell aber leider eher eingeschlafen. Also wireguard kann
dieses VRF noch nicht. Mit iprule kriegt man das hin, das ist auch nicht sonderlich
großartig und es frisst natürlich MTU. Also Wireguard. Ihr wollt, wenn ihr so was
macht, strikte Firewall-Regeln haben um Leaks zu unterbinden. Das heißt ihr wollt
nicht versehentlich aus eurem internen Netz Pakete mit eurer source IP an das
Hetzner Default-Gateway senden. Das wäre uncool. Weil Hetzner weiß ja nicht, oder
kennt ja euer AS nicht oder euer NAT nicht. Für Hetzer ist das ja ein externes
Netz, weil ihr da kein BGP upstream habt. Also da wirklich aufpassen, was ihr da
baut. Vorher verstehen und dann bauen. Mein Routing mache ich mit bird2 unter
Linux, OSPF als interior gateway- Protokoll, IBGP zwischen allen größeren
Standorten. Ist im wesentlichen Geschmackssache, wie man das baut. Da gibt
es auch verschiedenste Möglichkeiten. Weiterhin das Thema Administration.
Benutzt Konfigurationsmanagement. Ich benutz Saltstack mit Ansible oder anderen
Tools geht das garantiert auch. Nur das wächst so schnell an, da kriegt ihr dann
in die BGP-Filter, in die BGP- Konfiguration, in die Firewall Regeln
keine Konsistenz mehr rein, wenn ihr das nicht, ich sage mal systematisch ausrollt
und per config management sicherstellt, dass das System stabil und konsistent
läuft. Kommen wir so langsam zum Ende. Was wäre noch cool für das Projekt? Weg von
den IXP-VMs, hin zum echten Blech, was da steht und Pakete routet oder auch Dienste
hostet. Ist natürlich aufwendiger und teurer, das mit echtem Blech zu machen.
Ist eine Option für die Zukunft. Und echter Layer 2 Transport statt Overlay
wäre natürlich auch cool. Frisst mir dann nicht mehr die MTU weg und so weiter. Ist
aber gerade was Standorte, Konnektivität etc. betrifft nicht ganz trivial und auch
nicht ganz billig. Sollte man definitiv machen, wenn das Netz produktiv wird,
solange es irgendwie ein Best Effort Bastelnetz ist oder Privat-Netz ist, ist
das so eigentlich in Ordnung. Fazit: Würde ich es noch mal machen? Definitiv, v6-only
mit wenigen Legacy IP-Adressen auf den Edges ist durchaus sinnvoll machbar.
Kostentechnisch ist es eh schon interessant. Gerade Hetzner hat jetzt vor
kurzem ja angekündigt, dass v4 zukünftig extra kosten wird oder es ohne V4 billiger
wird. Also ja, das mache ich definitiv weiter so und würde das auch in neuen
Projekten so machen, dass ich V4 nur noch auf den Edges habe, auch im privaten
Umfeld. Ihr habt ja gesehen, dass ist nicht sonderlich kompliziert. Der Aufbau
mit diesen IXP-VMs und Tunneln dazwischen ist okay für private best effort services.
Ihr hört schon, ich bin nicht so ganz überzeugt. Also es ist nicht für wirklich
produktive Produktiv-Netze geeignet. Also nichts, was Geld verdient etc. Dafür Layer
2 Transport, ordentliche Peerings, ordentlicher Transit, ordentliche
Hardware. Aber das ist ja hier an der Stelle auch nicht Ziel des Ganzen. Und
damit bin ich am Ende. Vielen Dank fürs Einschalten, fürs Zuhören. Und wenn ihr
Fragen habt, sendet gerne eine Mail an rc3 at ipv6.church.
Herald: Und dann sind wir wieder zurück hier. Vielen Dank an margau für den Talk.
Es gibt leider kein Q&A, weil margau mit der C3 Infrastruktur beschäftigt ist. Aber
wie ihr gesehen habt, könnt ihr ihr eine Mail schreiben an die gerade eingeblendete
Email-Adresse. Hier auf dem FEM-Channel geht es jetzt gleich weiter um 19 Uhr mit
der nächsten Herald News Show und um 20:15 Uhr mit votti zu NetBox als Datenquelle
für Netzwerkinfrastruktur. Bis dahin.
Untertitel erstellt von c3subtitles.de im Jahr 2023. Mach mit und hilf uns!