In letzter Zeit zieht WireGuard viel Aufmerksamkeit auf sich, faktisch ist es der neue „Stern“ unter VPN. Aber ist es wirklich so gut, wie es scheint? Ich möchte einige Beobachtungen diskutieren und die Implementierung von WireGuard betrachten, um zu erklären, warum es keine Lösung ist, die IPsec oder OpenVPN ersetzen kann.
In diesem Artikel möchte ich einige Mythen [rund um WireGuard] entkräften. Ja, es wird lange zu lesen sein, also wenn Sie sich noch keine Tasse Tee oder Kaffee gemacht haben, ist jetzt der beste Zeitpunkt dafür. Ich möchte auch Peter für das Korrekturlesen meiner chaotischen Gedanken danken.
Ich strebe nicht an, die Entwickler von WireGuard zu diskreditieren, ihre Bemühungen oder Ideen zu entwerten. Ihr Produkt ist funktional, aber persönlich denke ich, dass es völlig falsch präsentiert wird — es wird als Ersatz für IPsec und OpenVPN dargestellt, wobei es diese in Wirklichkeit gerade nicht gibt.
Als Anmerkung möchte ich hinzufügen, dass die Verantwortung für diese Positionierung von WireGuard bei den Medien liegt, die darüber berichteten, und nicht beim Projekt selbst oder seinen Machern.
In letzter Zeit gab es nicht allzu viele gute Nachrichten über den Linux-Kernel. So wurden uns schreckliche Sicherheitsanfälligkeiten von Prozessoren präsentiert, die softwareseitig behoben wurden, und Linus Torvalds sprach darüber zu grob und langweilig, in der utilitaristischen Sprache eines Entwicklers. Der Scheduler oder der Netzwerk-Stack der Null-Ebene sind ebenfalls nicht gerade verständliche Themen für Hochglanzmagazine. Und hier kommt WireGuard ins Spiel.
Auf dem Papier klingt alles großartig: eine faszinierende neue Technologie.
Aber lassen Sie uns einen genaueren Blick darauf werfen.
Technische Dokumentation von WireGuard
Dieser Artikel basiert auf der offiziellen Dokumentation von WireGuard, die von Jason Donenfeld verfasst wurde. Dort erklärt er das Konzept, Ziel und die technische Umsetzung von [WireGuard] im Linux-Kernel.
Der erste Satz lautet:
WireGuard […] zielt darauf ab, sowohl IPsec in den meisten Anwendungsfällen zu ersetzen, als auch andere beliebte Lösungen auf Basis von Benutzermodus und/oder TLS, wie OpenVPN, und dabei sicherer, leistungsstärker und einfacher zu bedienenden [Werkzeug] zu sein.
Natürlich ist das Hauptmerkmal aller neuen Technologien ihre Einfachheit [im Vergleich zu Vorläufern]. Aber ein VPN muss auch sein effektiv und sicher.
Und was dann?
Wenn Sie sagen, dass Sie [von VPN] nicht das brauchen, können wir hier aufhören zu lesen. Ich möchte jedoch anmerken, dass solche Aufgaben jeder anderen Tunneltechnologie gestellt werden.
Das Interessanteste aus dem obigen Zitat steckt in den Worten „in den meisten Fällen“, die von der Presse selbstverständlich ignoriert wurden. Und da sind wir — in dem Chaos, das durch diese Nachlässigkeit entstanden ist — in diesem Artikel.
Wird WireGuard meine [IPsec] VPN-Verbindung zwischen Standorten ersetzen?
Nein. Es gibt einfach keine Chance, dass große Anbieter wie Cisco, Juniper und andere WireGuard für ihre Produkte übernehmen. Sie „springen nicht auf vorbeifahrende Züge“ in der Bewegung, es sei denn, es besteht eine große Notwendigkeit. Später werde ich auf einige Gründe eingehen, warum sie WireGuard wahrscheinlich nicht in ihre Produkte integrieren können, selbst wenn sie es wollten.
Wird WireGuard meinen RoadWarrior vom Laptop ins Rechenzentrum bringen?
Nein. Derzeit fehlen WireGuard viele wichtige Funktionen, um etwas Ähnliches zu erreichen. Zum Beispiel kann er keine dynamischen IP-Adressen auf der Serverseite des Tunnels verwenden, und allein das macht das gesamte Nutzungsszenario unmöglich.
IPFire wird häufig für günstige Internetverbindungen, wie DSL oder Kabel, verwendet. Das macht Sinn für kleine oder mittlere Unternehmen, die keine schnelle Glasfaser benötigen. [Hinweis des Übersetzers: Man sollte nicht vergessen, dass Russland und einige GUS-Staaten im Bereich der Kommunikation Europa und den USA weit voraus sind, da wir unsere Netzwerke viel später aufgebaut haben und mit dem Aufkommen von Ethernet und Glasfasernetzen als Standard war es für uns einfacher, umzusteigen. In den EU- oder US-Staaten ist xDSL-Breitband mit Geschwindigkeiten von 3-5 Mbit/s immer noch die allgemeine Norm, und die Kosten für eine Glasfaseranbindung sind im Vergleich zu unseren Maßstäben unrealistisch hoch. Daher spricht der Autor des Artikels von DSL oder Kabelanschluss als Norm und nicht als veralteter Technologie.] Allerdings haben DSL-, Kabel-, LTE- (und andere drahtlose Zugangsarten) dynamische IP-Adressen. Natürlich ändern sie sich manchmal nicht oft, aber sie ändern sich dennoch.
Es gibt ein Unterprojekt mit dem Namen „wg-dynamic“, der einen Benutzerraum-Dämon hinzufügt, um dieses Manko zu überwinden. Ein großes Problem des oben beschriebenen Nutzungsszenarios ist die Verschärfung der Situation durch dynamische IPv6-Adressen.
Aus Sicht des Anbieters sieht das ebenfalls nicht gut aus. Eines der Ziele der Entwicklung war es, die Einfachheit und Klarheit des Protokolls zu bewahren.
Leider ist das Ganze tatsächlich zu einfach und primitiv geworden, sodass wir zusätzliche Software verwenden müssen, um diese gesamte Struktur unter realen Bedingungen funktionsfähig zu machen.
Ist WireGuard so einfach zu benutzen?
Noch nicht. Ich sage nicht, dass WireGuard niemals eine gute Alternative für das Tunneln zwischen zwei Punkten sein wird, aber im Moment ist es nur eine Alpha-Version des Produkts, das es werden sollte.
Aber was macht es dann tatsächlich? Ist IPsec wirklich so viel komplizierter in der Anwendung?
Offensichtlich nicht. Der Anbieter von IPsec hat dies berücksichtigt und liefert sein Produkt mit einem Interface, zum Beispiel mit IPFire.
Zur Einrichtung eines VPN-Tunnels über IPsec benötigen Sie fünf Datensätze, die in die Konfiguration eingegeben werden müssen: Ihre eigene öffentliche IP-Adresse, die öffentliche IP-Adresse des anderen Endes, die Subnetze, die Sie über diese VPN-Verbindung öffentlich machen möchten, und den Pre-Shared Key. So wird das VPN in wenigen Minuten konfiguriert und ist mit jedem Anbieter kompatibel.
Leider gibt es in dieser Geschichte einige Ausnahmen. Jeder, der versucht hat, einen VPN-Tunnel über IPsec zu einem Rechner unter OpenBSD weiterzuleiten, weiß, wovon ich spreche. Es gibt noch ein paar schmerzhafte Beispiele, aber tatsächlich gibt es viel mehr positive Praxiserfahrungen mit IPsec.
Zur Komplexität des Protokolls
Der Endverbraucher sollte sich keine Sorgen über die Komplexität des Protokolls machen.
Wenn wir in einer Welt leben würden, in der dies eine echte Sorge für den Nutzer wäre, wären wir längst von SIP, H.323, FTP und anderen Protokollen, die vor über zehn Jahren entwickelt wurden und schlecht mit NAT funktionieren, befreit.
Es gibt Gründe, warum IPsec komplizierter ist als WireGuard: Es macht viel mehr Dinge. Zum Beispiel die Benutzerauthentifizierung mit Login/Passwort oder SIM-Karte mit EAP. Es bietet erweiterte Möglichkeiten zur Hinzufügung neuer kryptografischer primitiven.
Aber WireGuard hat das nicht.
Und das bedeutet, dass WireGuard irgendwann brechen wird, weil eines der kryptografischen Primitive geschwächt oder vollständig kompromittiert wird. Der Autor der technischen Dokumentation sagt dazu folgendes:
Es ist erwähnenswert, dass WireGuard kryptografisch selbstbewusst ist. Es fehlt ihm absichtlich an Flexibilität bei den Chiffren und Protokollen. Wenn es schwerwiegende Sicherheitslücken in den zugrunde liegenden Primitiven entdeckt werden, müssen alle Endpunkte aktualisiert werden. Wie der fortlaufende Strom von Schwachstellen in SLL/TLS zeigt, hat die Flexibilität der Verschlüsselung heute enorm zugenommen.
Der letzte Satz ist absolut zutreffend.
Eine Einigung darüber, welche Verschlüsselung verwendet werden soll, macht Protokolle wie IKE und TLS mehr als kompliziert. Zu kompliziert? Ja, in TLS/SSL treten Schwachstellen ziemlich häufig auf, und es gibt keine Alternativen dazu.
Über die Ignorierung realer Probleme
Stellen Sie sich vor, Sie haben einen VPN-Server mit 200 aktiven Clients, die irgendwo auf der ganzen Welt verteilt sind. Das ist ein recht typisches Nutzungsszenario. Wenn Sie die Verschlüsselung ändern müssen, müssen Sie das Update auf alle Kopien von WireGuard auf diesen Laptops, Smartphones usw. bringen. Gleichzeitig Das ist literarisch unmöglich. Administratoren, die versuchen, dies zu tun, benötigen Monate, um die erforderlichen Konfigurationen bereitzustellen, und durchschnittliche Unternehmen würden dafür buchstäblich Jahre benötigen.
IPsec und OpenVPN bieten eine Funktion zur Aushandlung von Chiffren. Daher wird eine gewisse Zeit, nachdem Sie die neue Verschlüsselung aktiviert haben, auch die alte weiter funktionieren. Dadurch können die aktuellen Clients auf die neue Version aktualisiert werden. Nachdem das Update ausgerollt wurde, schalten Sie einfach die anfällige Verschlüsselung ab. Und das war's! Fertig! Sie sind fantastisch! Und die Clients werden das gar nicht bemerken.
Tatsächlich ist dies ein sehr verbreiteter Fall für große Implementierungen, und selbst OpenVPN hat dabei einige Schwierigkeiten. Abwärtskompatibilität ist wichtig, und obwohl Sie eine schwächere Verschlüsselung verwenden, wird dies für viele nicht der Grund sein, das Geschäft zu schließen. Denn das würde zur Lahmlegung der Arbeit Hunderter Kunden führen, die nicht in der Lage sind, ihre Arbeit zu erledigen.
Das WireGuard-Team hat sein Protokoll einfacher gemacht, aber völlig ungeeignet für Menschen, die keine ständige Kontrolle über beide Peers ihres Tunnels haben. Meiner Erfahrung nach ist genau dieses Szenario das am häufigsten vorkommende.
Kryptographie!
Aber was ist das für eine interessante neue Verschlüsselung, die WireGuard verwendet?
WireGuard nutzt Curve25519 für den Schlüsselaustausch, ChaCha20 für die Verschlüsselung und Poly1305 für die Authentifizierung von Daten. Es arbeitet auch mit SipHash für Hash-Schlüssel und BLAKE2 für Hashing.
ChaCha20-Poly1305 ist für IPsec und OpenVPN (über TLS) standardisiert.
Offensichtlich wird die Entwicklung von Daniel Bernstein sehr häufig verwendet. BLAKE2 ist der Nachfolger von BLAKE, einem Finalisten von SHA-3, der nicht gewonnen hat, weil er SHA-2 zu ähnlich war. Wenn SHA-2 gehackt worden wäre, hätte es eine große Wahrscheinlichkeit gegeben, dass auch BLAKE kompromittiert worden wäre.
IPsec und OpenVPN benötigen aufgrund ihres Designs kein SipHash. Daher ist das einzige, was derzeit nicht mit ihnen verwendet werden kann, BLAKE2, und dies nur, solange es nicht standardisiert ist. Das stellt keinen großen Nachteil dar, da VPNs HMAC zur Integritätsprüfung verwenden, das als starke Lösung selbst in Kombination mit MD5 angesehen wird.
So kam ich zu dem Schluss, dass in allen VPNs praktisch dasselbe Set von kryptografischen Werkzeugen verwendet wird. Daher ist WireGuard nicht sicherer oder unsicherer als andere aktuelle Produkte, wenn es um die Verschlüsselung oder die Integrität der übertragenen Daten geht.
Aber selbst das ist nicht das Wichtigste, worauf man laut der offiziellen Dokumentation des Projekts achten sollte. Denn das Hauptaugenmerk liegt auf der Geschwindigkeit.
Ist WireGuard schneller als andere VPN-Lösungen?
Kurz gesagt: Nein, nicht schneller.
ChaCha20 ist ein Stream-Cipher, der leichter in Software implementiert werden kann. Er verschlüsselt ein Bit auf einmal. Blockprotokolle wie AES verschlüsseln Blöcke von 128 Bit auf einmal. Für die Implementierung von Hardwareunterstützung sind viel mehr Transistoren erforderlich, weshalb größere Prozessoren mit AES-NI ausgestattet sind, einer Erweiterung des Befehlssatzes, die einige Aufgaben des Verschlüsselungsprozesses zur Beschleunigung ausführt.
Es wurde erwartet, dass AES-NI niemals in Smartphones Einzug halten würde [aber es tat es, Anm. d. Übers.]. Deshalb wurde ChaCha20 als leichte und energieeffiziente Alternative entwickelt, die den Akku schont. Daher könnte es für Sie eine Überraschung sein, dass jedes Smartphone, das Sie heute kaufen können, eine Art Beschleunigung für AES hat und mit dieser Verschlüsselung schneller und mit geringerem Energieverbrauch arbeitet als mit ChaCha20.
Offensichtlich hat praktisch jeder PC-/Server-Prozessor, der in den letzten paar Jahren gekauft wurde, AES-NI.
Folglich erwarte ich, dass AES ChaCha20 in jedem einzelnen Anwendungsfall übertreffen wird. In der offiziellen Dokumentation von WireGuard wird erwähnt, dass ChaCha20-Poly1305 dank AVX512 AES-NI übertreffen wird, doch diese Befehlserweiterung wird nur auf großen Prozessoren verfügbar sein, was wiederum nicht bei kleineren und mobilen Geräten hilft, die immer schneller mit AES-NI arbeiten werden.
Ich bin mir nicht sicher, ob dies bei der Entwicklung von WireGuard vorhergesehen wurde, aber heute ist die Tatsache, dass es an eine bestimmte Verschlüsselung gebunden ist, bereits ein Nachteil, der sich negativ auf seine Leistung auswirken könnte.
IPsec ermöglicht eine freie Wahl der Verschlüsselung, die am besten für Ihren Anwendungsfall geeignet ist. Und das ist notwendig, wenn Sie beispielsweise 10 Gigabyte oder mehr Daten über eine VPN-Verbindung übertragen möchten.
Integrationsprobleme in Linux
Obwohl WireGuard ein modernes Verschlüsselungsprotokoll gewählt hat, verursacht dies bereits viele Probleme. Statt das zu verwenden, was das Kernel von Haus aus unterstützt, wurde die Integration von WireGuard jahrelang durch das Fehlen dieser primitiven Funktionen in Linux verzögert.
Ich bin mir nicht sicher, wie die Situation in anderen Betriebssystemen aussieht, aber wahrscheinlich unterscheidet sie sich nicht stark von der Situation in Linux.
Wie sieht die Realität aus?
Leider bin ich jedes Mal, wenn ein Kunde mich bittet, ihm eine VPN-Verbindung einzurichten, mit dem Thema konfrontiert, dass sie veraltete Anmeldeinformationen und Verschlüsselungen verwenden. 3DES in Kombination mit MD5 ist nach wie vor eine gängige Praxis, ebenso wie AES-256 und SHA1. Auch wenn letzterer etwas besser ist – das ist nichts, womit man im Jahr 2020 arbeiten sollte.
Für den Schlüsselaustausch immer wird RSA verwendet – ein langsames, aber ausreichend sicheres Werkzeug.
Meine Kunden stehen mit den Zollbehörden und anderen staatlichen Institutionen sowie mit großen Unternehmen in Verbindung, deren Namen weltweit bekannt sind. Alle nutzen ein Anfrageformular, das vor Jahrzehnten erstellt wurde, und die Möglichkeit, SHA-512 zu verwenden, wurde einfach nie hinzugefügt. Ich kann nicht sagen, dass dies den technologischen Fortschritt offensichtlich beeinflusst, aber es verlangsamt die Unternehmensprozesse.
Es schmerzt mich, das zu sehen, denn IPsec unterstützt seit etwa 2005 elliptische Kurven. Curve25519 ist ebenfalls neuer und für die Nutzung verfügbar. Es gibt auch Alternativen zu AES wie Camellia und ChaCha20, die offensichtlich nicht von allen großen Anbietern wie Cisco und anderen unterstützt werden.
Und die Leute nutzen das. Es gibt viele Cisco-Kits, zahlreiche Kits, die für die Arbeit mit Cisco erstellt wurden. Sie sind Marktführer in diesem Segment und nicht besonders an Innovationen interessiert.
Ja, die Situation [im Unternehmenssegment] ist grausam, aber wir werden keine Veränderungen aufgrund von WireGuard sehen. Die Hersteller werden wahrscheinlich nie irgendwelche Leistungsprobleme mit den bereits verwendeten Werkzeugen und Verschlüsselungen erkennen, sie werden keine Probleme mit IKEv2 sehen — und deshalb suchen sie nicht nach Alternativen.
Haben Sie jemals darüber nachgedacht, Cisco abzulehnen?
Benchmarks
Und jetzt kommen wir zu den Benchmarks aus der Dokumentation von WireGuard. Obwohl diese [Dokumentation] kein wissenschaftlicher Artikel ist, hatte ich von den Entwicklern dennoch einen wissenschaftlicheren Ansatz oder die Verwendung eines wissenschaftlichen Ansatzes als Maßstab erwartet. Jegliche Benchmarks sind nutzlos, wenn sie nicht reproduzierbar sind, und sie sind noch wertloser, wenn sie unter Laborbedingungen erzielt wurden.
In der WireGuard-Version für Linux hat es den Vorteil, GSO — Generic Segmentation Offloading — zu nutzen. Dadurch erstellt der Client ein riesiges Paket von 64 Kilobyte und verschlüsselt/entschlüsselt es in einem einzigen Schritt. So werden die Kosten für den Aufruf und die Durchführung kryptografischer Operationen gesenkt. Wenn Sie die Bandbreite Ihrer VPN-Verbindung maximieren möchten – ist das eine gute Idee.
Aber wie das so ist, ist in der Realität nicht alles so einfach. Der Versand eines so großen Pakets an den Netzwerkadapter erfordert, dass es in viele kleinere Pakete aufgeteilt wird. Die übliche Größe einer Übertragung beträgt 1500 Byte. Das heißt, unser Riese von 64 Kilobyte wird in 45 Pakete (1240 Byte Informationen und 20 Byte IP-Header) aufgeteilt. Dann blockieren sie für eine gewisse Zeit komplett die Arbeit des Netzwerkadapters, da sie zusammen und gleichzeitig gesendet werden müssen. Dies führt letztendlich zu einem Prioritätssprung, und Pakete wie zum Beispiel VoIP werden in die Warteschlange gestellt.
Auf diese Weise wird die hohe Bandbreite, die WireGuard so selbstbewusst angibt, auf Kosten der Verlangsamung der Netzwerkperformance anderer Anwendungen erreicht. Und das WireGuard-Team hat bereits bestätigt meine Schlussfolgerung.
Aber lassen Sie uns weitergehen.
Laut Benchmarks in der technischen Dokumentation zeigt die Verbindung eine Bandbreite von 1011 Mbit/s.
Beeindruckend.
Insbesondere ist das beeindruckend, da die maximale theoretische Bandbreite einer Gigabit-Ethernet-Verbindung 966 Mbit/s bei einer Paketgröße von 1500 Byte minus 20 Byte für den IP-Header, 8 Byte für den UDP-Header und 16 Byte für den Header von WireGuard beträgt. Es gibt noch einen weiteren IP-Header im gekapselten Paket und einen weiteren im TCP-Header von 20 Byte. Woher stammt also diese zusätzliche Bandbreite?
Mit großen Frames und den oben genannten Vorteilen von GSO beträgt das theoretische Maximum bei einer Frame-Größe von 9000 Byte 1014 Mbit/s. Solch eine Bandbreite ist in der Realität normalerweise unerreichbar, da sie mit großen Schwierigkeiten verbunden ist. Daher kann ich nur annehmen, dass der Test mit noch größeren Frames durchgeführt wurde, die 64 Kilobyte überschreiten, mit einem theoretischen Maximum von 1023 Mbit/s, das nur von einigen Netzwerkadaptern unterstützt wird. Aber dies ist absolut nicht anwendbar unter realen Bedingungen oder kann nur zwischen zwei direkt verbundenen Stationen innerhalb eines Testaufbaus verwendet werden.
Da der VPN-Tunnel zwischen zwei Hosts über eine Internetverbindung hergestellt wird, die generell keine großen Frames unterstützt, kann das auf dem Teststand erreichte Ergebnis nicht als Referenz akzeptiert werden. Es ist einfach eine unrealistische Laborleistung, die in echten Kampfbedingungen nicht anwendbar ist.
Selbst im Rechenzentrum könnte ich keine Frames größer als 9000 Byte weiterleiten.
Das Kriterium der Anwendbarkeit im realen Leben ist absolut verletzt, und ich denke, der Autor der durchgeführten "Messung" hat sich aus verständlichen Gründen stark diskreditiert.
Die letzte Hoffnungsschimmer
Auf der WireGuard-Website wird viel über Container gesprochen, und es wird klar, wofür er tatsächlich gedacht ist.
Ein einfacher und schneller VPN, der keine Konfiguration erfordert und mit umfangreichen Orchestrierungswerkzeugen wie denen von Amazon in deren Cloud implementiert und eingerichtet werden kann. Konkret nutzt Amazon die neuesten Hardware-Funktionen, die ich zuvor erwähnt habe, wie AVX512. Dies geschieht, um die Leistung zu steigern und nicht an x86 oder eine andere Architektur gebunden zu sein.
Sie optimieren die Bandbreite und Pakete, die größer als 9000 Byte sind - das sind riesige inkapsulierte Frames zur Kommunikation zwischen Containern oder für Backup-Operationen, Snapshots oder beim Bereitstellen dieser Container. Selbst dynamische IP-Adressen haben keinen Einfluss auf die Funktion von WireGuard im von mir beschriebenen Szenario.
Nicht schlecht gespielt. Hervorragende Umsetzung und ein sehr feiner, fast referenzwürdiger Protokoll.
Aber es ist einfach nicht geeignet für die Welt außerhalb eines von Ihnen vollständig kontrollierten Rechenzentrums. Wenn Sie jedoch das Risiko eingehen und mit WireGuard arbeiten möchten, müssen Sie bei der Entwicklung und Implementierung des Verschlüsselungsprotokolls ständig Kompromisse eingehen.
Ausgabe
Es fällt mir nicht schwer zu dem Schluss zu kommen, dass WireGuard noch nicht bereit ist.
Es wurde als leichtgewichtige und schnelle Lösung für eine Reihe von Problemen bestehender Lösungen gedacht. Leider hat es viele Funktionen geopfert, die für die meisten Benutzer relevant sind. Deshalb kann es IPsec oder OpenVPN nicht ersetzen.
Damit WireGuard wettbewerbsfähig wird, muss es zumindest die Einstellung der IP-Adresse sowie die Konfiguration von Routing und DNS hinzufügen. Offensichtlich sind verschlüsselte Kanäle genau dafür notwendig.
Sicherheit hat für mich oberste Priorität, und derzeit habe ich keinen Grund zu glauben, dass IKE oder TLS in irgendeiner Weise kompromittiert oder gebrochen sind. Moderne Verschlüsselung wird in beiden unterstützt und sie wurden über Jahrzehnte hinweg getestet. Nur weil etwas neuer ist, bedeutet das nicht, dass es besser ist.
Funktionale Kompatibilität ist von entscheidender Bedeutung, wenn Sie mit Dritten kommunizieren, deren Stationen Sie nicht kontrollieren. IPsec ist de facto der Standard und wird praktisch überall unterstützt. Und es funktioniert. So sehr es auch theoretisch aussehen mag, könnte WireGuard in Zukunft sogar mit verschiedenen Versionen seiner selbst inkompatibel sein.
Jeder kryptografische Schutz wird früher oder später geknackt und muss entsprechend ersetzt oder aktualisiert werden.
Die Leugnung all dieser Fakten und der blinde Drang, WireGuard zu nutzen, um Ihr iPhone mit Ihrer heimischen Arbeitsstation zu verbinden, ist einfach ein Meisterklasse im Kopf-in-den-Sand-stecken.
Quelle: habr.com
