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!