0:00:00.000,0:00:03.630
Herald: Hallo und herzlich willkommen auf[br]dem FEM Kanal und zu unserem ersten Talk

0:00:03.630,0:00:08.880
heute von margau. Margau hat irgendwann[br]mal angefangen bei Freifunk und ist dann

0:00:08.880,0:00:13.170
irgendwann immer professioneller geworden[br]und inzwischen beim C3 Infrastuktur Team

0:00:13.170,0:00:18.270
angekommen. Kümmert man sich also jetzt[br]genau gerade um die RC3 World und das

0:00:18.270,0:00:22.260
ganze was es dahinter gibt. Aus genau dem[br]Grund gibt es heute auch kein Q&A bei dem

0:00:22.260,0:00:28.380
Talk, denn der Talk ist aufgezeichnet.[br]Magau ist busy mit dem Betrieb, so. Es

0:00:28.380,0:00:36.060
geht um IPv6 und zwar nicht wie sonst[br]immer mit ... v4 zusammen, sondern

0:00:36.060,0:00:41.790
standalone. Also quasi das, was der Traum[br]eines jeden Netzwerkers unter 40 Jahren

0:00:41.790,0:00:48.330
ist. Er wird ein paar Erfahrungen[br]weitergeben und Tipps, falls wir das auch

0:00:48.330,0:00:51.450
alle mal machen wollen, dann... for the[br]English speaking viwers, there will be a

0:00:51.450,0:01:00.420
translation. To listen to it, select on[br]the language selection select the first

0:01:00.420,0:01:05.487
translated option to hear the english[br]translation. Und jetzt viel Spaß beim Talk

0:01:05.487,0:01:08.819
mit Margau.[br][placeholder remove me in amara]

0:01:08.819,0:01:14.468
margau: Ja hallo, ich bin margau. Schön,[br]dass ihr eingeschaltet habt zu meinem Talk

0:01:14.468,0:01:20.235
"Legacy IP gibt es nicht mehr, aber kein[br]Netz ist auch keine Lösung" hier beim RC3

0:01:20.235,0:01:26.841
2021. Genau. Worum geht es bei meinem Talk[br]heute? Wie betreibe ich ein richtiges Netz

0:01:26.841,0:01:32.012
mit IPv6-Focus oder soweit es geht[br]IPv6-Only. Bisschen, meine Erfahrungen.

0:01:32.012,0:01:37.896
Welche Probleme habe ich gefunden, welche[br]Lösungen und natürlich auch ein bisschen

0:01:37.896,0:01:42.356
Inspiration, was ihr für eure Netze für[br]eure Dienste mitnehmen könnt, damit

0:01:42.356,0:01:46.905
vielleicht auch ihr dann in der Lage seid[br]IPv6-Only zu sprechen, wenn ihr es noch

0:01:46.905,0:01:52.323
nicht macht. Vorher, bevor wir loslegen[br]aber erst mal ein Disclaimer. In dem Talk

0:01:52.323,0:01:57.480
und auch bei meinem Netz geht es um, ich[br]sage mal, echtes Internet. Das heißt, wir

0:01:57.480,0:02:03.120
haben einen AS, wir haben IP-space der BGP[br]mit dem Rest des Internets spricht. Das

0:02:03.120,0:02:08.154
ganze ist kein Spielzeug! Betrieb eines[br]AS's ist deutlich mehr als einfach nur

0:02:08.154,0:02:12.051
irgendwo eine virtuelle Maschine klicken[br]und da einen Linux drauf zu installieren

0:02:12.051,0:02:15.901
und einen Webserver hochzuziehen oder so.[br]Also überlegt euch wirklich gut, ob ihr

0:02:15.901,0:02:21.735
das könnt, ob ihr die Verantwortung tragen[br]könnt und ja, ob ihr das auch braucht, an

0:02:21.735,0:02:28.863
der Stelle. Passt auf, dass ihr wisst was[br]ihr tut. Weil, wenn es erst mal nur ums

0:02:28.863,0:02:33.885
Üben und ums Spielen mit BGP, mit[br]Internet, mit Routing geht, gibt z.B. das

0:02:33.885,0:02:38.534
den DN42, das ist ein virtuelles Overlay-[br]Netz und das ist dafür sehr gut geeignet.

0:02:38.534,0:02:43.719
Aber das sollte man nicht direkt produktiv[br]im Internet tun. Genau, dann nachdem der

0:02:43.719,0:02:49.410
Formalkram geklärt is, machen wir mal[br]weiter mit der Terminologie. Ich werde in

0:02:49.410,0:02:56.101
dem Talk ein paar Begriffe häufig nutzen,[br]nämlich IP oder richtiges IP meint

0:02:56.101,0:03:03.014
natürlich IPv6, das Moderne die 128 Bit[br]Variante und wenn ich von Legacy IP

0:03:03.014,0:03:09.287
spreche, meine ich damit IPv4, die alter[br]32 Bit Variante. Genau. Aber wie hat das

0:03:09.287,0:03:14.215
ganze eigentlich angefangen? Irgendwann in[br]2020 habe ich mir gedacht, so

0:03:14.215,0:03:20.203
Infrastruktur betreibe ich eigentlich[br]schon lange genug, mehrere Jahre. Das DN42

0:03:20.203,0:03:25.677
und auch bei anderen Möglichkeiten,[br]Routing etc. auch schon einiges an

0:03:25.677,0:03:30.930
Erfahrung gesammelt. Es hat sich in ein[br]ganzer Zoo an Diensten angesammelt, der

0:03:30.930,0:03:36.700
mal einen ordentlichen Neubau brauchte.[br]Von daher so langsam lohnt sich eigentlich

0:03:36.700,0:03:42.141
ein richtiges Netzwerk, oder? Was brauche[br]ich denn für ein richtiges Netzwerk? Ich

0:03:42.141,0:03:46.115
brauche erst mal ein Autonomes System. Das[br]kann ich, wenn ich nicht selbst RIPE-

0:03:46.115,0:03:51.137
Mitglied werde, von einem Sponsoring LIR[br]bekommen. Ich brauche Konnektivität. Also

0:03:51.137,0:03:56.881
irgendwie muss ich ja meine IP Adressen[br]meines Autonomen Systems ins Internet

0:03:56.881,0:04:02.610
bringen. Da gibt es virtuelle Maschinen[br]mit IXP, also Internet Exchange Points

0:04:02.610,0:04:08.505
Anbindung. Es gibt virtuelle Maschinen mit[br]BGP Upstream. Also auch das ist nicht das

0:04:08.505,0:04:14.100
Problem. Zuletzt brauche ich natürlich im[br]Netz noch IP Adressen. Richtiges IP, also

0:04:14.100,0:04:21.547
IPv6, auch kein Problem. Gibt es zu Hauf,[br]von RIPE bekommt man /48 PI als Provider

0:04:21.547,0:04:29.210
Independent und das ist an einen selbst[br]oder an die Organisation gebunden, aber

0:04:29.210,0:04:36.464
nicht an den Provider, der jemandem das[br]bereitstellt. Genau. Also v6 Adressen

0:04:36.464,0:04:42.759
haben wir. Legacy IP-Adressen oder auch[br]IPv4 Adressen genannt. Jetzt wird es

0:04:42.759,0:04:47.436
langsam interessanter, gibt es nämlich[br]nicht mehr. Wenn man mal auf die Seite der

0:04:47.436,0:04:52.873
RIPE guckt, wie die RIPE-Mitglieder auf[br]neue IPv4-Adressen warten, sieht man der

0:04:52.873,0:04:57.866
Graph, die Warteliste steigt stetig an.[br]Und ja, vermutlich hat es heute einen

0:04:57.866,0:05:02.300
neuen Höchststand wie gestern, wie[br]vorgestern, wie letzte Woche etc. Und auch

0:05:02.300,0:05:07.784
der Gebrauchtmarkt, nenne ich es mal, für[br]IPv4-Adressen ist jetzt nicht gerade so

0:05:07.784,0:05:15.022
toll, da bezahlt man definitiv einen[br]zweistelligen Betrag in mittlerer Größe

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

0:05:22.162,0:05:27.558
eigentlich für so ein privates Best Effort[br]Projekt allein aus finanzieller Sicht

0:05:27.558,0:05:33.848
schon keine wirkliche Lösung mehr. Was[br]macht man also? Einfach nur IPv6? Weil

0:05:33.848,0:05:39.710
IPv6 haben wir ja. Ist kein Problem oder[br]ist kein Problem, das zu bekommen. Machen

0:05:39.710,0:05:44.360
wir IPv6 only. Als nächstes habe ich mir[br]überlegt, was soll mein Netz eigentlich

0:05:44.360,0:05:50.000
machen? Ich habe dann so eine kleine Liste[br]an Diensten, die ich betreibe, die auch in

0:05:50.000,0:05:53.510
dieses Netz dann umziehen sollen.[br]Natürlich ein klassischer Webserver mit

0:05:53.510,0:05:58.880
einem Blog dahinter, eine Nextcloud, einen[br]Hedgedoc, über den übrigens gerade diese

0:05:58.880,0:06:05.990
Präsentation hier läuft. Mailserver,[br]kommen wir später noch zu und auch noch

0:06:05.990,0:06:09.020
das eine oder andere, je nachdem wie[br]gerade Bedarf ist. Aber wenn man sich

0:06:09.020,0:06:14.120
diese Liste anguckt, merkt man das nutzen[br]tatsächlich Menschen. Also es ist nicht

0:06:14.120,0:06:19.070
nur für mich, um es zu haben, da greifen[br]tatsächlich Menschen drauf zu und wollen

0:06:19.070,0:06:23.780
vielleicht das eine oder andere Mal mit[br]diesen Diensten interagieren. Was macht

0:06:23.780,0:06:29.150
man jetzt aber, wenn die Nutzer der[br]Dienste nur Legacy IP haben? Wir haben ja

0:06:29.150,0:06:33.280
eben gesagt, wir machen ein IPv6 only[br]Netz. Kann man in mehreren Stufen lösen.

0:06:33.280,0:06:38.590
Step 1, so mittelmäßig ernst gemeint,[br]Awareness schaffen. Ihr seht hier diese

0:06:38.590,0:06:43.240
schönen Banner auf meinem Blog. Falls ihr[br]das nicht lesen könnt, da steht drin: Du

0:06:43.240,0:06:48.130
besuchst diese Seite mit einem veralteten[br]IPv4-Internetzugang. Möglicherweise treten

0:06:48.130,0:06:51.730
in Zukunft Probleme mit der Erreichbarkeit[br]und Performance auf. Bitte frage deinen

0:06:51.730,0:06:56.260
Internetanbieter oder Netzwerk-[br]Administrator nach IPv6-Unterstützung. Was

0:06:56.260,0:07:00.100
ist die Idee dahinter? Wenn das genug[br]Leute machen, wirds zu einem Marketing

0:07:00.100,0:07:04.720
Problem wenn ein Netz oder ein Provider[br]kein IPv6 kann, also kein richtiges IP

0:07:04.720,0:07:09.310
anbieten. Und damit wird sich das Problem[br]lösen, weil dann hoffentlich mehr

0:07:09.310,0:07:14.530
richtiges IP anbieten etc. Das ist eine[br]schöne Diskussion für Twitter, wenn ich

0:07:14.530,0:07:18.940
ehrlich bin. Wie gesagt, ist nicht so ganz[br]ernst gemeint, aber falls ihr das auch

0:07:18.940,0:07:25.630
machen wollt, wie habe ich das Ding[br]gemacht? nginx hat eine Weiche drin. Ob

0:07:25.630,0:07:31.030
der Request per richtigem IP oder per[br]Legacy IP kam. Und wenn er herausfindet,

0:07:31.030,0:07:36.820
dass der Request per Legacy IP kam,[br]ersetzt er den schließenden Body-Tag mit

0:07:36.820,0:07:40.780
diesem Banner und natürlich einem[br]schließenden Body-Tag. Aber in Summe ist

0:07:40.780,0:07:44.830
eine nette Spielerei, hilft aber nichts,[br]solange das nicht sehr sehr viele

0:07:44.830,0:07:52.660
Webseiten etc. machen. Naja, also Step 1[br]naja. Brauchen wir also doch Legacy IP

0:07:52.660,0:07:59.950
überall? Nein, weil dafür gibt es Step 2,[br]den Layer 4 Proxy. Und da ist die Idee,

0:07:59.950,0:08:07.390
dass eine geringe Anzahl an Kisten doch[br]noch eine Legacy IP Adresse bekommt. Bei

0:08:07.390,0:08:12.238
mir heißen die Gateways, kann man nennen[br]wie man will. Genau. Und auf diesen Kisten

0:08:12.238,0:08:17.663
läuft dann ein nginx und der verteilt[br]quasi die Anfragen an die Legacy IP

0:08:17.663,0:08:25.300
Adresse nach Port. Heißt, wenn eine[br]Anfrage an TCP Port 80 kommt, über Legacy

0:08:25.300,0:08:33.760
IP weiß nginx, schickt es an an den und[br]den Server mit richtigem IP etc. weiter.

0:08:33.760,0:08:39.700
Nachteil ist dann natürlich, man braucht[br]für jeden Dienst der einen auf dem schon

0:08:39.700,0:08:44.920
belegten Port was macht, eine neue IP[br]Adresse oder neue Public V4 Adresse, weil

0:08:44.920,0:08:49.150
sonst kann man es ja nicht, sondern[br]auseinander sortieren. Heißt natürlich

0:08:49.150,0:08:55.390
besonders für http und https, dass ich mir[br]da ein zentrales Reverse Proxy Gateway

0:08:55.390,0:08:58.990
gebaut habe, weil ich sonst viel zu viele[br]Gateways brauche, um das auseinander zu

0:08:58.990,0:09:03.970
sortieren. Ich habe da auch mal ein[br]Beispiel-Config. Man sieht hier den nginx

0:09:03.970,0:09:09.820
stream Block, das ist nicht der standard[br]nginx http Teil, sondern eben auf Layer 4,

0:09:09.820,0:09:16.720
also TCP oder UDP. Man spezifiziert dann[br]hier ein upstream DNS-UDP-Backend in dem

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

0:09:21.640,0:09:27.100
einem Port, wo das ganze hingeschickt[br]werden soll und sagt dem nginx dann: Hier

0:09:27.100,0:09:33.880
bitte auf dieser IP Adresse UDP und Port,[br]hört, das ist in dem Fall natürlich die

0:09:33.880,0:09:39.940
public v4, sollte das sein. Die 10.1.2.3[br]ist einfach nur ein Example und das ganze

0:09:39.940,0:09:43.870
andere, das dann an das entsprechende[br]Backend weiterleitet. Das ganze gibt es

0:09:43.870,0:09:49.360
hier drunter noch mal für die TCP[br]Variante, genau. Also, eigentlich auch

0:09:49.360,0:09:54.940
kein Hexenwerk, das ganze zu machen. Wie[br]sieht das praktisch aus? Interne Dienste,

0:09:54.940,0:09:59.710
die nicht von außen erreichbar sein sollen[br]oder müssen, haben bei mir generell nur

0:09:59.710,0:10:06.745
eine Public V6 Adresse. Das heißt, wenn[br]wir beim DNS bleiben, ein hidden Primary

0:10:06.745,0:10:12.790
hat nur eine einzige V6 Adresse. Das ist[br]auch die drauf konfigurierte, darunter ist

0:10:12.790,0:10:19.030
er erreichbar, aber er brauch ja kein V4,[br]wenn keine Endnutzer von V4, die nur V4

0:10:19.030,0:10:25.780
haben, von außen drauf zugreifen müssen.[br]Nehmen wir mal ein Beispiel den Secondary,

0:10:25.780,0:10:30.760
der von Endnutzern erreichbar sein soll.[br]Der Hostname und die IP, die die Kiste

0:10:30.760,0:10:37.690
selbst hat, ist weiterhin v6 only, wie man[br]hier im oberen Beispiel erkennen kann. Die

0:10:37.690,0:10:42.580
Endnutzer kriegen dann aber einen anderen[br]Hostnamen, hier z.B. ns1.example.com. Und

0:10:42.580,0:10:47.680
der geht für richtiges IP einmal direkt[br]auf die konfigurierte Adresse. Da hängt

0:10:47.680,0:10:51.940
kein Gateway mehr dazwischen etc. Das ist[br]natürlich direkte Ende zu Ende

0:10:51.940,0:10:57.700
Kommunikation. Genau. Und die V4 Adresse[br]geht an dieses nginx stream Gateway, was

0:10:57.700,0:11:01.840
wir eben gesehen haben, was dann natürlich[br]entsprechend konfiguriert sein muss, dass

0:11:01.840,0:11:09.490
es auf Port 53 eingehende Anfragen[br]entsprechend behandelt. Das Thema Wie

0:11:09.490,0:11:14.980
sprechen Endnutzer mit den Servern ist[br]jetzt gelöst. Wie sprechen aber jetzt die

0:11:14.980,0:11:20.530
Server nach außen? Das Problem ist, manche[br]Endpunkte haben kein richtiges IP. Da gibt

0:11:20.530,0:11:25.120
es nur sehr sehr bekannte GIT Webseite,[br]die aktuell noch nicht per IPv6-only

0:11:25.120,0:11:29.290
bedienbar ist oder erreichbar ist. Was[br]macht man also? The same procedure as

0:11:29.290,0:11:33.580
every time. Wenn man ein Netzwerkproblem[br]hat und insbesondere ein

0:11:33.580,0:11:38.200
Adressierungsproblem macht man natürlich[br]NAT. Diesmal nur nicht ganz so schlimm.

0:11:38.200,0:11:42.700
Wir machen nicht NAT 44, sondern wir[br]machen NAT 64. Das heißt wir NATen im

0:11:42.700,0:11:47.020
Prinzip Adressen zwischen dem[br]IPv6-Adressraum und dem IPv4-Adressraum.

0:11:47.590,0:11:51.010
Das ganze will ich jetzt nicht im Detail[br]erklären. Das ist ein eigener Talk. Da

0:11:51.010,0:11:55.780
gibt es auch mehr als genug Infos und[br]Literatur dazu, wie dieses NAT 64

0:11:55.780,0:12:00.460
eigentlich funktioniert. Zumindest wenn[br]ihr im Telekom-Mobilfunknetz seid, ist die

0:12:00.460,0:12:05.110
Chance, dass ihr das unwissentlich schon[br]benutzt relativ groß, weil meines Wissens

0:12:05.110,0:12:10.150
macht die das Telekom das per Default oder[br]bietet das per default an. Genau, die

0:12:10.150,0:12:16.270
Realisierung bei mir ist: Ich habe diesen[br]Common Präfix, diesen V6 Präfix, wo der

0:12:16.270,0:12:22.390
gesamte IPv4 Adressraum drin abgebildet[br]werden kann. Dieser /96 Präfix wird im

0:12:22.390,0:12:31.060
internen Netz von den 64-Gateways[br]announced um quasi den Devices die Routen

0:12:31.060,0:12:38.470
dahin anzubieten, also per ITP genau. Und[br]wenn eine IPv6-only Kiste jetzt auf eine

0:12:38.470,0:12:43.930
IPv4-only Resource im Internet zugreifen[br]will, macht sie eine Anfrage an einen

0:12:43.930,0:12:47.920
entsprechend konfigurierten DNS resolver,[br]der genau eine Adresse in diesem Range

0:12:47.920,0:12:52.390
zurückgibt. So Resolver gibt es[br]haufenweise, kann man selbst hosten.

0:12:52.390,0:12:56.410
Google hat da was, Cloudflare hat da was,[br]das ist auch alles ein gelöstes Problem,

0:12:56.410,0:13:04.270
einfach mal DNS 64 resolver googlen, da[br]findet man was. Also sind wir eigentlich

0:13:04.270,0:13:07.870
fertig. Wir können von innen nach außen[br]kommunizieren und von außen nach innen.

0:13:07.870,0:13:12.580
Gucken wir uns die Übersicht noch mal an.[br]Von erstmal unten haben wir unser großes

0:13:12.580,0:13:17.860
IPv6-only-Netzwerk. Bei mir läuft es mit[br]OSPF und IBGP. Wir haben den ganz normalen

0:13:17.860,0:13:24.040
Edge-Router, der die Adressen ins Internet[br]routet und umgekehrt. V6 Enduser gehen

0:13:24.040,0:13:27.550
direkt über diesen Edge-Router Ende zu[br]Ende zu dem Dienst unten auf der rechten

0:13:27.550,0:13:34.660
Seite. Oben sehen wir noch Legacy End[br]User. Der muss den Umweg über unser TCP

0:13:34.660,0:13:41.650
UDP Legacy to V6 Proxy nehmen. Das ist die[br]nginx stream Config, die wir eben gesehen

0:13:41.650,0:13:47.020
haben. Auf der linken Seite nochmal[br]zusammengefasst das, was ich eben kurz

0:13:47.020,0:13:53.406
erklärte, wie Native V6 only Services mit[br]Legacy only Ressourcen kommunizieren,

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

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

0:14:04.931,0:14:10.007
mal die Adresse zu bekommen. Wäre[br]natürlich zu schön, wenn das ganze out of

0:14:10.007,0:14:15.080
the box funktioniert und man nicht den ein[br]oder anderen problematischen Dienst an der

0:14:15.080,0:14:21.314
Stelle hätte. Womit hatte ich Probleme?[br]Wie habe ich die gelöst? Mail ist an sich

0:14:21.314,0:14:26.405
kompliziert, weil Reverse-DNS etc., das[br]muss alles passen, sonst werden E-Mails

0:14:26.405,0:14:30.422
abgelehnt. Gleichzeitig ist E-Mail für[br]mich ein sehr kritischer Dienst. Von da

0:14:30.422,0:14:35.025
habe ich einfach von Anfang an gesagt Der[br]lebt nicht IPv6-only, der kriegt eine

0:14:35.025,0:14:39.467
eigene V4 und oder läuft sogar ganz[br]außerhalb. An der Stelle noch mal,

0:14:39.467,0:14:43.833
überlegt euch gut, ob ihr einen eigenen[br]Mailserver betreiben wollt. Wenn ihr das

0:14:43.833,0:14:47.290
noch nicht macht, das ist administrativ[br]nicht ganz einfach, wenn nicht sogar das

0:14:47.290,0:14:52.916
Komplizierteste an der ganzen Geschichte[br]hier, einen verfügbaren funktionierenden

0:14:52.916,0:14:58.423
Mailserver zu betreiben. Ein weiteres[br]Problem, was ich hatte mit der netten

0:14:58.423,0:15:02.648
Software Matrix Synapse, ein Home Server[br]für Matrix, also Instant Messaging. An

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

0:15:07.245,0:15:11.217
verschickt und die kann kein Happy[br]Eyeballs. Das heißt, wenn die versucht

0:15:11.217,0:15:16.821
sich zu diesem SMTP Server, der eine V4[br]oder V6 Adresse hat zu connecten, ähm aber

0:15:16.821,0:15:22.481
den über Legacy nicht erreichen kann,[br]weil eine V6-only Kiste natürlich keine

0:15:22.481,0:15:26.938
default route für eine legacy IP-Adresse[br]hat, hört die einfach auf zu

0:15:26.938,0:15:31.271
funktionieren. Also es gibt ein Timeout,[br]sie kann es nicht erreichen. Habe ich noch

0:15:31.271,0:15:35.344
nicht gelöst. Gibt ein GitHub issue dazu,[br]müsste man wahrscheinlich mal etwas viel

0:15:35.344,0:15:40.895
Zeit rein investieren und dann ist auch[br]das Thema gefixt. Aber aktuell ist es noch

0:15:40.895,0:15:46.076
kaputt. Docker ist auch so ein Thema. Wenn[br]man das entsprechend konfiguriert und die

0:15:46.076,0:15:50.423
Zeit reinsteckt, läuft es dann per V6, per[br]Default nicht so wirklich, ist eher

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

0:15:56.500,0:16:02.720
toll ist das ganze mit Gitlab Runnern. Ich[br]habe mal versucht ein GitLab Run in dieses

0:16:02.720,0:16:07.121
V6-only Netz zu stellen. Die Kommunikation[br]zwischen Containern klappte dann irgendwie

0:16:07.121,0:16:10.856
nicht, wenn man Docker in Docker gemacht[br]hat und dann noch irgendwie docker Service

0:16:10.856,0:16:14.847
containern brauchte. Eventuell muss ich[br]das Ding auf V4 only zurückbauen und dann

0:16:14.847,0:16:19.175
irgendwie so eine CLAT da hinstellen. Also[br]ohne jetzt ins Detail zu gehen. Alles ganz

0:16:19.175,0:16:23.588
schrecklich. Ist aktuell weiterhin kaputt.[br]Noch so ein Thema, wenn ich per https ins

0:16:23.588,0:16:33.366
Heimnetz will, aber das eben nicht über[br]einen Dyn-DNS machen will, sondern über

0:16:33.366,0:16:40.441
einen direkt angebundenen, über VPN[br]angebundenen Jumphost, nenne ich es mal,

0:16:40.441,0:16:44.914
ist das ein bisschen kompliziert, je[br]nachdem, wie man sein Netz aufbaut. Mein

0:16:44.914,0:16:50.270
OpenVPN-Server steht im IPv6-only Teil.[br]Das funktioniert auch. Kam trotzdem nicht

0:16:50.270,0:16:56.958
drumrum, ein Reverse Proxy Channing, also[br]quasi ein NAT für HTTP zu bauen. Ist nicht

0:16:56.958,0:17:03.086
schön, ginge bestimmt anders. Anders wäre[br]das halt deutlich zeitaufwändiger. Dann

0:17:03.086,0:17:08.216
kommen wir mal zum letzten wichtigen Teil:[br]Konnektivität, Routing und Administration.

0:17:08.216,0:17:14.059
Das ist jetzt nicht mehr so stark auf[br]IPv6-only bezogen. Eher generell. Ich habe

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

0:17:21.360,0:17:27.442
eine VM nur mit Transit. Transit für V6[br]ist relativ günstig. Gratis v6-Transit ist

0:17:27.442,0:17:32.773
zumindest für kleine Projekte auch[br]verfügbar. Und dann habe ich noch weitere

0:17:32.773,0:17:37.652
Projekte, weitere Standorte mit billigem[br]Compute. Also die ganze Rechenleistung

0:17:37.652,0:17:41.862
steht, wo ich aber leider kein BGP habe,[br]zum Beispiel Hetzner. Heißt ich muss

0:17:41.862,0:17:46.803
irgendwie zwischen diesen beiden[br]Standorten kommunizieren können. Da musste

0:17:46.803,0:17:52.179
ich mir, weil ich nichts besseres habe,[br]einen Wireguard, also ein VPN-Overlay

0:17:52.179,0:17:57.521
bauen. WAN-intern, läuft da getrennt über[br]Policy Based Routing. iprule is your

0:17:57.521,0:18:02.402
friend. VRFs wären besser, um quasi die[br]Sicht des eigenen Netzes und die Sicht des

0:18:02.402,0:18:05.998
Hetzner-Netzes zu trennen. Es gibt da auf[br]der wireguard-Mailingliste eine

0:18:05.998,0:18:09.995
Diskussion, die ist aktuell aber leider[br]eher eingeschlafen. Also wireguard kann

0:18:09.995,0:18:14.774
dieses VRF noch nicht. Mit iprule kriegt[br]man das hin, das ist auch nicht sonderlich

0:18:14.774,0:18:20.113
großartig und es frisst natürlich MTU.[br]Also Wireguard. Ihr wollt, wenn ihr so was

0:18:20.113,0:18:24.943
macht, strikte Firewall-Regeln haben um[br]Leaks zu unterbinden. Das heißt ihr wollt

0:18:24.943,0:18:30.913
nicht versehentlich aus eurem internen[br]Netz Pakete mit eurer source IP an das

0:18:30.913,0:18:37.491
Hetzner Default-Gateway senden. Das wäre[br]uncool. Weil Hetzner weiß ja nicht, oder

0:18:37.491,0:18:42.275
kennt ja euer AS nicht oder euer NAT[br]nicht. Für Hetzer ist das ja ein externes

0:18:42.275,0:18:47.330
Netz, weil ihr da kein BGP upstream habt.[br]Also da wirklich aufpassen, was ihr da

0:18:47.330,0:18:51.976
baut. Vorher verstehen und dann bauen.[br]Mein Routing mache ich mit bird2 unter

0:18:51.976,0:18:58.944
Linux, OSPF als interior gateway-[br]Protokoll, IBGP zwischen allen größeren

0:18:58.944,0:19:02.641
Standorten. Ist im wesentlichen[br]Geschmackssache, wie man das baut. Da gibt

0:19:02.641,0:19:05.830
es auch verschiedenste Möglichkeiten.[br]Weiterhin das Thema Administration.

0:19:05.830,0:19:13.675
Benutzt Konfigurationsmanagement. Ich[br]benutz Saltstack mit Ansible oder anderen

0:19:13.675,0:19:18.860
Tools geht das garantiert auch. Nur das[br]wächst so schnell an, da kriegt ihr dann

0:19:18.860,0:19:22.292
in die BGP-Filter, in die BGP-[br]Konfiguration, in die Firewall Regeln

0:19:22.292,0:19:26.302
keine Konsistenz mehr rein, wenn ihr das[br]nicht, ich sage mal systematisch ausrollt

0:19:26.302,0:19:31.490
und per config management sicherstellt,[br]dass das System stabil und konsistent

0:19:31.490,0:19:39.262
läuft. Kommen wir so langsam zum Ende. Was[br]wäre noch cool für das Projekt? Weg von

0:19:39.262,0:19:46.114
den IXP-VMs, hin zum echten Blech, was da[br]steht und Pakete routet oder auch Dienste

0:19:46.114,0:19:51.879
hostet. Ist natürlich aufwendiger und[br]teurer, das mit echtem Blech zu machen.

0:19:51.879,0:19:57.558
Ist eine Option für die Zukunft. Und[br]echter Layer 2 Transport statt Overlay

0:19:57.558,0:20:02.471
wäre natürlich auch cool. Frisst mir dann[br]nicht mehr die MTU weg und so weiter. Ist

0:20:02.471,0:20:06.881
aber gerade was Standorte, Konnektivität[br]etc. betrifft nicht ganz trivial und auch

0:20:06.881,0:20:11.203
nicht ganz billig. Sollte man definitiv[br]machen, wenn das Netz produktiv wird,

0:20:11.203,0:20:17.547
solange es irgendwie ein Best Effort[br]Bastelnetz ist oder Privat-Netz ist, ist

0:20:17.547,0:20:25.105
das so eigentlich in Ordnung. Fazit: Würde[br]ich es noch mal machen? Definitiv, v6-only

0:20:25.105,0:20:30.078
mit wenigen Legacy IP-Adressen auf den[br]Edges ist durchaus sinnvoll machbar.

0:20:30.078,0:20:34.060
Kostentechnisch ist es eh schon[br]interessant. Gerade Hetzner hat jetzt vor

0:20:34.060,0:20:39.854
kurzem ja angekündigt, dass v4 zukünftig[br]extra kosten wird oder es ohne V4 billiger

0:20:39.854,0:20:44.939
wird. Also ja, das mache ich definitiv[br]weiter so und würde das auch in neuen

0:20:44.939,0:20:48.412
Projekten so machen, dass ich V4 nur noch[br]auf den Edges habe, auch im privaten

0:20:48.412,0:20:52.988
Umfeld. Ihr habt ja gesehen, dass ist[br]nicht sonderlich kompliziert. Der Aufbau

0:20:52.988,0:20:58.021
mit diesen IXP-VMs und Tunneln dazwischen[br]ist okay für private best effort services.

0:20:58.021,0:21:02.205
Ihr hört schon, ich bin nicht so ganz[br]überzeugt. Also es ist nicht für wirklich

0:21:02.205,0:21:07.375
produktive Produktiv-Netze geeignet. Also[br]nichts, was Geld verdient etc. Dafür Layer

0:21:07.375,0:21:11.878
2 Transport, ordentliche Peerings,[br]ordentlicher Transit, ordentliche

0:21:11.878,0:21:16.961
Hardware. Aber das ist ja hier an der[br]Stelle auch nicht Ziel des Ganzen. Und

0:21:16.961,0:21:22.190
damit bin ich am Ende. Vielen Dank fürs[br]Einschalten, fürs Zuhören. Und wenn ihr

0:21:22.190,0:21:27.015
Fragen habt, sendet gerne eine Mail an rc3[br]at ipv6.church.

0:21:27.015,0:21:35.195
Herald: Und dann sind wir wieder zurück[br]hier. Vielen Dank an margau für den Talk.

0:21:35.195,0:21:40.298
Es gibt leider kein Q&A, weil margau mit[br]der C3 Infrastruktur beschäftigt ist. Aber

0:21:40.298,0:21:44.643
wie ihr gesehen habt, könnt ihr ihr eine[br]Mail schreiben an die gerade eingeblendete

0:21:44.643,0:21:48.628
Email-Adresse. Hier auf dem FEM-Channel[br]geht es jetzt gleich weiter um 19 Uhr mit

0:21:48.628,0:21:52.957
der nächsten Herald News Show und um 20:15[br]Uhr mit votti zu NetBox als Datenquelle

0:21:52.957,0:21:55.170
für Netzwerkinfrastruktur. Bis dahin.

0:21:55.170,0:22:20.000
Untertitel erstellt von c3subtitles.de[br]im Jahr 2023. Mach mit und hilf uns!