 Was machen wir heute? Die wunderbare List System Antikatoren bei Port Zero hält heute einen Vortrag über WireGuard. Also wunderschöne Alternative zu den ganzen alten Sachen, die wir mal benutzt haben IPsec und Co. Und damit wir sagen, fängst du an? Ja, hallo. Ich wurde schon vorgestellt, ich bin Liz und ich halte heute einen Vortrag über WireGuard. Also WireGuard ist ein recht neues Protokoll zu VPNs, wenn das überhaupt nichts sagt. Aber wer solltet alle die Beschreibung von Talk lesen haben? Genau, also mein Falleinnahmen ist Alissa Gerhardt, ich nutze sie, ihr Pronomen. Und ich habe eigentlich so 2014 bis 2019 im Bereich Future Internet geforscht, erst in Kaiserslautern als HIV und dann als wissenschaftliche Mitarbeiterin im KIT. Und seit 2020 bin ich eben Systemindikatorin bei Port Zero. Und so diese Schnittstelle zwischen Systemindikation, Netzwerk, da ist VPN halt so das Obvious Thema, was ich jetzt reden kann. An der Stelle will ich kurz ein Dank an meinen Arbeitgeber aussprechen, der mich tatsächlich dafür bezahlt hat, diesen Vortrag vorzubereiten. Ich rede heute, also ich rede über WireGuard, obviously. Ich fange an mit einem kurzen Überblick darüber, was WireGuard überhaupt ist. Gehe danach kurz darauf ein, wie man sehr schnell mit ein paar Zahlen Code WireGuard zwischen zwei Rechnern zumaufen bekommt. Gehe danach ein bisschen näher auf das Protokoll ein. Und im Anschluss werde ich dann auch kurz über die Performance davon sprechen und auch, wie man das Ganze in einem etwas größeren Stiladmins gehen würde. Und genau WireGuard ist ein vergleichsweise neues VPN Protokoll. So die ersten Spezifikationen, fertigen Spezifikationen, die man findet, sind so von 2018. Es basiert vollständig auf UDP. Es ist eigentlich auch vollständig peer-to-peer und ist ein Kryptografiezentreter Ansatz. Sprich, die Kryptografie ist einfach so tief in dieses Protokoll reingebaut, dass man sie nicht wirklich weglassen könnte. WireGuard funktioniert verbindungslos. Das hat so Vorteile, dass es Roaming unterstützt, also Clients, die ihre IP-Adressen ändern und auch andere Formen von Verbindungsabbrüchen auf Seiten 2.hosts einfach überlebt. Sobald Verbindung wieder da ist, die bestehende Kommunikation einfach fortgesetzt wird. Das heißt, irgendwie die Interfaces auf den Endgeräten zum Beispiel gehen nicht verloren, die bleiben da. Und es ist immer noch ein etwas merkwürdiges Erlebnis im Büro, mein Laptop zuzuklappen und dann den im Zug wieder aufzuklappen und immer noch SSH-Verbindungen und Ähnliches auf die Server zu haben. Und die solchen Neuverhandlungen dabei funktioniert dadurch eben komplett transparent und die Anwendungen bekommen das wirklich nicht mit, dass da was passiert ist, außer eben, weil er gerade minimiert außerdem die Angriffsfläche disputert. Das heißt, es ist einerseits unsichtbar in Port Scans, weil es eben einfach nicht antwortet auf nicht authentifizierte Nachrichten. Es hat einen eingebauten Schutz gegen den All-of-Service und es hat auch ein Replay-Schutz. Und wurde 2020 auch in den Jungskörnel integriert, was eben den Vorteil gibt, dass es im Körnelspace läuft und dadurch starke Performance-Vorteile hat gegenüber vielen anderen Anwendungen. Das Zentrale, was man verstehen muss, wenn man vorher gerade zumindest authentisiert, ist das sogenannte Crypto-Key-Routing. Das bedeutet, dass Piers anhand ihres statischen Public Keys identifiziert werden und eben jede Nachricht von ihren Sender jeweils authentifiziert ist. Und jeder Pier pflegt dabei eine Tabelle von anderen Piers. Diese Tabelle hat drei Spalten, das ist einerseits der Public Key bzw. die ID des entsprechenden Piers, dann die erlaubten IP-Adressen oder eine Liste von erlaubten IP-Adressen oder Adress-Räumen und sofern bekannt ein Internet-Endpunkt. Könnte jemand die Tür zu machen? Danke schön. Und man sieht schon, das Ganze sieht ein bisschen aus wie eine Routing-Tabelle, in der letztlich ziel-IP-Adressen oder ziel-IP-Adress-Räume stehen und der nächste Hopp dahin. Und genauso funktioniert das auch. So ist es einerseits die erlaubten IPs, von denen diese Piers senden dürfen, aber auch gleichzeitig gibt diese Tabelle an, in welche Richtung die IPs dann auch in welche Richtung diese IP-Adressen auch erreichbar sind. Und eine wichtige Sache an der Stelle ist noch, dass immer, wenn eine Nachricht empfangen wird und die Sender IP-Adresse abweicht, wird der Internet-Endpunkt an der Stelle geupdatet. Das heißt also, an der Stelle werden Geräte identifiziert und nicht die User oder so. Und wenn ein Gerät mobil ist, sobald es von der neuen IP-Adresse sendet, dann wird der andere Host diese IP-Adresse bei sich selbst updaten. Um schnell einen WireGuard VPN selbst zu machen zu bekommen, muss man es zunächst mal installieren. Das ist bei Linux recht einfach. Man könne 5.6 oder höher. Das ist so 2020. Auf einem system hat man das. Und dann installiert man sich rein entsprechend das Paket der eigenen Distribution. Das heißt meistens WireGuard Tools. Das stellt vor allem das Tool WG bereit und wer Netzwerke kennt, kennt auch das Tool IP bei Linux und letztlich reichen die beiden Tools aus, um WireGuard zu konfigurieren. Üblicherweise wird aber noch das Tool WG quick verwendet. Das ist eben ermöglicht, die gesamte WireGuard-Konfiguration eine einzige Konfigurationsdatei zu packen und dann auch über SystemD direkt zu steuern, also zu starten, zu stoppen, reloaden und so weiter. Unter MacOS, iOS, Android und Windows gibt es in der Regel grafische Clients. Die bekommt man auf wireguard.com. Die ermöglichten das Ganze in der GUI zu verwalten. Es gibt hier einen Edit-Button oder auch hinzufügen, entfernen und so weiter. Dann bekommt man einen Editor, der von diesen Tools auf Erhöhung gestellt wird. Das ist nicht ganz so ins System integriert. Es gibt auch andere Optionen. Über Homeboot bei Mac bekommt man auch direkt WG und WG quick wieder. Aber der übliche Weg, den ich gefunden habe, den ich in der Regel verwende, weil ich auf meinen Endgeräten eigentlich keine komplexe Konfiguration brauche und der auch so vorgeschlagen wird, ist eben über diese grafischen Tools zu gehen. Wenn man das Ganze installiert hat, dann kann man die wireguard eingebauten Funktionen nutzen, um Private- und Public-Key zu generieren. Das sind letztlich zwei Befehle. Einmal Gen-Key und einmal WG-Gen-Key und WG-PUB-Key. Der Public-Key lässt sich ebenfalls ständig aus dem Private-Key herleiten. Das hier ist ein etwas schrecklicher Art, mit Geheimnissen umzugehen. Was man eher macht, ist, dass man die nicht auf dem Bildschirm anzeigt, sondern direkt in Dateien speichert. Und an der Stelle sieht man auch, dass es auch, wie es junigst üblich ist, einfach Standard-Input, Standard-Output nutzt, um damit umzugehen, parametrisiert zu werden und so weiter. Und das lässt sich eben recht gut auch in andere Tools oder Frameworks etc. einbinden. Und ich merke man auch, dass das Ganze nicht wirklich parametrisierbar ist. WireGuard schreibt nämlich die Kryptografie, die verwendet wird, vollständig vor. Und da hat man als User gar nicht die Möglichkeit, das sich irgendwas auszusuchen. Einfaches kleinen Server-Setup sieht dann so aus. In dem Setup können Clients mit dem Server kommunizieren, aber es ist nichts wirklich eingerichtet, dass der Server Pakete weiterleitet oder sonst was. In dem Fall haben wir eben einen Client, der mit dem Server reden kann. Der Server hat mehrere Clients. Und die minimale Konfiguration besteht eben aus diesem Interface und einem PIA. Das eigene Interface beschreibt der Server sich eben, indem er einerseits die Interface-Adresse festgelegt wird. Der Private Key in der Konfig steht und noch ein UDP-Port angegeben wird, auf den der Server hören soll. Und dann hat der Server noch eine Liste von PIAs, die jeweils an ihrem Public Key identifiziert werden und eine eben ihre erlaubten IP-Adressen haben. Und der Client in dem Fall ist eigentlich genauso konfiguriert. Der eigentlich Unterschied hier ist, dass eben nur der Server als PIA eingetragen ist. Man könnte jetzt natürlich diesen zweiten PIA, den der Server kennt, auch noch bei dem Client eingeben. Und dann könnten alle drei miteinander reden, vorausgesetzt. Dieser zweite PIA hätte auch noch alle, hätte auch noch den entsprechenden Public Keys autorisiert. Wenn man sich eine Weiterleitung dann einrichten möchte, dass die Clients untereinander kommunizieren können und auch dass der Client vielleicht in das private Netz vom Server weitergeleitet wird. Das heißt also, man hat ein Server, der hat ein privates Netz, wie man es beim VPN üblicherweise hat und hat da mehrere Clients, die auch da reinsprechen wollen. Dann lässt es sich recht einfach handhaben, indem man wirklich mit IP-Tables einfach das Forwarding konfiguriert. Und dazu stellt in dem Fall WG Quick diese Hooks post up und post down zur Verfügung. Das können beliebige Kommandos sein, die man eben in der Shell auch geben könnte. Das kann auch ein Bash Script sein oder was auch immer man brauchte. Und genau wichtig an der Stelle ist, dass im Client dann auch vermerkt sein muss, dass der Server ein ganzes Subnetz hat und nicht nur ein einziger IP. Das heißt, worauf man achten sollte, ist, dass man einfach die richtige Subnetzmaske noch mitangibt. Für den Full Tunnel VPN ist letztlich die Konfig auch wieder ähnlich. Die gesamte Konfiguration davon passiert, wie gesagt, ein Betriebssystem. Das heißt, die IP-Tables-Kommandos werden hier ausgetauscht, dass man eben Netting eingerichtet. Und beim Client, damit der eben wirklich Full Tunnel ist, muss die gesamte, also muss wirklich 0.0.0.0.0 angegeben werden, um eben wirklich alle Pakete über dieses Interface zu leiten. So, das bringt mich dann jetzt dazu, wie dieses Protokoll überhaupt funktioniert. Die Kryptografie ist, wie gesagt, vollständig festgelegt. Es hat ein paar Vorteile. Es ist einerseits sehr einfach, damit die Auswahl von Cypher-Suits zu implementieren. Es vermeidet auch einfach Downgrade-Angriffe, weil es nichts gibt, wohin irgendein Pia ein Downgrade akzeptieren würde. Und auch unsichere Field-Konfigurationen, die Admins oder auch User vornehmen könnten, werden damit einfach ausgeschlossen. Der Nachteil an der Stelle ist natürlich, dass die User ihre eigene Krypto nicht austauschen können. Die genaue Kryptografie, die verwendet wird, ist eben Diffie-Helmen auf erleblichen Kurven für die Schlüsselaushandlung. Judge has 20 für die symmetrische Verschlüsselung. Das hat eine Schlüssellänge von 256 Spitzen und eben Black Toe für das Hashing und Message Authentication Codes. In der angewendet werden die eben so, dass einerseits jadische und kurzlebige Schlüsselpaare an Diffie-Helmen Schlüsselaustausch verwendet werden. Das heißt, man hat Perfect Forward Secrecy. Dabei werden die statischen öffentlichen Schlüssel nie direkt übermittelt. Das bedeutet, dass die Identität der beiden Pias wirklich verschleiert ist für alle, die mithören würden. Sofern die IP-Adresse eben auch nicht zuordnbar wäre. Und optional unterstützt es auch die Möglichkeit, noch einen symmetrischen Pre-Shared-Key zu verteilen. Da hat man eben das Problem, diesen Schlüssel zu verteilen. Die Idee davon ist aber, dass man jetzt schon Quantenangriffen gegen symmetrische Verfahren vorbeigen könnte. Die Begründung dahinter ist eben, dass zum Beispiel staatliche Agencies einfach die WireGuard-Kommunikation aufzeichnen könnten. Und die Hoffnung dahinter ist, dass der eigentliche Schlüsselaustausch aber längst verloren ist, bis eben Quantencomputer wirklich einsetzbar sind, diese Quantenangriffe realisierbar. Das Protokoll hat so ein paar Grundsätze. Generell basiert es auf dem IK-Pattern von dem Neues Protokoll-Framework, wem das was sagt. Da werde ich jetzt aber nicht weiter drauf eingehen, weil das ist ein bisschen wenig Zeit gerade. Alle Nachrichten sind grundsätzlich authentifiziert. Also die Handshakes, die stattfinden, werden eben durch die Publicies ihrer Sender jeweils authentifiziert und Payload wird dann durch den symmetrischen Sitzungskey, der aus dem Handshake ausgehandelt wird, authentifiziert. Und es bedeutet eben, dass WireGuard wirklich alle Nachrichten, die nicht authentifiziert sind, verwerfen kann. Das hat Vorteile, wie zum Beispiel, dass Dossangriffe vermieden werden, wie zum Beispiel TCP-Synflatting, sollte bekannt sein, also dass einfach, wenn sehr viele Synpakete zu einem TCP-Socket kommen, dass eben sehr viel Arbeitsbreiche allokiert wird auf den Server, was den Server letztlich in den Knie zwingen kann, indem einfach alle Nachrichten von unbekannten Quellen verworfen werden, vermeidet man diese Art von Angriffen. Und auch Portscans können das nicht finden, weil um diesen Portscans sichtbar zu machen, bräuchte man schon Wissen darüber, welche Publicies überhaupt erlaubt sind bei dem Server. Sessions werden immer an die Mahnd aufgebaut. Das heißt, wenn eine Anwendung ein erstes Paket in das Netz schicken möchte, dann ist es unter Umständen von Woundtrip-Time Verzögerungen für die Anwendung, bis dieses Paket tatsächlich ankommt. Das ist nicht allzu viel und ist für die Anwendung in der Regel nicht merkbar. Und danach wird immer genau ein IP-Paket pro UDP-Datagramm versendet. Das UDP zu verwenden für VPNs bringt den Vorteil, dass die Pakete den grundlegenden Eigenschaften des Netzes erst mal unterliegen, also es gibt Paketverlust, es gibt Paketvertauschungen und so weiter. Anwendungen sind sowieso geschrieben, dass sie sich dagegen schützen können, wenn sie es brauchen. Und in manchen Fällen ist TCP tatsächlich ein großer Nachteil. Wie zum Beispiel im Fall von Internettelefonie oder so, wo es eben wichtig ist, dass Pakete eher rechtzeitig ankommen und es weniger wichtig ist, dass wirklich alles durchkommt. Genau, Datagramme werden immer an die letzte bekannte IP-Adresse des Piers gesendet. Das habe ich schon erwähnt. Was auch zu beachten ist noch, dass eigentlich ungefähr alle zwei Minuten der symmetrische Schlüssel durchgewechselt wird. Das heißt, etwa alle zwei Minuten findet ein neuer Handshack statt und es wird auf einen neuen Key damit gewechselt. Grundsätzlich funktioniert das Protokoll eben so, dass ein Handshack durchgeführt wird und danach Daten übertragen werden können. Dabei heißt der Pia, der das ganze Initiat eben initiator. Und der andere Pia heißt Responder. Es gibt einen zwei-wege-out Handshack und danach keine Daten übertragen werden. Beim Handshack geht es letztlich darum, erst mal einen gemeinsamen Zustand durch zwei Nachrichten herzustellen. Das Ganze basiert auf einen Diffy-Hellman-Schüssel-Austausch. Aber es werden durch Diffy-Hellman nicht direkt die symmetrischen Schlüssel ausgetauscht, sondern dadurch wird nur über mehrere kryptografische Schritte auf, bei denen ich selbst noch nicht so 100% durchgestiegen bin. Ich bin jetzt nicht unbedingt Expertin, was Kryptografie angeht, aber es findet Diffy-Hellman-Schüssel-Austausch quasi statt. Aber letztlich wird einfach nur dadurch ein gemeinsamer Zustand erzeugt, der dann genutzt wird, um daraus zwei symmetrische Schlüssel abzuleiten. Und zwei Schlüssel einfach, dann gibt es eben einen für jede Kommunikationsrichtung. Ich habe hier jetzt noch mal die genauen Rahmen aufgezeichnet. Schrieben letztlich initiärter Soesponder. Also die erste Nachrichten im Handshack hat erstmal eine Sender-ID, die man zum Beispiel auch die, an der Stelle vom Sender eben ausgewählt wird. Das ist die, das kennt man zum Beispiel auch von IP-Sack in SPI. Dann wird der flüchtige Public Key übertragen und ab dann werden eben schon Nachrichten verschlüsselt beziehungsweise authentiziert über AD. Und das eine ist eben einfach ein statischer Wert, der aber an der Stelle durch Diffy-Hellman schon abgesichert wird. Und danach der Time Stamp, der nochmal mit einem zweiten Diffy-Hellman-Austausch nochmal abgesichert wird. Zwei Diffy-Hellmans einfach, indem einmal der flüchtige Key und einmal der statische Key verwendet wird. Und das Ganze wird dann noch mit üblicherweise einer MAC abgesichert, der zweitermäßig Authentication Code ist in der Regel leer. Es sei denn, es kommt zum Cookie-Respawns, da komme ich gleich noch drauf. Und die Nachricht vom Respawner zum Initiator basiert letztlich auf dem gleichen Prinzip, bloß dass dabei eben sich die genauen Werte, die übertragen werden, ein bisschen unterscheiden. Time Stamp übrigens deshalb, um Replay-Angriffe zu verhindern. Datenübertragung dabei ist dann recht einfach. Das Ganze ist symmetrisch verschlüsselt, womit Traulichkeit und Authentizität der Daten gegeben ist. Dabei wird wie gesagt genau ein IP-Paket pro UDP-Data gekommen gegeben. Und dazu gibt es auch noch einen Counter, der nochmal Replay-Angriffe vermeidet. Wobei dabei eben der Empfänger jeweils ein Fenster von vergangenen Countern auch noch mit akzeptiert. Das ist einfach deshalb notwendig, weil eben Paketvertauschungen stattfinden können und man eventuell verwendete Pakete immer noch akzeptieren möchte und nicht sofort verwerfen. Für die Mitigation von DOS-Angriffen gibt es einen Cookie-Mechanismus, der ist optional. Den sollte der Respawner nutzen, wenn er unter Last ist. Die Cookies sind dabei so gestaltet, dass sie keine Zustandshaltung erfordern. Das Ganze funktioniert eben, indem auf die erste Handcheck-Initiation, die vom Initiator kommt, eine Cookie-Reply vom Respawner gesendet wird. Diese Cookie-Reply enthält letztlich hauptsächlich ein Cookie, das aus Teilen der Informationen aus der Handcheck-Initiation gebildet wird. Und der Sender sollte daraufhin nochmal eine völlig neue Handcheck-Initiation starten, also mit anderen Keys, die dann eine Mac2 enthalten, die auf dem Cookie passiert. Der Respawner kann sich daraus wieder den Cookie herleiten und dann überprüfen, ob die Mac2 korrekt gesetzt ist. Wenn sie korrekt gesetzt ist, dann den Handcheck normal fortsetzen. Es gibt wie gesagt eine Key-Vortation, die funktioniert so, dass alle zwei Minuten eine neue Session gestartet wird. Dabei ist der Initiator dafür verantwortlich, einen neuen Handcheck durchzuführen. Die Keys der letzten Sitzung bleiben dabei aber immer noch gültig für quasi eine weitere Runde, damit eben wieder Pakete, die immer noch in Transit sind, also die eventuell verspätet ankommen oder so, noch empfangen werden können. Die Session bleibt nicht nur für diese zwei Minuten gültig, sondern noch mal zwei Minuten länger. Die zweite Sache an der Stelle ist, dass der Respawner, nachdem er seine Handcheck-Respawns gesendet hat, keine Bestätigung vom Sender bekommen hat, dass diese Nachricht angekommen ist. Das heißt, der Respawner muss noch seine alten Keys benutzen, bis er zum ersten Mal ein Paket vom Sender mit einem neuen Key empfängt. Das bedeutet, dass der Respawner noch zusätzlich eine zukünftige Session halten muss und insgesamt sind es bis zu drei Sessions in meinem Speicher pro Kommunikationspaar. Jetzt noch ein paar Kleinigkeiten. Also Handshakes, Nachrichten können verloren gehen. Das ergibt das Timeouts, die sind auf fünf Sekunden gesetzt. Der Autor vom White Paper verweist selbst darauf, dass diese fünf Sekunden erst mal abiträr gesetzt sind und in der zukünftigen Arbeit ermittelt werden müsste, was ein sinnvoller Wert an der Stelle ist und auch Exponential Backup oder Ähnliches verwendet. Nach diesen fünf Sekunden wird eben ein neuer Versuch vom Initiator durchgeführt und dieser neue Versuch sollte auch wieder ein völlig neues Set an Schlüsseln enthalten und mit den neuen Keys durchgeführt werden. Es gibt außerdem Keep Alive Mechanismus, der eben sicherstellt, dass regelmäßig Nachrichten übertragen werden und sich verbindungsabbrüche erkannt werden. In Keep Alive Nachricht ist im Prinzip einfach eine normale Datennachricht, aber die eben ohne Payload übertragen wird und die wird pro Richtung nach zehn Sekunden ohne Datenübertragung durchgeführt. So, jetzt gehe ich noch kurz auf die Performance ein. Performance Eigenschaften von WireGuard sind eben einerseits, dass es im Kernelspace ist, was es WireGuard erlaubt, deutlich schneller auf Pakete zu reagieren und eben einfach die Performanceverteile von Kernelspace nutzen kann. Und WireGuard hat eine Schifre, die parallelisierbar ist, was zum Beispiel ein großer Vorteil gegenüber OpenVPN ist, was eben bedeutet, dass wirklich Multithreading und auch mehrere, also eigentlich alle Prozessor, keine gleichzeitig genutzt werden können, was gerade bei schnellen Verbindungen durchaus relevant ist, wo OpenVPN zum Beispiel große Probleme hat. Das ist jetzt die Performance-Messung, die von den Toren von WireGuard selbst durchgeführt wurde. Letztlich ist das ein Gigabit-Link, bei dem IPa3 über 30 Minuten gelaufen lassen wurde und ein Mittel gebildet wurde. An der Stelle ist noch zu sagen, dass OpenVPN im UDP-Mode läuft und man sieht zweimal IP-Sack. Dabei wurde das gewählte Ciphersword im Prinzip einmal an WireGuard in OpenVPN angepasst. Was im Ergebnis aus irgendeinem Grund nur der Durchsatz besprochen, bei dem man sieht, dass WireGuard das Gigabit eigentlich fast vollständig ausnutzen kann, während OpenVPN schon so weit 250 Megabits pro Sekunde in die Knie geht und IP-Sack auch nicht das Ganze vollständig ausnutzen kann. Dabei wird eben erwähnt, dass OpenVPN und IP-Sack auf 100% gelaufen sind, während WireGuard deutlich statt runter lag. Es ist auch zu sehen, dass die Ping-Zeit bei WireGuard deutlich geringer ist als bei OpenVPN. Es wird nicht wirklich darauf eingegangen, warum das der Fall ist. Was die Administration von WireGuard angeht, ich bin eben schon darauf eingegangen, wie das Ganze funktioniert. Letztlich ist das große Problem eben, dass man ein Cake Exchange braucht. Wenn man selbst ein internes Netz verwaltet, wo man Zugriff zu allen Geräten hat, ist das Verteilen von Public Keys kein großes Problem. Und WireGuard gibt dabei den Vorteil, dass es zustandslos ist und das hat wirklich sehr stabil funktioniert. Und eben, wenn es konfiguriert ist, wenig Wartungsaufwand hat, dass irgendwelche Verbindungen abbrechen, die dann automatisch neu gestartet werden müssen, was manchmal viel schlägt und so weiter. WireGuard eher, also ist mir noch nicht passiert, seit ich es nutze. Und meine Erfahrung ist auch, dass es dadurch eben recht, auch eine recht einfache Lösung ist, wirklich mehrere geschlossene, also interne Netze zur Verbindung verbinden. Ich nutze das jetzt so im Berufsleben, vor allem um die internen Netze zwischen verschiedenen Cloud-Providern zu einem großen internen Netz zusammenzuschließen. Und auch das funktioniert in meiner Erfahrung sehr stabil. Schwieriger wird das Ganze, wenn man einen VPN mit vielen Usern verwalten möchte. Weil gerade so in einem Unternehmens-Szenario hat man auch vor allem viele nicht technische User. Und man kann, im Optimalfall, übertragen man keine Private Keys. Und wenn man keine Private Keys übertragen will, hat man eben das Problem, dass die User erstmal ihren Private und Public Key überzeugen müssen, dann den Public Key übergeben müssen und man dann eben noch diesen Pia registrieren kann und gleichzeitig dem User eine Konfig geben muss. Das aber hat recht viel Interaktion zwischen dann Admins von dem entsprechenden Netzwerk und den einzelnen Usern. Und vor allem, wenn die User wenig Erfahrung haben, dann gibt es eben recht viele Stolperfallen. Zum Beispiel eben genau die Tatsache, dass die Private Key in der Konfiguration steht. Das heißt, ohne einen Wizard oder eine Benutzeroberfläche, die diesen Prozess erklärt, ist es schwer, muss man Usern irgendwie vermitteln, dass sie die ersten Teile der Konfig erzeugen, dann den Public Key daraus bekommen müssen und so weiter. Und genau, wie gesagt, in der Stelle einfach, es ist sehr viel Interaktion, die davon notwendig ist. Dazu kommt eben, dass viele User eventuell Private Public Keys so als Konzept nicht verstehen und dabei versehentlich ihre Schlüssel, also ihre Private Keys kompromittieren oder in ähnliche Stolperfallen damit tragen. Vor allem, weil das Ganze ist eine Konfig-Datei und in der steht ein Private Key drin. Unerfahrende Nutzer wird vielleicht öffentlich nach Hilfe fragen, warum es nicht funktioniert und dabei eine Konfig posten, in der der Private Key steht. Und die dritte Stolperfalle, die ich auch sehe, ist, dass eben Geräte und nicht User identifiziert werden. Die meisten User aber erwarten, dass, wenn sie ihre Konfiguration von einem Gerät auf das andere übertragen, dass reibungslos funktioniert. Das funktioniert auch, wenn man ein Gerät gleichzeitig verwendet. Das ist ja eben den Fall, dass jedes Mal, wenn ein Gerät Daten gesendet hat, plötzlich eine neue IP-Adresse beim Server angekommen ist und die Kommunikation, die zwischen den anderen Geräten im Server ist plötzlich unterbrochen, wird nicht mehr funktioniert und dadurch eben auch ständig neue Keys und Sitzungen ausgehandelt werden müssen. Es gibt zur Administration mehrere Frontends. Dazu sind so die bekanntesten WG UI, der Screenshotsrechts von WG UI. Üblicherweise verwalten die die gesamte kleinen Konfig inklusive Private Key. Das ist meiner Meinung nach kein großes Downgrade zu dem, was aktuell passiert. Wo meistens bei OpenVPN, wenn es auch mit Zertifikaten genutzt wird, meistens der Key direkt mit ausgeliefert wird und man eben schaut, dass man verschlüsselt, dann die gesamte VPN-Konfig überträgt. Allerdings nimmt es eben genau den Vorteil wieder raus, dass man bei WireGuard Private Key hat und man das eigentlich nicht übertragen müsste. Also in diesem QR-Code ist tatsächlich die gesamte Konfig drin als Datei, die man so dann direkt abspacern könnte. Das sind meine Quellen und damit bin ich fertig, ich bedanke mich und würde dann jetzt auch zum Q&A hier wechseln. Wunderbar, geil. Also vielen lieben Dank für den Talk erst mal. Wer hatte eine Frage Hand hoch und ich komme mit dem Mikro rum? Wunderbar. Darf ich ganz vorne anfangen? Ist okay für dich? Wunderbar, dann fangen wir ganz vorne an. Hallo. Ich bin der Axel. Die Frage wird den Namen raus. Bei der Einfolie, da habe ich mich gefragt, ob die Konfiguration jetzt für den Fall war, dass der Kleint sein Netzwerk zur Verfügung stellt oder umgekehrt? Bei der hier? Genau. Genau, also hier stellt der Server sein Netz zur Verfügung. Der Server ist derjenige, wo eben IP-Tables konfiguriert wird, dass eine Paketweiter-Latung stattfindet zwischen dem Interface von WireGuard, also dieses Minus-E, %E, %E ist ein Playsolder für das Interface von WireGuard und eben allen anderen Interfaces. Das ist genau so symmetrisch konfiguriert, dass Sie sich beide sehen können? Ja. Man müsste eben schauen, dass die IP-Adress-Räume entsprechend gesetzt sind, dass das Roteing funktioniert, aber ja, könnte man. Danke. Danke für den Vortrag. Wo wir jetzt einmal hier sind, verstehe ich das richtig, dass in der Konfiguration die IP-Adressen statisch gesetzt werden, ab einer gewissen Unternehmensgröße für die IP-Adressen. Ja. An der Stelle ist es eben so, dass man Geräte managt. Man managt keine User, sondern man managt Geräte. Und die Beispiele, die ich eben gebracht habe für die UIs, zum Beispiel, die funktionieren teilweise auch als Self-Service-Portale, das bedeutet, dass man da eine Authentifizierung braucht und dann können die User selbstständig ihre Geräte hinzufügen und entfernen. Und die zweite Frage hat wohl vom BSI für Kritis-Infrastruktur nicht empfohlen ist. Weißt du da was zu? Nein. Ich habe nichts von mitbekommen. Okay. Ich habe eine Frage und zwar von meiner Firma, die Open-VPN-Geschichte funktioniert mit zwei Faktor-Authentifizierung. Habe ich jetzt hier in dieser Oberfläche zum Durchklicken für User nicht gesehen? Es gibt so ein paar Erweiterungen. In dem Protokoll selbst findet nie wirklich eine Password-Eingabe statt und das heißt, und dadurch, dass es auch transparent funktioniert, ist es schwierig, das mit zwei Faktor zu machen. Es gibt Ansätze dafür, die auch funktionieren. Das sind meistens Systeme, die eben nochmal die auf WireGuard aufbauen und da nochmal andere Formen von Netzwerkautorisierungen reinbauen. Und dann authentifiziert man sich da drüber, dass WireGuard noch mehr ist. Händchen nochmal hoch. Wo habe ich weiter zu gehen? Dann gehen wir hier hin. Hallo, ich hätte eine Frage zu diesem KIAUS-Tausch alle zwei Minuten. Wird der wegparalysiert oder habe ich da eine kurze Verzögerung? Der wird einfach wegparalysiert. Die alte Session bleibt ja sogar noch länger, als dieser KIAUS-Tausch überhaupt verfügbar und wird verwendet. Das bedeutet, dass dieser KIAUS-Tausch fertig ist, dann sind die neuen Kies da. Und die alte Session ist ja immer noch verfügbar, selbst wenn schon die neuen Kies überhaupt verwendet werden. Ach, das sind diese drei Sessions. Es gibt immer so eine Current-Session, eine Past-Session, die am Anfang leer ist, aber noch zwei Minuten dann eben gefüllt wird und eine Future-Session. Das heißt, wenn der KIAUS-Tausch fertig ist, dann der passiert vollständig parallel dazu eben einfach. Danke, das ist ja für echt zeitkritisch wichtig. Ja. Ich habe OpenVPN bei mir im Einsatz und habe die Erfahrung gemacht, dass in manchen Netzen zum Beispiel öffentliche Zug-WLANs ist über TCP besser funktioniert als über UDP. Hast du da irgendwelche Erfahrungen mit, ob das über WireGuard auch funktioniert, dass er auf UDP festgelegt zu sein scheint? Ich habe bis jetzt in Zug-WLANs keine Probleme mit WireGuard gehabt. Ich kann mir vorstellen, dass einige öffentliche WLANs eventuell WireGuard einfach blockieren, weil die generell alles, was UDP ist, blockieren, weil die es irgendwie aus Bisches finden. Aber davon abgesehen ist halt die Tatsache einfach, dass, also wenn ich eine TCP-basierte Anwendung über WireGuard kommunizieren lasse, dann habe ich ja immer noch TCP. Oder Umständen gehen vielleicht sehr viele Handchecks verloren oder so, das kann ich mir vorstellen. Aber das sollte, aber wenn so viele Handchecks verloren gehen, wäre ich stabil dann die Anwendung überhaupt funktionieren könnte. Weitere Fragen Hände hoch, sieht nicht so aus. Ja dann, doch nochmal die Hände hoch für den fetten Applaus.