WEBVTT

00:00:00.000 --> 00:00:03.630
Herald: Hallo und herzlich willkommen auf
dem FEM Kanal und zu unserem ersten Talk

00:00:03.630 --> 00:00:08.880
heute von margau. Margau hat irgendwann
mal angefangen bei Freifunk und ist dann

00:00:08.880 --> 00:00:13.170
irgendwann immer professioneller geworden
und inzwischen beim C3 Infrastructure Team

00:00:13.170 --> 00:00:18.270
angekommen. Kümmert man sich also jetzt
genau gerade um die RC3 World und das

00:00:18.270 --> 00:00:22.260
ganze was es dahinter gibt. Aus genau dem
Grund gibt es heute auch kein Q&A bei dem

00:00:22.260 --> 00:00:28.380
Talk, denn der Talk ist aufgezeichnet.
Margau ist busy mit dem Betrieb, so. Es

00:00:28.380 --> 00:00:36.060
geht um IPv6 und zwar nicht wie sonst
immer mit ... v4 zusammen, sondern

00:00:36.060 --> 00:00:41.790
standalone. Also quasi das, was der Traum
eines jeden Netzwerkers unter 40 Jahren

00:00:41.790 --> 00:00:48.330
ist. Er wird ein paar Erfahrungen
weitergeben und Tipps, falls wir das auch

00:00:48.330 --> 00:00:51.450
alle mal machen wollen, dann... for the
English speaking viwers, there will be a

00:00:51.450 --> 00:01:00.420
translation. To listen to it, select on
the language selection select the first

00:01:00.420 --> 00:01:05.487
translated option to hear the english
translation. Und jetzt viel Spaß beim Talk

00:01:05.487 --> 00:01:08.819
mit Margau.
[placeholder remove me in amara]

00:01:08.819 --> 00:01:14.468
margau: Ja hallo, ich bin margau. Schön,
dass ihr eingeschaltet habt zu meinem Talk

00:01:14.468 --> 00:01:19.815
"Legacy IP gibt es nicht mehr, aber kein
Netz ist auch keine Lösung" hier beim RC3

00:01:19.815 --> 00:01:26.841
2021. Genau. Worum geht es bei meinem Talk
heute? Wie betreibe ich ein richtiges Netz

00:01:26.841 --> 00:01:32.012
mit IPv6-Focus oder soweit es geht
IPv6-Only. Bisschen, meine Erfahrungen.

00:01:32.012 --> 00:01:37.896
Welche Probleme habe ich gefunden, welche
Lösungen und natürlich auch ein bisschen

00:01:37.896 --> 00:01:42.356
Inspiration, was ihr für eure Netze für
eure Dienste mitnehmen könnt, damit

00:01:42.356 --> 00:01:46.905
vielleicht auch ihr dann in der Lage seid
IPv6-Only zu sprechen, wenn ihr es noch

00:01:46.905 --> 00:01:52.323
nicht macht. Vorher, bevor wir loslegen
aber erst mal ein Disclaimer. In dem Talk

00:01:52.323 --> 00:01:57.480
und auch bei meinem Netz geht es um, ich
sage mal, echtes Internet. Das heißt, wir

00:01:57.480 --> 00:02:03.120
haben einen AS, wir haben IP-space der BGP
mit dem Rest des Internets spricht. Das

00:02:03.120 --> 00:02:08.154
ganze ist kein Spielzeug! Betrieb eines
AS's ist deutlich mehr als einfach nur

00:02:08.154 --> 00:02:12.051
irgendwo eine virtuelle Maschine klicken
und da einen Linux drauf zu installieren

00:02:12.051 --> 00:02:15.901
und einen Webserver hochzuziehen oder so.
Also überlegt euch wirklich gut, ob ihr

00:02:15.901 --> 00:02:21.735
das könnt, ob ihr die Verantwortung tragen
könnt und ja, ob ihr das auch braucht, an

00:02:21.735 --> 00:02:28.863
der Stelle. Passt auf, dass ihr wisst was
ihr tut. Weil, wenn es erst mal nur ums

00:02:28.863 --> 00:02:33.885
Üben und ums Spielen mit BGP, mit
Internet, mit Routing geht, gibt z.B. das

00:02:33.885 --> 00:02:38.534
den DN42, das ist ein virtuelles Overlay-
Netz und das ist dafür sehr gut geeignet.

00:02:38.534 --> 00:02:43.719
Aber das sollte man nicht direkt produktiv
im Internet tun. Genau, dann nachdem der

00:02:43.719 --> 00:02:49.410
Formalkram geklärt is, machen wir mal
weiter mit der Terminologie. Ich werde in

00:02:49.410 --> 00:02:56.101
dem Talk ein paar Begriffe häufig nutzen,
nämlich IP oder richtiges IP meint

00:02:56.101 --> 00:03:03.014
natürlich IPv6, das Moderne die 128 Bit
Variante und wenn ich von Legacy IP

00:03:03.014 --> 00:03:09.287
spreche, meine ich damit IPv4, die alter
32 Bit Variante. Genau. Aber wie hat das

00:03:09.287 --> 00:03:14.215
ganze eigentlich angefangen? Irgendwann in
2020 habe ich mir gedacht, so

00:03:14.215 --> 00:03:20.203
Infrastruktur betreibe ich eigentlich
schon lange genug, mehrere Jahre. Das DN42

00:03:20.203 --> 00:03:25.677
und auch bei anderen Möglichkeiten,
Routing etc. auch schon einiges an

00:03:25.677 --> 00:03:30.930
Erfahrung gesammelt. Es hat sich in ein
ganzer Zoo an Diensten angesammelt, der

00:03:30.930 --> 00:03:36.700
mal einen ordentlichen Neubau brauchte.
Von daher so langsam lohnt sich eigentlich

00:03:36.700 --> 00:03:42.141
ein richtiges Netzwerk, oder? Was brauche
ich denn für ein richtiges Netzwerk? Ich

00:03:42.141 --> 00:03:46.115
brauche erst mal ein Autonomes System. Das
kann ich, wenn ich nicht selbst RIPE-

00:03:46.115 --> 00:03:51.137
Mitglied werde, von einem Sponsoring LIR
bekommen. Ich brauche Konnektivität. Also

00:03:51.137 --> 00:03:56.881
irgendwie muss ich ja meine IP Adressen
meines Autonomen Systems ins Internet

00:03:56.881 --> 00:04:02.610
bringen. Da gibt es virtuelle Maschinen
mit IXP, also Internet Exchange Points

00:04:02.610 --> 00:04:08.505
Anbindung. Es gibt virtuelle Maschinen mit
BGP Upstream. Also auch das ist nicht das

00:04:08.505 --> 00:04:14.100
Problem. Zuletzt brauche ich natürlich im
Netz noch IP Adressen. Richtiges IP, also

00:04:14.100 --> 00:04:21.547
IPv6, auch kein Problem. Gibt es zu Hauf,
von RIPE bekommt man /48 PI als Provider

00:04:21.547 --> 00:04:29.210
Independent und das ist an einen selbst
oder an die Organisation gebunden, aber

00:04:29.210 --> 00:04:36.464
nicht an den Provider, der jemandem das
bereitstellt. Genau. Also v6 Adressen

00:04:36.464 --> 00:04:42.759
haben wir. Legacy IP-Adressen oder auch
IPv4 Adressen genannt. Jetzt wird es

00:04:42.759 --> 00:04:47.436
langsam interessanter, gibt es nämlich
nicht mehr. Wenn man mal auf die Seite der

00:04:47.436 --> 00:04:52.873
RIPE guckt, wie die RIPE-Mitglieder auf
neue IPv4-Adressen warten, sieht man der

00:04:52.873 --> 00:04:57.866
Graph, die Warteliste steigt stetig an.
Und ja, vermutlich hat es heute einen

00:04:57.866 --> 00:05:02.300
neuen Höchststand wie gestern, wie
vorgestern, wie letzte Woche etc. Und auch

00:05:02.300 --> 00:05:07.784
der Gebrauchtmarkt, nenne ich es mal, für
IPv4-Adressen ist jetzt nicht gerade so

00:05:07.784 --> 00:05:15.022
toll, da bezahlt man definitiv einen
zweistelligen Betrag in mittlerer Größe

00:05:15.022 --> 00:05:22.162
für eine IPv4-Adresse, natürlich auch je
nach Präfixgröße etc. Aber IPv4 ist

00:05:22.162 --> 00:05:27.558
eigentlich für so ein privates Best Effort
Projekt allein aus finanzieller Sicht

00:05:27.558 --> 00:05:33.848
schon keine wirkliche Lösung mehr. Was
macht man also? Einfach nur IPv6? Weil

00:05:33.848 --> 00:05:39.710
IPv6 haben wir ja. Ist kein Problem oder
ist kein Problem, das zu bekommen. Machen

00:05:39.710 --> 00:05:44.360
wir IPv6 only. Als nächstes habe ich mir
überlegt, was soll mein Netz eigentlich

00:05:44.360 --> 00:05:50.000
machen? Ich habe dann so eine kleine Liste
an Diensten, die ich betreibe, die auch in

00:05:50.000 --> 00:05:53.510
dieses Netz dann umziehen sollen.
Natürlich ein klassischer Webserver mit

00:05:53.510 --> 00:05:58.880
einem Blog dahinter, eine Nextcloud, einen
Hedgedoc, über den übrigens gerade diese

00:05:58.880 --> 00:06:05.990
Präsentation hier läuft. Mailserver,
kommen wir später noch zu und auch noch

00:06:05.990 --> 00:06:09.020
das eine oder andere, je nachdem wie
gerade Bedarf ist. Aber wenn man sich

00:06:09.020 --> 00:06:14.120
diese Liste anguckt, merkt man das nutzen
tatsächlich Menschen. Also es ist nicht

00:06:14.120 --> 00:06:19.070
nur für mich, um es zu haben, da greifen
tatsächlich Menschen drauf zu und wollen

00:06:19.070 --> 00:06:23.780
vielleicht das eine oder andere Mal mit
diesen Diensten interagieren. Was macht

00:06:23.780 --> 00:06:29.150
man jetzt aber, wenn die Nutzer der
Dienste nur Legacy IP haben? Wir haben ja

00:06:29.150 --> 00:06:33.280
eben gesagt, wir machen ein IPv6 only
Netz. Kann man in mehreren Stufen lösen.

00:06:33.280 --> 00:06:38.590
Step 1, so mittelmäßig ernst gemeint,
Awareness schaffen. Ihr seht hier diese

00:06:38.590 --> 00:06:43.240
schönen Banner auf meinem Blog. Falls ihr
das nicht lesen könnt, da steht drin: Du

00:06:43.240 --> 00:06:48.130
besuchst diese Seite mit einem veralteten
IPv4-Internetzugang. Möglicherweise treten

00:06:48.130 --> 00:06:51.730
in Zukunft Probleme mit der Erreichbarkeit
und Performance auf. Bitte frage deinen

00:06:51.730 --> 00:06:56.260
Internetanbieter oder Netzwerk-
Administrator nach IPv6-Unterstützung. Was

00:06:56.260 --> 00:07:00.100
ist die Idee dahinter? Wenn das genug
Leute machen, wirds zu einem Marketing

00:07:00.100 --> 00:07:04.720
Problem wenn ein Netz oder ein Provider
kein IPv6 kann, also kein richtiges IP

00:07:04.720 --> 00:07:09.310
anbieten. Und damit wird sich das Problem
lösen, weil dann hoffentlich mehr

00:07:09.310 --> 00:07:14.530
richtiges IP anbieten etc. Das ist eine
schöne Diskussion für Twitter, wenn ich

00:07:14.530 --> 00:07:18.940
ehrlich bin. Wie gesagt, ist nicht so ganz
ernst gemeint, aber falls ihr das auch

00:07:18.940 --> 00:07:25.630
machen wollt, wie habe ich das Ding
gemacht? nginx hat eine Weiche drin. Ob

00:07:25.630 --> 00:07:31.030
der Request per richtigem IP oder per
Legacy IP kam. Und wenn er herausfindet,

00:07:31.030 --> 00:07:36.820
dass der Request per Legacy IP kam,
ersetzt er den schließenden Body-Tag mit

00:07:36.820 --> 00:07:40.780
diesem Banner und natürlich einem
schließenden Body-Tag. Aber in Summe ist

00:07:40.780 --> 00:07:44.830
eine nette Spielerei, hilft aber nichts,
solange das nicht sehr sehr viele

00:07:44.830 --> 00:07:52.660
Webseiten etc. machen. Naja, also Step 1
naja. Brauchen wir also doch Legacy IP

00:07:52.660 --> 00:07:59.950
überall? Nein, weil dafür gibt es Step 2,
den Layer 4 Proxy. Und da ist die Idee,

00:07:59.950 --> 00:08:07.390
dass eine geringe Anzahl an Kisten doch
noch eine Legacy IP Adresse bekommt. Bei

00:08:07.390 --> 00:08:12.238
mir heißen die Gateways, kann man nennen
wie man will. Genau. Und auf diesen Kisten

00:08:12.238 --> 00:08:17.663
läuft dann ein nginx und der verteilt
quasi die Anfragen an die Legacy IP

00:08:17.663 --> 00:08:25.300
Adresse nach Port. Heißt, wenn eine
Anfrage an TCP Port 80 kommt, über Legacy

00:08:25.300 --> 00:08:33.760
IP weiß nginx, schickt es an an den und
den Server mit richtigem IP etc. weiter.

00:08:33.760 --> 00:08:39.700
Nachteil ist dann natürlich, man braucht
für jeden Dienst der einen auf dem schon

00:08:39.700 --> 00:08:44.920
belegten Port was macht, eine neue IP
Adresse oder neue Public V4 Adresse, weil

00:08:44.920 --> 00:08:49.150
sonst kann man es ja nicht, sondern
auseinander sortieren. Heißt natürlich

00:08:49.150 --> 00:08:55.390
besonders für http und https, dass ich mir
da ein zentrales Reverse Proxy Gateway

00:08:55.390 --> 00:08:58.990
gebaut habe, weil ich sonst viel zu viele
Gateways brauche, um das auseinander zu

00:08:58.990 --> 00:09:03.970
sortieren. Ich habe da auch mal ein
Beispiel-Config. Man sieht hier den nginx

00:09:03.970 --> 00:09:09.820
stream Block, das ist nicht der standard
nginx http Teil, sondern eben auf Layer 4,

00:09:09.820 --> 00:09:16.720
also TCP oder UDP. Man spezifiziert dann
hier ein upstream DNS-UDP-Backend in dem

00:09:16.720 --> 00:09:21.640
Beispiel. Also hier geht es um DNS. Ein
Server, in dem Fall v6-only natürlich, mit

00:09:21.640 --> 00:09:27.100
einem Port, wo das ganze hingeschickt
werden soll und sagt dem nginx dann: Hier

00:09:27.100 --> 00:09:33.880
bitte auf dieser IP Adresse UDP und Port,
hört, das ist in dem Fall natürlich die

00:09:33.880 --> 00:09:39.940
public v4, sollte das sein. Die 10.1.2.3
ist einfach nur ein Example und das ganze

00:09:39.940 --> 00:09:43.870
andere, das dann an das entsprechende
Backend weiterleitet. Das Ganze gibt es

00:09:43.870 --> 00:09:49.360
hier drunter noch mal für die TCP
Variante, genau. Also, eigentlich auch

00:09:49.360 --> 00:09:54.940
kein Hexenwerk, das ganze zu machen. Wie
sieht das praktisch aus? Interne Dienste,

00:09:54.940 --> 00:09:59.710
die nicht von außen erreichbar sein sollen
oder müssen, haben bei mir generell nur

00:09:59.710 --> 00:10:06.745
eine Public V6 Adresse. Das heißt, wenn
wir beim DNS bleiben, ein hidden Primary

00:10:06.745 --> 00:10:12.790
hat nur eine einzige V6 Adresse. Das ist
auch die drauf konfigurierte, darunter ist

00:10:12.790 --> 00:10:19.030
er erreichbar, aber er brauch ja kein V4,
wenn keine Endnutzer von V4, die nur V4

00:10:19.030 --> 00:10:25.780
haben, von außen drauf zugreifen müssen.
Nehmen wir mal ein Beispiel den Secondary,

00:10:25.780 --> 00:10:30.760
der von Endnutzern erreichbar sein soll.
Der Hostname und die IP, die die Kiste

00:10:30.760 --> 00:10:37.690
selbst hat, ist weiterhin v6 only, wie man
hier im oberen Beispiel erkennen kann. Die

00:10:37.690 --> 00:10:42.580
Endnutzer kriegen dann aber einen anderen
Hostnamen, hier z.B. ns1.example.com. Und

00:10:42.580 --> 00:10:47.680
der geht für richtiges IP einmal direkt
auf die konfigurierte Adresse. Da hängt

00:10:47.680 --> 00:10:51.940
kein Gateway mehr dazwischen etc. Das ist
natürlich direkte Ende zu Ende

00:10:51.940 --> 00:10:57.700
Kommunikation. Genau. Und die V4 Adresse
geht an dieses nginx stream Gateway, was

00:10:57.700 --> 00:11:01.840
wir eben gesehen haben, was dann natürlich
entsprechend konfiguriert sein muss, dass

00:11:01.840 --> 00:11:09.490
es auf Port 53 eingehende Anfragen
entsprechend behandelt. Das Thema Wie

00:11:09.490 --> 00:11:14.980
sprechen Endnutzer mit den Servern ist
jetzt gelöst. Wie sprechen aber jetzt die

00:11:14.980 --> 00:11:20.530
Server nach außen? Das Problem ist, manche
Endpunkte haben kein richtiges IP. Da gibt

00:11:20.530 --> 00:11:25.120
es nur sehr sehr bekannte GIT Webseite,
die aktuell noch nicht per IPv6-only

00:11:25.120 --> 00:11:29.290
bedienbar ist oder erreichbar ist. Was
macht man also? The same procedure as

00:11:29.290 --> 00:11:33.580
every time. Wenn man ein Netzwerkproblem
hat und insbesondere ein

00:11:33.580 --> 00:11:38.200
Adressierungsproblem macht man natürlich
NAT. Diesmal nur nicht ganz so schlimm.

00:11:38.200 --> 00:11:42.700
Wir machen nicht NAT 44, sondern wir
machen NAT 64. Das heißt wir NATen im

00:11:42.700 --> 00:11:47.020
Prinzip Adressen zwischen dem
IPv6-Adressraum und dem IPv4-Adressraum.

00:11:47.590 --> 00:11:51.010
Das ganze will ich jetzt nicht im Detail
erklären. Das ist ein eigener Talk. Da

00:11:51.010 --> 00:11:55.780
gibt es auch mehr als genug Infos und
Literatur dazu, wie dieses NAT 64

00:11:55.780 --> 00:12:00.460
eigentlich funktioniert. Zumindest wenn
ihr im Telekom-Mobilfunknetz seid, ist die

00:12:00.460 --> 00:12:05.110
Chance, dass ihr das unwissentlich schon
benutzt relativ groß, weil meines Wissens

00:12:05.110 --> 00:12:10.150
macht die das Telekom das per Default oder
bietet das per default an. Genau, die

00:12:10.150 --> 00:12:16.270
Realisierung bei mir ist: Ich habe diesen
Common Präfix, diesen V6 Präfix, wo der

00:12:16.270 --> 00:12:22.390
gesamte IPv4 Adressraum drin abgebildet
werden kann. Dieser /96 Präfix wird im

00:12:22.390 --> 00:12:31.060
internen Netz von den 64-Gateways
announced um quasi den Devices die Routen

00:12:31.060 --> 00:12:38.470
dahin anzubieten, also per ITP genau. Und
wenn eine IPv6-only Kiste jetzt auf eine

00:12:38.470 --> 00:12:43.930
IPv4-only Resource im Internet zugreifen
will, macht sie eine Anfrage an einen

00:12:43.930 --> 00:12:47.920
entsprechend konfigurierten DNS resolver,
der genau eine Adresse in diesem Range

00:12:47.920 --> 00:12:52.390
zurückgibt. So Resolver gibt es
haufenweise, kann man selbst hosten.

00:12:52.390 --> 00:12:56.410
Google hat da was, Cloudflare hat da was,
das ist auch alles ein gelöstes Problem,

00:12:56.410 --> 00:13:04.270
einfach mal DNS 64 resolver googlen, da
findet man was. Also sind wir eigentlich

00:13:04.270 --> 00:13:07.870
fertig. Wir können von innen nach außen
kommunizieren und von außen nach innen.

00:13:07.870 --> 00:13:12.580
Gucken wir uns die Übersicht noch mal an.
Von erstmal unten haben wir unser großes

00:13:12.580 --> 00:13:17.860
IPv6-only-Netzwerk. Bei mir läuft es mit
OSPF und IBGP. Wir haben den ganz normalen

00:13:17.860 --> 00:13:24.040
Edge-Router, der die Adressen ins Internet
routet und umgekehrt. V6 Enduser gehen

00:13:24.040 --> 00:13:27.550
direkt über diesen Edge-Router Ende zu
Ende zu dem Dienst unten auf der rechten

00:13:27.550 --> 00:13:34.660
Seite. Oben sehen wir noch Legacy End
User. Der muss den Umweg über unser TCP

00:13:34.660 --> 00:13:41.650
UDP Legacy to V6 Proxy nehmen. Das ist die
nginx stream Config, die wir eben gesehen

00:13:41.650 --> 00:13:47.020
haben. Auf der linken Seite nochmal
zusammengefasst das, was ich eben kurz

00:13:47.020 --> 00:13:53.406
erklärte, wie Native V6 only Services mit
Legacy only Ressourcen kommunizieren,

00:13:53.406 --> 00:13:58.265
nämlich über ein Nat64 Gateway, was quasi
auch an der Kante des IPv6-only Netzes

00:13:58.265 --> 00:14:04.931
steht. Und vorher müssen sie noch einen
DNS64-Resolver natürlich fragen, um erst

00:14:04.931 --> 00:14:10.007
mal die Adresse zu bekommen. Wäre
natürlich zu schön, wenn das ganze out of

00:14:10.007 --> 00:14:14.440
the box funktioniert und man nicht den ein
oder anderen problematischen Dienst an der

00:14:14.440 --> 00:14:21.314
Stelle hätte. Womit hatte ich Probleme?
Wie habe ich die gelöst? Mail ist an sich

00:14:21.314 --> 00:14:26.015
kompliziert, weil Reverse-DNS etc., das
muss alles passen, sonst werden E-Mails

00:14:26.015 --> 00:14:30.422
abgelehnt. Gleichzeitig ist E-Mail für
mich ein sehr kritischer Dienst. Von da

00:14:30.422 --> 00:14:35.025
habe ich einfach von Anfang an gesagt Der
lebt nicht IPv6-only, der kriegt eine

00:14:35.025 --> 00:14:39.467
eigene V4 und oder läuft sogar ganz
außerhalb. An der Stelle noch mal,

00:14:39.467 --> 00:14:43.833
überlegt euch gut, ob ihr einen eigenen
Mailserver betreiben wollt. Wenn ihr das

00:14:43.833 --> 00:14:47.290
noch nicht macht, das ist administrativ
nicht ganz einfach, wenn nicht sogar das

00:14:47.290 --> 00:14:52.916
Komplizierteste an der ganzen Geschichte
hier, einen verfügbaren funktionierenden

00:14:52.916 --> 00:14:58.423
Mailserver zu betreiben. Ein weiteres
Problem, was ich hatte mit der netten

00:14:58.423 --> 00:15:02.648
Software Matrix Synapse, ein Home Server
für Matrix, also Instant Messaging. An

00:15:02.648 --> 00:15:07.245
sich läuft das Ding IPv6 only. Es gibt da
nur eine komische Library, die E-Mails

00:15:07.245 --> 00:15:11.217
verschickt und die kann kein Happy
Eyeballs. Das heißt, wenn die versucht

00:15:11.217 --> 00:15:16.821
sich zu diesem SMTP Server, der eine V4
oder V6 Adresse hat zu connecten, ähm aber

00:15:16.821 --> 00:15:21.861
den über Legacy nicht erreichen kann,
weil eine V6-only Kiste natürlich keine

00:15:21.861 --> 00:15:26.938
default route für eine legacy IP-Adresse
hat, hört die einfach auf zu

00:15:26.938 --> 00:15:31.271
funktionieren. Also es gibt ein Timeout,
sie kann es nicht erreichen. Habe ich noch

00:15:31.271 --> 00:15:35.344
nicht gelöst. Gibt ein GitHub issue dazu,
müsste man wahrscheinlich mal etwas viel

00:15:35.344 --> 00:15:40.895
Zeit rein investieren und dann ist auch
das Thema gefixt. Aber aktuell ist es noch

00:15:40.895 --> 00:15:46.076
kaputt. Docker ist auch so ein Thema. Wenn
man das entsprechend konfiguriert und die

00:15:46.076 --> 00:15:50.423
Zeit reinsteckt, läuft es dann per V6, per
Default nicht so wirklich, ist eher

00:15:50.423 --> 00:15:56.500
anstrengend, sich um Docker in V6-only zu
kümmern, geht aber wenn man will. Weniger

00:15:56.500 --> 00:16:02.720
toll ist das ganze mit Gitlab Runnern. Ich
habe mal versucht ein GitLab Run in dieses

00:16:02.720 --> 00:16:07.121
V6-only Netz zu stellen. Die Kommunikation
zwischen Containern klappte dann irgendwie

00:16:07.121 --> 00:16:10.856
nicht, wenn man Docker in Docker gemacht
hat und dann noch irgendwie docker Service

00:16:10.856 --> 00:16:14.847
containern brauchte. Eventuell muss ich
das Ding auf V4 only zurückbauen und dann

00:16:14.847 --> 00:16:19.175
irgendwie so eine CLAT da hinstellen. Also
ohne jetzt ins Detail zu gehen. Alles ganz

00:16:19.175 --> 00:16:23.588
schrecklich. Ist aktuell weiterhin kaputt.
Noch so ein Thema, wenn ich per https ins

00:16:23.588 --> 00:16:33.366
Heimnetz will, aber das eben nicht über
einen Dyn-DNS machen will, sondern über

00:16:33.366 --> 00:16:40.441
einen direkt angebundenen, über VPN
angebundenen Jumphost, nenne ich es mal,

00:16:40.441 --> 00:16:44.914
ist das ein bisschen kompliziert, je
nachdem, wie man sein Netz aufbaut. Mein

00:16:44.914 --> 00:16:50.270
OpenVPN-Server steht im IPv6-only Teil.
Das funktioniert auch. Kam trotzdem nicht

00:16:50.270 --> 00:16:56.958
drumrum, ein Reverse Proxy Channing, also
quasi ein NAT für HTTP zu bauen. Ist nicht

00:16:56.958 --> 00:17:03.086
schön, ginge bestimmt anders. Anders wäre
das halt deutlich zeitaufwändiger. Dann

00:17:03.086 --> 00:17:08.216
kommen wir mal zum letzten wichtigen Teil:
Konnektivität, Routing und Administration.

00:17:08.216 --> 00:17:14.059
Das ist jetzt nicht mehr so stark auf
IPv6-only bezogen. Eher generell. Ich habe

00:17:14.059 --> 00:17:21.360
zwei Standorte mit BGP-Konnektivität nach
außen, eine IXP-VM in Frankfurt und einmal

00:17:21.360 --> 00:17:27.442
eine VM nur mit Transit. Transit für V6
ist relativ günstig. Gratis v6-Transit ist

00:17:27.442 --> 00:17:32.773
zumindest für kleine Projekte auch
verfügbar. Und dann habe ich noch weitere

00:17:32.773 --> 00:17:37.652
Projekte, weitere Standorte mit billigem
Compute. Also die ganze Rechenleistung

00:17:37.652 --> 00:17:41.862
steht, wo ich aber leider kein BGP habe,
zum Beispiel Hetzner. Heißt ich muss

00:17:41.862 --> 00:17:46.803
irgendwie zwischen diesen beiden
Standorten kommunizieren können. Da musste

00:17:46.803 --> 00:17:52.179
ich mir, weil ich nichts besseres habe,
einen Wireguard, also ein VPN-Overlay

00:17:52.179 --> 00:17:57.521
bauen. WAN-intern, läuft da getrennt über
Policy Based Routing. iprule is your

00:17:57.521 --> 00:18:02.402
friend. VRFs wären besser, um quasi die
Sicht des eigenen Netzes und die Sicht des

00:18:02.402 --> 00:18:05.998
Hetzner-Netzes zu trennen. Es gibt da auf
der wireguard-Mailingliste eine

00:18:05.998 --> 00:18:09.995
Diskussion, die ist aktuell aber leider
eher eingeschlafen. Also wireguard kann

00:18:09.995 --> 00:18:14.264
dieses VRF noch nicht. Mit iprule kriegt
man das hin, das ist auch nicht sonderlich

00:18:14.264 --> 00:18:20.113
großartig und es frisst natürlich MTU.
Also Wireguard. Ihr wollt, wenn ihr so was

00:18:20.113 --> 00:18:24.943
macht, strikte Firewall-Regeln haben um
Leaks zu unterbinden. Das heißt ihr wollt

00:18:24.943 --> 00:18:30.913
nicht versehentlich aus eurem internen
Netz Pakete mit eurer source IP an das

00:18:30.913 --> 00:18:37.491
Hetzner Default-Gateway senden. Das wäre
uncool. Weil Hetzner weiß ja nicht, oder

00:18:37.491 --> 00:18:42.275
kennt ja euer AS nicht oder euer NAT
nicht. Für Hetzer ist das ja ein externes

00:18:42.275 --> 00:18:47.330
Netz, weil ihr da kein BGP upstream habt.
Also da wirklich aufpassen, was ihr da

00:18:47.330 --> 00:18:51.976
baut. Vorher verstehen und dann bauen.
Mein Routing mache ich mit bird2 unter

00:18:51.976 --> 00:18:58.944
Linux, OSPF als interior gateway-
Protokoll, IBGP zwischen allen größeren

00:18:58.944 --> 00:19:02.641
Standorten. Ist im wesentlichen
Geschmackssache, wie man das baut. Da gibt

00:19:02.641 --> 00:19:05.830
es auch verschiedenste Möglichkeiten.
Weiterhin das Thema Administration.

00:19:05.830 --> 00:19:13.245
Benutzt Konfigurationsmanagement. Ich
benutz Saltstack mit Ansible oder anderen

00:19:13.245 --> 00:19:18.860
Tools geht das garantiert auch. Nur das
wächst so schnell an, da kriegt ihr dann

00:19:18.860 --> 00:19:22.292
in die BGP-Filter, in die BGP-
Konfiguration, in die Firewall Regeln

00:19:22.292 --> 00:19:26.302
keine Konsistenz mehr rein, wenn ihr das
nicht, ich sage mal systematisch ausrollt

00:19:26.302 --> 00:19:31.490
und per config management sicherstellt,
dass das System stabil und konsistent

00:19:31.490 --> 00:19:39.262
läuft. Kommen wir so langsam zum Ende. Was
wäre noch cool für das Projekt? Weg von

00:19:39.262 --> 00:19:45.544
den IXP-VMs, hin zum echten Blech, was da
steht und Pakete routet oder auch Dienste

00:19:45.544 --> 00:19:51.879
hostet. Ist natürlich aufwendiger und
teurer, das mit echtem Blech zu machen.

00:19:51.879 --> 00:19:57.558
Ist eine Option für die Zukunft. Und
echter Layer 2 Transport statt Overlay

00:19:57.558 --> 00:20:02.471
wäre natürlich auch cool. Frisst mir dann
nicht mehr die MTU weg und so weiter. Ist

00:20:02.471 --> 00:20:06.881
aber gerade was Standorte, Konnektivität
etc. betrifft nicht ganz trivial und auch

00:20:06.881 --> 00:20:11.203
nicht ganz billig. Sollte man definitiv
machen, wenn das Netz produktiv wird,

00:20:11.203 --> 00:20:17.547
solange es irgendwie ein Best Effort
Bastelnetz ist oder Privat-Netz ist, ist

00:20:17.547 --> 00:20:24.635
das so eigentlich in Ordnung. Fazit: Würde
ich es noch mal machen? Definitiv, v6-only

00:20:24.635 --> 00:20:30.078
mit wenigen Legacy IP-Adressen auf den
Edges ist durchaus sinnvoll machbar.

00:20:30.078 --> 00:20:34.060
Kostentechnisch ist es eh schon
interessant. Gerade Hetzner hat jetzt vor

00:20:34.060 --> 00:20:38.744
kurzem ja angekündigt, dass v4 zukünftig
extra kosten wird oder es ohne V4 billiger

00:20:38.744 --> 00:20:44.939
wird. Also ja, das mache ich definitiv
weiter so und würde das auch in neuen

00:20:44.939 --> 00:20:48.412
Projekten so machen, dass ich V4 nur noch
auf den Edges habe, auch im privaten

00:20:48.412 --> 00:20:52.988
Umfeld. Ihr habt ja gesehen, dass ist
nicht sonderlich kompliziert. Der Aufbau

00:20:52.988 --> 00:20:58.021
mit diesen IXP-VMs und Tunneln dazwischen
ist okay für private best effort services.

00:20:58.021 --> 00:21:02.205
Ihr hört schon, ich bin nicht so ganz
überzeugt. Also es ist nicht für wirklich

00:21:02.205 --> 00:21:07.375
produktive Produktiv-Netze geeignet. Also
nichts, was Geld verdient etc. Dafür Layer

00:21:07.375 --> 00:21:11.528
2 Transport, ordentliche Peerings,
ordentlicher Transit, ordentliche

00:21:11.528 --> 00:21:16.961
Hardware. Aber das ist ja hier an der
Stelle auch nicht Ziel des Ganzen. Und

00:21:16.961 --> 00:21:22.190
damit bin ich am Ende. Vielen Dank fürs
Einschalten, fürs Zuhören. Und wenn ihr

00:21:22.190 --> 00:21:27.015
Fragen habt, sendet gerne eine Mail an rc3
at ipv6.church.

00:21:27.015 --> 00:21:35.195
Herald: Und dann sind wir wieder zurück
hier. Vielen Dank an margau für den Talk.

00:21:35.195 --> 00:21:40.298
Es gibt leider kein Q&A, weil margau mit
der C3 Infrastruktur beschäftigt ist. Aber

00:21:40.298 --> 00:21:44.643
wie ihr gesehen habt, könnt ihr ihr eine
Mail schreiben an die gerade eingeblendete

00:21:44.643 --> 00:21:48.628
Email-Adresse. Hier auf dem FEM-Channel
geht es jetzt gleich weiter um 19 Uhr mit

00:21:48.628 --> 00:21:52.957
der nächsten Herald News Show und um 20:15
Uhr mit votti zu NetBox als Datenquelle

00:21:52.957 --> 00:21:55.170
für Netzwerkinfrastruktur. Bis dahin.

00:21:55.170 --> 00:22:20.000
Untertitel erstellt von c3subtitles.de
im Jahr 2023. Mach mit und hilf uns!