1 00:00:00,000 --> 00:00:03,630 Herald: Hallo und herzlich willkommen auf dem FEM Kanal und zu unserem ersten Talk 2 00:00:03,630 --> 00:00:08,880 heute von margau. Margau hat irgendwann mal angefangen bei Freifunk und ist dann 3 00:00:08,880 --> 00:00:13,170 irgendwann immer professioneller geworden und inzwischen beim C3 Infrastructure Team 4 00:00:13,170 --> 00:00:18,270 angekommen. Kümmert man sich also jetzt genau gerade um die RC3 World und das 5 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 6 00:00:22,260 --> 00:00:28,380 Talk, denn der Talk ist aufgezeichnet. Margau ist busy mit dem Betrieb, so. Es 7 00:00:28,380 --> 00:00:36,060 geht um IPv6 und zwar nicht wie sonst immer mit ... v4 zusammen, sondern 8 00:00:36,060 --> 00:00:41,790 standalone. Also quasi das, was der Traum eines jeden Netzwerkers unter 40 Jahren 9 00:00:41,790 --> 00:00:48,330 ist. Er wird ein paar Erfahrungen weitergeben und Tipps, falls wir das auch 10 00:00:48,330 --> 00:00:51,450 alle mal machen wollen, dann... for the English speaking viwers, there will be a 11 00:00:51,450 --> 00:01:00,420 translation. To listen to it, select on the language selection select the first 12 00:01:00,420 --> 00:01:05,487 translated option to hear the english translation. Und jetzt viel Spaß beim Talk 13 00:01:05,487 --> 00:01:08,819 mit Margau. [placeholder remove me in amara] 14 00:01:08,819 --> 00:01:14,468 margau: Ja hallo, ich bin margau. Schön, dass ihr eingeschaltet habt zu meinem Talk 15 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 16 00:01:19,815 --> 00:01:26,841 2021. Genau. Worum geht es bei meinem Talk heute? Wie betreibe ich ein richtiges Netz 17 00:01:26,841 --> 00:01:32,012 mit IPv6-Focus oder soweit es geht IPv6-Only. Bisschen, meine Erfahrungen. 18 00:01:32,012 --> 00:01:37,896 Welche Probleme habe ich gefunden, welche Lösungen und natürlich auch ein bisschen 19 00:01:37,896 --> 00:01:42,356 Inspiration, was ihr für eure Netze für eure Dienste mitnehmen könnt, damit 20 00:01:42,356 --> 00:01:46,905 vielleicht auch ihr dann in der Lage seid IPv6-Only zu sprechen, wenn ihr es noch 21 00:01:46,905 --> 00:01:52,323 nicht macht. Vorher, bevor wir loslegen aber erst mal ein Disclaimer. In dem Talk 22 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 23 00:01:57,480 --> 00:02:03,120 haben einen AS, wir haben IP-space der BGP mit dem Rest des Internets spricht. Das 24 00:02:03,120 --> 00:02:08,154 ganze ist kein Spielzeug! Betrieb eines AS's ist deutlich mehr als einfach nur 25 00:02:08,154 --> 00:02:12,051 irgendwo eine virtuelle Maschine klicken und da einen Linux drauf zu installieren 26 00:02:12,051 --> 00:02:15,901 und einen Webserver hochzuziehen oder so. Also überlegt euch wirklich gut, ob ihr 27 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 28 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 29 00:02:28,863 --> 00:02:33,885 Üben und ums Spielen mit BGP, mit Internet, mit Routing geht, gibt z.B. das 30 00:02:33,885 --> 00:02:38,534 den DN42, das ist ein virtuelles Overlay- Netz und das ist dafür sehr gut geeignet. 31 00:02:38,534 --> 00:02:43,719 Aber das sollte man nicht direkt produktiv im Internet tun. Genau, dann nachdem der 32 00:02:43,719 --> 00:02:49,410 Formalkram geklärt is, machen wir mal weiter mit der Terminologie. Ich werde in 33 00:02:49,410 --> 00:02:56,101 dem Talk ein paar Begriffe häufig nutzen, nämlich IP oder richtiges IP meint 34 00:02:56,101 --> 00:03:03,014 natürlich IPv6, das Moderne die 128 Bit Variante und wenn ich von Legacy IP 35 00:03:03,014 --> 00:03:09,287 spreche, meine ich damit IPv4, die alter 32 Bit Variante. Genau. Aber wie hat das 36 00:03:09,287 --> 00:03:14,215 ganze eigentlich angefangen? Irgendwann in 2020 habe ich mir gedacht, so 37 00:03:14,215 --> 00:03:20,203 Infrastruktur betreibe ich eigentlich schon lange genug, mehrere Jahre. Das DN42 38 00:03:20,203 --> 00:03:25,677 und auch bei anderen Möglichkeiten, Routing etc. auch schon einiges an 39 00:03:25,677 --> 00:03:30,930 Erfahrung gesammelt. Es hat sich in ein ganzer Zoo an Diensten angesammelt, der 40 00:03:30,930 --> 00:03:36,700 mal einen ordentlichen Neubau brauchte. Von daher so langsam lohnt sich eigentlich 41 00:03:36,700 --> 00:03:42,141 ein richtiges Netzwerk, oder? Was brauche ich denn für ein richtiges Netzwerk? Ich 42 00:03:42,141 --> 00:03:46,115 brauche erst mal ein Autonomes System. Das kann ich, wenn ich nicht selbst RIPE- 43 00:03:46,115 --> 00:03:51,137 Mitglied werde, von einem Sponsoring LIR bekommen. Ich brauche Konnektivität. Also 44 00:03:51,137 --> 00:03:56,881 irgendwie muss ich ja meine IP Adressen meines Autonomen Systems ins Internet 45 00:03:56,881 --> 00:04:02,610 bringen. Da gibt es virtuelle Maschinen mit IXP, also Internet Exchange Points 46 00:04:02,610 --> 00:04:08,505 Anbindung. Es gibt virtuelle Maschinen mit BGP Upstream. Also auch das ist nicht das 47 00:04:08,505 --> 00:04:14,100 Problem. Zuletzt brauche ich natürlich im Netz noch IP Adressen. Richtiges IP, also 48 00:04:14,100 --> 00:04:21,547 IPv6, auch kein Problem. Gibt es zu Hauf, von RIPE bekommt man /48 PI als Provider 49 00:04:21,547 --> 00:04:29,210 Independent und das ist an einen selbst oder an die Organisation gebunden, aber 50 00:04:29,210 --> 00:04:36,464 nicht an den Provider, der jemandem das bereitstellt. Genau. Also v6 Adressen 51 00:04:36,464 --> 00:04:42,759 haben wir. Legacy IP-Adressen oder auch IPv4 Adressen genannt. Jetzt wird es 52 00:04:42,759 --> 00:04:47,436 langsam interessanter, gibt es nämlich nicht mehr. Wenn man mal auf die Seite der 53 00:04:47,436 --> 00:04:52,873 RIPE guckt, wie die RIPE-Mitglieder auf neue IPv4-Adressen warten, sieht man der 54 00:04:52,873 --> 00:04:57,866 Graph, die Warteliste steigt stetig an. Und ja, vermutlich hat es heute einen 55 00:04:57,866 --> 00:05:02,300 neuen Höchststand wie gestern, wie vorgestern, wie letzte Woche etc. Und auch 56 00:05:02,300 --> 00:05:07,784 der Gebrauchtmarkt, nenne ich es mal, für IPv4-Adressen ist jetzt nicht gerade so 57 00:05:07,784 --> 00:05:15,022 toll, da bezahlt man definitiv einen zweistelligen Betrag in mittlerer Größe 58 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 59 00:05:22,162 --> 00:05:27,558 eigentlich für so ein privates Best Effort Projekt allein aus finanzieller Sicht 60 00:05:27,558 --> 00:05:33,848 schon keine wirkliche Lösung mehr. Was macht man also? Einfach nur IPv6? Weil 61 00:05:33,848 --> 00:05:39,710 IPv6 haben wir ja. Ist kein Problem oder ist kein Problem, das zu bekommen. Machen 62 00:05:39,710 --> 00:05:44,360 wir IPv6 only. Als nächstes habe ich mir überlegt, was soll mein Netz eigentlich 63 00:05:44,360 --> 00:05:50,000 machen? Ich habe dann so eine kleine Liste an Diensten, die ich betreibe, die auch in 64 00:05:50,000 --> 00:05:53,510 dieses Netz dann umziehen sollen. Natürlich ein klassischer Webserver mit 65 00:05:53,510 --> 00:05:58,880 einem Blog dahinter, eine Nextcloud, einen Hedgedoc, über den übrigens gerade diese 66 00:05:58,880 --> 00:06:05,990 Präsentation hier läuft. Mailserver, kommen wir später noch zu und auch noch 67 00:06:05,990 --> 00:06:09,020 das eine oder andere, je nachdem wie gerade Bedarf ist. Aber wenn man sich 68 00:06:09,020 --> 00:06:14,120 diese Liste anguckt, merkt man das nutzen tatsächlich Menschen. Also es ist nicht 69 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 70 00:06:19,070 --> 00:06:23,780 vielleicht das eine oder andere Mal mit diesen Diensten interagieren. Was macht 71 00:06:23,780 --> 00:06:29,150 man jetzt aber, wenn die Nutzer der Dienste nur Legacy IP haben? Wir haben ja 72 00:06:29,150 --> 00:06:33,280 eben gesagt, wir machen ein IPv6 only Netz. Kann man in mehreren Stufen lösen. 73 00:06:33,280 --> 00:06:38,590 Step 1, so mittelmäßig ernst gemeint, Awareness schaffen. Ihr seht hier diese 74 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 75 00:06:43,240 --> 00:06:48,130 besuchst diese Seite mit einem veralteten IPv4-Internetzugang. Möglicherweise treten 76 00:06:48,130 --> 00:06:51,730 in Zukunft Probleme mit der Erreichbarkeit und Performance auf. Bitte frage deinen 77 00:06:51,730 --> 00:06:56,260 Internetanbieter oder Netzwerk- Administrator nach IPv6-Unterstützung. Was 78 00:06:56,260 --> 00:07:00,100 ist die Idee dahinter? Wenn das genug Leute machen, wirds zu einem Marketing 79 00:07:00,100 --> 00:07:04,720 Problem wenn ein Netz oder ein Provider kein IPv6 kann, also kein richtiges IP 80 00:07:04,720 --> 00:07:09,310 anbieten. Und damit wird sich das Problem lösen, weil dann hoffentlich mehr 81 00:07:09,310 --> 00:07:14,530 richtiges IP anbieten etc. Das ist eine schöne Diskussion für Twitter, wenn ich 82 00:07:14,530 --> 00:07:18,940 ehrlich bin. Wie gesagt, ist nicht so ganz ernst gemeint, aber falls ihr das auch 83 00:07:18,940 --> 00:07:25,630 machen wollt, wie habe ich das Ding gemacht? nginx hat eine Weiche drin. Ob 84 00:07:25,630 --> 00:07:31,030 der Request per richtigem IP oder per Legacy IP kam. Und wenn er herausfindet, 85 00:07:31,030 --> 00:07:36,820 dass der Request per Legacy IP kam, ersetzt er den schließenden Body-Tag mit 86 00:07:36,820 --> 00:07:40,780 diesem Banner und natürlich einem schließenden Body-Tag. Aber in Summe ist 87 00:07:40,780 --> 00:07:44,830 eine nette Spielerei, hilft aber nichts, solange das nicht sehr sehr viele 88 00:07:44,830 --> 00:07:52,660 Webseiten etc. machen. Naja, also Step 1 naja. Brauchen wir also doch Legacy IP 89 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, 90 00:07:59,950 --> 00:08:07,390 dass eine geringe Anzahl an Kisten doch noch eine Legacy IP Adresse bekommt. Bei 91 00:08:07,390 --> 00:08:12,238 mir heißen die Gateways, kann man nennen wie man will. Genau. Und auf diesen Kisten 92 00:08:12,238 --> 00:08:17,663 läuft dann ein nginx und der verteilt quasi die Anfragen an die Legacy IP 93 00:08:17,663 --> 00:08:25,300 Adresse nach Port. Heißt, wenn eine Anfrage an TCP Port 80 kommt, über Legacy 94 00:08:25,300 --> 00:08:33,760 IP weiß nginx, schickt es an an den und den Server mit richtigem IP etc. weiter. 95 00:08:33,760 --> 00:08:39,700 Nachteil ist dann natürlich, man braucht für jeden Dienst der einen auf dem schon 96 00:08:39,700 --> 00:08:44,920 belegten Port was macht, eine neue IP Adresse oder neue Public V4 Adresse, weil 97 00:08:44,920 --> 00:08:49,150 sonst kann man es ja nicht, sondern auseinander sortieren. Heißt natürlich 98 00:08:49,150 --> 00:08:55,390 besonders für http und https, dass ich mir da ein zentrales Reverse Proxy Gateway 99 00:08:55,390 --> 00:08:58,990 gebaut habe, weil ich sonst viel zu viele Gateways brauche, um das auseinander zu 100 00:08:58,990 --> 00:09:03,970 sortieren. Ich habe da auch mal ein Beispiel-Config. Man sieht hier den nginx 101 00:09:03,970 --> 00:09:09,820 stream Block, das ist nicht der standard nginx http Teil, sondern eben auf Layer 4, 102 00:09:09,820 --> 00:09:16,720 also TCP oder UDP. Man spezifiziert dann hier ein upstream DNS-UDP-Backend in dem 103 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 104 00:09:21,640 --> 00:09:27,100 einem Port, wo das ganze hingeschickt werden soll und sagt dem nginx dann: Hier 105 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 106 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 107 00:09:39,940 --> 00:09:43,870 andere, das dann an das entsprechende Backend weiterleitet. Das Ganze gibt es 108 00:09:43,870 --> 00:09:49,360 hier drunter noch mal für die TCP Variante, genau. Also, eigentlich auch 109 00:09:49,360 --> 00:09:54,940 kein Hexenwerk, das ganze zu machen. Wie sieht das praktisch aus? Interne Dienste, 110 00:09:54,940 --> 00:09:59,710 die nicht von außen erreichbar sein sollen oder müssen, haben bei mir generell nur 111 00:09:59,710 --> 00:10:06,745 eine Public V6 Adresse. Das heißt, wenn wir beim DNS bleiben, ein hidden Primary 112 00:10:06,745 --> 00:10:12,790 hat nur eine einzige V6 Adresse. Das ist auch die drauf konfigurierte, darunter ist 113 00:10:12,790 --> 00:10:19,030 er erreichbar, aber er brauch ja kein V4, wenn keine Endnutzer von V4, die nur V4 114 00:10:19,030 --> 00:10:25,780 haben, von außen drauf zugreifen müssen. Nehmen wir mal ein Beispiel den Secondary, 115 00:10:25,780 --> 00:10:30,760 der von Endnutzern erreichbar sein soll. Der Hostname und die IP, die die Kiste 116 00:10:30,760 --> 00:10:37,690 selbst hat, ist weiterhin v6 only, wie man hier im oberen Beispiel erkennen kann. Die 117 00:10:37,690 --> 00:10:42,580 Endnutzer kriegen dann aber einen anderen Hostnamen, hier z.B. ns1.example.com. Und 118 00:10:42,580 --> 00:10:47,680 der geht für richtiges IP einmal direkt auf die konfigurierte Adresse. Da hängt 119 00:10:47,680 --> 00:10:51,940 kein Gateway mehr dazwischen etc. Das ist natürlich direkte Ende zu Ende 120 00:10:51,940 --> 00:10:57,700 Kommunikation. Genau. Und die V4 Adresse geht an dieses nginx stream Gateway, was 121 00:10:57,700 --> 00:11:01,840 wir eben gesehen haben, was dann natürlich entsprechend konfiguriert sein muss, dass 122 00:11:01,840 --> 00:11:09,490 es auf Port 53 eingehende Anfragen entsprechend behandelt. Das Thema Wie 123 00:11:09,490 --> 00:11:14,980 sprechen Endnutzer mit den Servern ist jetzt gelöst. Wie sprechen aber jetzt die 124 00:11:14,980 --> 00:11:20,530 Server nach außen? Das Problem ist, manche Endpunkte haben kein richtiges IP. Da gibt 125 00:11:20,530 --> 00:11:25,120 es nur sehr sehr bekannte GIT Webseite, die aktuell noch nicht per IPv6-only 126 00:11:25,120 --> 00:11:29,290 bedienbar ist oder erreichbar ist. Was macht man also? The same procedure as 127 00:11:29,290 --> 00:11:33,580 every time. Wenn man ein Netzwerkproblem hat und insbesondere ein 128 00:11:33,580 --> 00:11:38,200 Adressierungsproblem macht man natürlich NAT. Diesmal nur nicht ganz so schlimm. 129 00:11:38,200 --> 00:11:42,700 Wir machen nicht NAT 44, sondern wir machen NAT 64. Das heißt wir NATen im 130 00:11:42,700 --> 00:11:47,020 Prinzip Adressen zwischen dem IPv6-Adressraum und dem IPv4-Adressraum. 131 00:11:47,590 --> 00:11:51,010 Das ganze will ich jetzt nicht im Detail erklären. Das ist ein eigener Talk. Da 132 00:11:51,010 --> 00:11:55,780 gibt es auch mehr als genug Infos und Literatur dazu, wie dieses NAT 64 133 00:11:55,780 --> 00:12:00,460 eigentlich funktioniert. Zumindest wenn ihr im Telekom-Mobilfunknetz seid, ist die 134 00:12:00,460 --> 00:12:05,110 Chance, dass ihr das unwissentlich schon benutzt relativ groß, weil meines Wissens 135 00:12:05,110 --> 00:12:10,150 macht die das Telekom das per Default oder bietet das per default an. Genau, die 136 00:12:10,150 --> 00:12:16,270 Realisierung bei mir ist: Ich habe diesen Common Präfix, diesen V6 Präfix, wo der 137 00:12:16,270 --> 00:12:22,390 gesamte IPv4 Adressraum drin abgebildet werden kann. Dieser /96 Präfix wird im 138 00:12:22,390 --> 00:12:31,060 internen Netz von den 64-Gateways announced um quasi den Devices die Routen 139 00:12:31,060 --> 00:12:38,470 dahin anzubieten, also per ITP genau. Und wenn eine IPv6-only Kiste jetzt auf eine 140 00:12:38,470 --> 00:12:43,930 IPv4-only Resource im Internet zugreifen will, macht sie eine Anfrage an einen 141 00:12:43,930 --> 00:12:47,920 entsprechend konfigurierten DNS resolver, der genau eine Adresse in diesem Range 142 00:12:47,920 --> 00:12:52,390 zurückgibt. So Resolver gibt es haufenweise, kann man selbst hosten. 143 00:12:52,390 --> 00:12:56,410 Google hat da was, Cloudflare hat da was, das ist auch alles ein gelöstes Problem, 144 00:12:56,410 --> 00:13:04,270 einfach mal DNS 64 resolver googlen, da findet man was. Also sind wir eigentlich 145 00:13:04,270 --> 00:13:07,870 fertig. Wir können von innen nach außen kommunizieren und von außen nach innen. 146 00:13:07,870 --> 00:13:12,580 Gucken wir uns die Übersicht noch mal an. Von erstmal unten haben wir unser großes 147 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 148 00:13:17,860 --> 00:13:24,040 Edge-Router, der die Adressen ins Internet routet und umgekehrt. V6 Enduser gehen 149 00:13:24,040 --> 00:13:27,550 direkt über diesen Edge-Router Ende zu Ende zu dem Dienst unten auf der rechten 150 00:13:27,550 --> 00:13:34,660 Seite. Oben sehen wir noch Legacy End User. Der muss den Umweg über unser TCP 151 00:13:34,660 --> 00:13:41,650 UDP Legacy to V6 Proxy nehmen. Das ist die nginx stream Config, die wir eben gesehen 152 00:13:41,650 --> 00:13:47,020 haben. Auf der linken Seite nochmal zusammengefasst das, was ich eben kurz 153 00:13:47,020 --> 00:13:53,406 erklärte, wie Native V6 only Services mit Legacy only Ressourcen kommunizieren, 154 00:13:53,406 --> 00:13:58,265 nämlich über ein Nat64 Gateway, was quasi auch an der Kante des IPv6-only Netzes 155 00:13:58,265 --> 00:14:04,931 steht. Und vorher müssen sie noch einen DNS64-Resolver natürlich fragen, um erst 156 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 157 00:14:10,007 --> 00:14:14,440 the box funktioniert und man nicht den ein oder anderen problematischen Dienst an der 158 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 159 00:14:21,314 --> 00:14:26,015 kompliziert, weil Reverse-DNS etc., das muss alles passen, sonst werden E-Mails 160 00:14:26,015 --> 00:14:30,422 abgelehnt. Gleichzeitig ist E-Mail für mich ein sehr kritischer Dienst. Von da 161 00:14:30,422 --> 00:14:35,025 habe ich einfach von Anfang an gesagt Der lebt nicht IPv6-only, der kriegt eine 162 00:14:35,025 --> 00:14:39,467 eigene V4 und oder läuft sogar ganz außerhalb. An der Stelle noch mal, 163 00:14:39,467 --> 00:14:43,833 überlegt euch gut, ob ihr einen eigenen Mailserver betreiben wollt. Wenn ihr das 164 00:14:43,833 --> 00:14:47,290 noch nicht macht, das ist administrativ nicht ganz einfach, wenn nicht sogar das 165 00:14:47,290 --> 00:14:52,916 Komplizierteste an der ganzen Geschichte hier, einen verfügbaren funktionierenden 166 00:14:52,916 --> 00:14:58,423 Mailserver zu betreiben. Ein weiteres Problem, was ich hatte mit der netten 167 00:14:58,423 --> 00:15:02,648 Software Matrix Synapse, ein Home Server für Matrix, also Instant Messaging. An 168 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 169 00:15:07,245 --> 00:15:11,217 verschickt und die kann kein Happy Eyeballs. Das heißt, wenn die versucht 170 00:15:11,217 --> 00:15:16,821 sich zu diesem SMTP Server, der eine V4 oder V6 Adresse hat zu connecten, ähm aber 171 00:15:16,821 --> 00:15:21,861 den über Legacy nicht erreichen kann, weil eine V6-only Kiste natürlich keine 172 00:15:21,861 --> 00:15:26,938 default route für eine legacy IP-Adresse hat, hört die einfach auf zu 173 00:15:26,938 --> 00:15:31,271 funktionieren. Also es gibt ein Timeout, sie kann es nicht erreichen. Habe ich noch 174 00:15:31,271 --> 00:15:35,344 nicht gelöst. Gibt ein GitHub issue dazu, müsste man wahrscheinlich mal etwas viel 175 00:15:35,344 --> 00:15:40,895 Zeit rein investieren und dann ist auch das Thema gefixt. Aber aktuell ist es noch 176 00:15:40,895 --> 00:15:46,076 kaputt. Docker ist auch so ein Thema. Wenn man das entsprechend konfiguriert und die 177 00:15:46,076 --> 00:15:50,423 Zeit reinsteckt, läuft es dann per V6, per Default nicht so wirklich, ist eher 178 00:15:50,423 --> 00:15:56,500 anstrengend, sich um Docker in V6-only zu kümmern, geht aber wenn man will. Weniger 179 00:15:56,500 --> 00:16:02,720 toll ist das ganze mit Gitlab Runnern. Ich habe mal versucht ein GitLab Run in dieses 180 00:16:02,720 --> 00:16:07,121 V6-only Netz zu stellen. Die Kommunikation zwischen Containern klappte dann irgendwie 181 00:16:07,121 --> 00:16:10,856 nicht, wenn man Docker in Docker gemacht hat und dann noch irgendwie docker Service 182 00:16:10,856 --> 00:16:14,847 containern brauchte. Eventuell muss ich das Ding auf V4 only zurückbauen und dann 183 00:16:14,847 --> 00:16:19,175 irgendwie so eine CLAT da hinstellen. Also ohne jetzt ins Detail zu gehen. Alles ganz 184 00:16:19,175 --> 00:16:23,588 schrecklich. Ist aktuell weiterhin kaputt. Noch so ein Thema, wenn ich per https ins 185 00:16:23,588 --> 00:16:33,366 Heimnetz will, aber das eben nicht über einen Dyn-DNS machen will, sondern über 186 00:16:33,366 --> 00:16:40,441 einen direkt angebundenen, über VPN angebundenen Jumphost, nenne ich es mal, 187 00:16:40,441 --> 00:16:44,914 ist das ein bisschen kompliziert, je nachdem, wie man sein Netz aufbaut. Mein 188 00:16:44,914 --> 00:16:50,270 OpenVPN-Server steht im IPv6-only Teil. Das funktioniert auch. Kam trotzdem nicht 189 00:16:50,270 --> 00:16:56,958 drumrum, ein Reverse Proxy Channing, also quasi ein NAT für HTTP zu bauen. Ist nicht 190 00:16:56,958 --> 00:17:03,086 schön, ginge bestimmt anders. Anders wäre das halt deutlich zeitaufwändiger. Dann 191 00:17:03,086 --> 00:17:08,216 kommen wir mal zum letzten wichtigen Teil: Konnektivität, Routing und Administration. 192 00:17:08,216 --> 00:17:14,059 Das ist jetzt nicht mehr so stark auf IPv6-only bezogen. Eher generell. Ich habe 193 00:17:14,059 --> 00:17:21,360 zwei Standorte mit BGP-Konnektivität nach außen, eine IXP-VM in Frankfurt und einmal 194 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 195 00:17:27,442 --> 00:17:32,773 zumindest für kleine Projekte auch verfügbar. Und dann habe ich noch weitere 196 00:17:32,773 --> 00:17:37,652 Projekte, weitere Standorte mit billigem Compute. Also die ganze Rechenleistung 197 00:17:37,652 --> 00:17:41,862 steht, wo ich aber leider kein BGP habe, zum Beispiel Hetzner. Heißt ich muss 198 00:17:41,862 --> 00:17:46,803 irgendwie zwischen diesen beiden Standorten kommunizieren können. Da musste 199 00:17:46,803 --> 00:17:52,179 ich mir, weil ich nichts besseres habe, einen Wireguard, also ein VPN-Overlay 200 00:17:52,179 --> 00:17:57,521 bauen. WAN-intern, läuft da getrennt über Policy Based Routing. iprule is your 201 00:17:57,521 --> 00:18:02,402 friend. VRFs wären besser, um quasi die Sicht des eigenen Netzes und die Sicht des 202 00:18:02,402 --> 00:18:05,998 Hetzner-Netzes zu trennen. Es gibt da auf der wireguard-Mailingliste eine 203 00:18:05,998 --> 00:18:09,995 Diskussion, die ist aktuell aber leider eher eingeschlafen. Also wireguard kann 204 00:18:09,995 --> 00:18:14,264 dieses VRF noch nicht. Mit iprule kriegt man das hin, das ist auch nicht sonderlich 205 00:18:14,264 --> 00:18:20,113 großartig und es frisst natürlich MTU. Also Wireguard. Ihr wollt, wenn ihr so was 206 00:18:20,113 --> 00:18:24,943 macht, strikte Firewall-Regeln haben um Leaks zu unterbinden. Das heißt ihr wollt 207 00:18:24,943 --> 00:18:30,913 nicht versehentlich aus eurem internen Netz Pakete mit eurer source IP an das 208 00:18:30,913 --> 00:18:37,491 Hetzner Default-Gateway senden. Das wäre uncool. Weil Hetzner weiß ja nicht, oder 209 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 210 00:18:42,275 --> 00:18:47,330 Netz, weil ihr da kein BGP upstream habt. Also da wirklich aufpassen, was ihr da 211 00:18:47,330 --> 00:18:51,976 baut. Vorher verstehen und dann bauen. Mein Routing mache ich mit bird2 unter 212 00:18:51,976 --> 00:18:58,944 Linux, OSPF als interior gateway- Protokoll, IBGP zwischen allen größeren 213 00:18:58,944 --> 00:19:02,641 Standorten. Ist im wesentlichen Geschmackssache, wie man das baut. Da gibt 214 00:19:02,641 --> 00:19:05,830 es auch verschiedenste Möglichkeiten. Weiterhin das Thema Administration. 215 00:19:05,830 --> 00:19:13,245 Benutzt Konfigurationsmanagement. Ich benutz Saltstack mit Ansible oder anderen 216 00:19:13,245 --> 00:19:18,860 Tools geht das garantiert auch. Nur das wächst so schnell an, da kriegt ihr dann 217 00:19:18,860 --> 00:19:22,292 in die BGP-Filter, in die BGP- Konfiguration, in die Firewall Regeln 218 00:19:22,292 --> 00:19:26,302 keine Konsistenz mehr rein, wenn ihr das nicht, ich sage mal systematisch ausrollt 219 00:19:26,302 --> 00:19:31,490 und per config management sicherstellt, dass das System stabil und konsistent 220 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 221 00:19:39,262 --> 00:19:45,544 den IXP-VMs, hin zum echten Blech, was da steht und Pakete routet oder auch Dienste 222 00:19:45,544 --> 00:19:51,879 hostet. Ist natürlich aufwendiger und teurer, das mit echtem Blech zu machen. 223 00:19:51,879 --> 00:19:57,558 Ist eine Option für die Zukunft. Und echter Layer 2 Transport statt Overlay 224 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 225 00:20:02,471 --> 00:20:06,881 aber gerade was Standorte, Konnektivität etc. betrifft nicht ganz trivial und auch 226 00:20:06,881 --> 00:20:11,203 nicht ganz billig. Sollte man definitiv machen, wenn das Netz produktiv wird, 227 00:20:11,203 --> 00:20:17,547 solange es irgendwie ein Best Effort Bastelnetz ist oder Privat-Netz ist, ist 228 00:20:17,547 --> 00:20:24,635 das so eigentlich in Ordnung. Fazit: Würde ich es noch mal machen? Definitiv, v6-only 229 00:20:24,635 --> 00:20:30,078 mit wenigen Legacy IP-Adressen auf den Edges ist durchaus sinnvoll machbar. 230 00:20:30,078 --> 00:20:34,060 Kostentechnisch ist es eh schon interessant. Gerade Hetzner hat jetzt vor 231 00:20:34,060 --> 00:20:38,744 kurzem ja angekündigt, dass v4 zukünftig extra kosten wird oder es ohne V4 billiger 232 00:20:38,744 --> 00:20:44,939 wird. Also ja, das mache ich definitiv weiter so und würde das auch in neuen 233 00:20:44,939 --> 00:20:48,412 Projekten so machen, dass ich V4 nur noch auf den Edges habe, auch im privaten 234 00:20:48,412 --> 00:20:52,988 Umfeld. Ihr habt ja gesehen, dass ist nicht sonderlich kompliziert. Der Aufbau 235 00:20:52,988 --> 00:20:58,021 mit diesen IXP-VMs und Tunneln dazwischen ist okay für private best effort services. 236 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 237 00:21:02,205 --> 00:21:07,375 produktive Produktiv-Netze geeignet. Also nichts, was Geld verdient etc. Dafür Layer 238 00:21:07,375 --> 00:21:11,528 2 Transport, ordentliche Peerings, ordentlicher Transit, ordentliche 239 00:21:11,528 --> 00:21:16,961 Hardware. Aber das ist ja hier an der Stelle auch nicht Ziel des Ganzen. Und 240 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 241 00:21:22,190 --> 00:21:27,015 Fragen habt, sendet gerne eine Mail an rc3 at ipv6.church. 242 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. 243 00:21:35,195 --> 00:21:40,298 Es gibt leider kein Q&A, weil margau mit der C3 Infrastruktur beschäftigt ist. Aber 244 00:21:40,298 --> 00:21:44,643 wie ihr gesehen habt, könnt ihr ihr eine Mail schreiben an die gerade eingeblendete 245 00:21:44,643 --> 00:21:48,628 Email-Adresse. Hier auf dem FEM-Channel geht es jetzt gleich weiter um 19 Uhr mit 246 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 247 00:21:52,957 --> 00:21:55,170 für Netzwerkinfrastruktur. Bis dahin. 248 00:21:55,170 --> 00:22:20,000 Untertitel erstellt von c3subtitles.de im Jahr 2023. Mach mit und hilf uns!