WireGuard hat in letzter Zeit viel Aufmerksamkeit auf sich gezogen, tatsächlich ist es der neue Star unter den VPNs. Aber ist er so gut, wie er scheint? Ich möchte einige Beobachtungen diskutieren und die Implementierung von WireGuard überprüfen, um zu erklären, warum es keine Lösung ist, um IPsec oder OpenVPN zu ersetzen.
In diesem Artikel möchte ich einige der Mythen [um WireGuard] entlarven. Ja, das Lesen wird lange dauern. Wenn Sie sich also noch keine Tasse Tee oder Kaffee gemacht haben, ist es an der Zeit, es zu tun. Ich möchte auch Peter dafür danken, dass er meine chaotischen Gedanken korrigiert hat.
Ich setze mir nicht das Ziel, die Entwickler von WireGuard zu diskreditieren, ihre Bemühungen oder Ideen abzuwerten. Ihr Produkt funktioniert, aber ich persönlich denke, dass es völlig anders präsentiert wird, als es wirklich ist – es wird als Ersatz für IPsec und OpenVPN präsentiert, die es derzeit einfach nicht gibt.
Als Anmerkung möchte ich hinzufügen, dass die Verantwortung für eine solche Positionierung von WireGuard bei den Medien liegt, die darüber gesprochen haben, und nicht beim Projekt selbst oder seinen Urhebern.
In letzter Zeit gab es nicht viele gute Nachrichten über den Linux-Kernel. Man erzählte uns also von den monströsen Schwachstellen des Prozessors, die durch Software beseitigt wurden, und Linus Torvalds sprach zu unhöflich und langweilig darüber, in der Gebrauchssprache des Entwicklers. Auch ein Scheduler oder ein Zero-Level-Networking-Stack sind keine ganz klaren Themen für Hochglanzmagazine. Und hier kommt WireGuard.
Auf dem Papier klingt alles großartig: eine aufregende neue Technologie.
Aber schauen wir es uns etwas genauer an.
WireGuard-Whitepaper
Dieser Artikel basiert auf geschrieben von Jason Donenfeld. Dort erklärt er Konzept, Zweck und technische Umsetzung von [WireGuard] im Linux-Kernel.
Der erste Satz lautet:
WireGuard […] zielt darauf ab, sowohl IPsec in den meisten Anwendungsfällen als auch andere beliebte Userspace- und/oder TLS-basierte Lösungen wie OpenVPN zu ersetzen und gleichzeitig sicherer, leistungsfähiger und benutzerfreundlicher zu sein [Tool].
Der Hauptvorteil aller neuen Technologien ist natürlich ihr Einfachheit [im Vergleich zu Vorgängern]. Aber ein VPN sollte es auch sein effizient und sicher.
Und was dann?
Wenn Sie sagen, dass dies nicht das ist, was Sie [von einem VPN] benötigen, können Sie die Lektüre hier beenden. Ich möchte jedoch darauf hinweisen, dass solche Aufgaben auch für jede andere Tunneltechnologie gelten.
Das Interessanteste des obigen Zitats sind die Worte „in den meisten Fällen“, die von der Presse natürlich ignoriert wurden. Und so sind wir nun dort, wo wir aufgrund des durch diese Nachlässigkeit entstandenen Chaos gelandet sind – in diesem Artikel.
Wird WireGuard mein [IPsec] Site-to-Site-VPN ersetzen?
Nein. Es besteht einfach keine Chance, dass große Anbieter wie Cisco, Juniper und andere WireGuard für ihre Produkte kaufen. Sie springen unterwegs nicht „auf vorbeifahrende Züge auf“, es sei denn, es besteht ein dringender Bedarf dazu. Später werde ich auf einige der Gründe eingehen, warum sie ihre WireGuard-Produkte wahrscheinlich nicht ins Boot holen könnten, selbst wenn sie es wollten.
Wird WireGuard meinen RoadWarrior von meinem Laptop zum Rechenzentrum bringen?
Nein. Derzeit sind in WireGuard nicht viele wichtige Funktionen implementiert, um so etwas tun zu können. Beispielsweise können auf der Seite des Tunnelservers keine dynamischen IP-Adressen verwendet werden, und dies allein macht das gesamte Szenario einer solchen Verwendung des Produkts zunichte.
IPFire wird häufig für günstige Internetverbindungen wie DSL- oder Kabelverbindungen verwendet. Dies ist für kleine und mittlere Unternehmen sinnvoll, die keine schnelle Glasfaser benötigen. [Anmerkung des Übersetzers: Vergessen Sie nicht, dass Russland und einige GUS-Staaten in Bezug auf die Kommunikation Europa und den Vereinigten Staaten weit voraus sind, da wir viel später und mit dem Aufkommen von Ethernet- und Glasfasernetzen mit dem Aufbau unserer Netzwerke begonnen haben Standard war es für uns einfacher, es umzubauen. In denselben Ländern der EU oder den USA ist der xDSL-Breitbandzugang mit einer Geschwindigkeit von 3-5 Mbit/s immer noch die allgemeine Norm, und ein Glasfaseranschluss kostet für unsere Verhältnisse unrealistische Kosten. Daher spricht der Autor des Artikels von DSL- oder Kabelanschluss als Norm und nicht von antiken Zeiten.] Allerdings verfügen DSL, Kabel, LTE (und andere drahtlose Zugangsmethoden) über dynamische IP-Adressen. Natürlich ändern sie sich manchmal nicht oft, aber sie ändern sich.
Es gibt ein Teilprojekt namens , der einen Userspace-Daemon hinzufügt, um dieses Manko zu beheben. Ein großes Problem bei dem oben beschriebenen Benutzerszenario ist die Verschärfung der dynamischen IPv6-Adressierung.
Auch aus Sicht des Händlers sieht das alles nicht besonders gut aus. Eines der Designziele bestand darin, das Protokoll einfach und sauber zu halten.
Leider ist das alles eigentlich zu einfach und primitiv geworden, sodass wir zusätzliche Software verwenden müssen, damit das gesamte Design in der Praxis realisierbar ist.
Ist WireGuard so einfach zu bedienen?
Noch nicht. Ich sage nicht, dass WireGuard niemals eine gute Alternative zum Tunneln zwischen zwei Punkten sein wird, aber im Moment ist es nur eine Alpha-Version des Produkts, das es sein soll.
Aber was macht er dann eigentlich? Ist IPsec wirklich so viel schwieriger zu warten?
Offensichtlich nicht. Daran hat der IPsec-Anbieter gedacht und liefert sein Produkt mit einer Schnittstelle aus, beispielsweise mit IPFire.
Um einen VPN-Tunnel über IPsec einzurichten, benötigen Sie fünf Datensätze, die Sie in die Konfiguration eingeben müssen: Ihre eigene öffentliche IP-Adresse, die öffentliche IP-Adresse des Empfängers, die Subnetze, über die Sie öffentlich zugänglich machen möchten diese VPN-Verbindung und den Pre-Shared Key. Somit ist das VPN innerhalb weniger Minuten eingerichtet und mit jedem Anbieter kompatibel.
Leider gibt es von dieser Geschichte einige Ausnahmen. Jeder, der versucht hat, über IPsec einen Tunnel zu einer OpenBSD-Maschine herzustellen, weiß, wovon ich spreche. Es gibt noch ein paar weitere schmerzhafte Beispiele, aber tatsächlich gibt es noch viele, viele weitere gute Praktiken für die Verwendung von IPsec.
Über Protokollkomplexität
Der Endbenutzer muss sich keine Gedanken über die Komplexität des Protokolls machen.
Wenn wir in einer Welt leben würden, in der dies ein echtes Anliegen des Benutzers wäre, hätten wir SIP, H.323, FTP und andere Protokolle abgeschafft, die vor mehr als zehn Jahren erstellt wurden und mit NAT nicht gut funktionieren.
Es gibt Gründe, warum IPsec komplexer ist als WireGuard: Es macht viel mehr Dinge. Zum Beispiel die Benutzerauthentifizierung mittels Login/Passwort oder einer SIM-Karte mit EAP. Es verfügt über eine erweiterte Fähigkeit, Neues hinzuzufügen .
Und WireGuard hat das nicht.
Und das bedeutet, dass WireGuard irgendwann kaputt geht, weil eines der kryptografischen Grundelemente schwächer wird oder vollständig kompromittiert wird. Der Autor der technischen Dokumentation sagt dazu:
Es ist erwähnenswert, dass WireGuard kryptografisch ausgerichtet ist. Es fehlt bewusst die Flexibilität von Chiffren und Protokollen. Wenn schwerwiegende Lücken in den zugrunde liegenden Grundelementen gefunden werden, müssen alle Endpunkte aktualisiert werden. Wie Sie an der anhaltenden Flut von SLL/TLS-Schwachstellen erkennen können, hat sich die Flexibilität der Verschlüsselung mittlerweile enorm erhöht.
Der letzte Satz ist absolut richtig.
Um einen Konsens darüber zu erzielen, welche Verschlüsselung verwendet werden soll, werden Protokolle wie IKE und TLS benötigt mehr Komplex. Zu kompliziert? Ja, Schwachstellen kommen bei TLS/SSL recht häufig vor und es gibt keine Alternative dazu.
Über das Ignorieren echter Probleme
Stellen Sie sich vor, Sie hätten irgendwo auf der Welt einen VPN-Server mit 200 Kampfclients. Dies ist ein ziemlich normaler Anwendungsfall. Wenn Sie die Verschlüsselung ändern müssen, müssen Sie das Update auf allen Kopien von WireGuard auf diesen Laptops, Smartphones usw. bereitstellen. Gleichzeitig liefern. Es ist buchstäblich unmöglich. Administratoren, die dies versuchen, werden Monate brauchen, um die erforderlichen Konfigurationen bereitzustellen, und ein mittelständisches Unternehmen wird buchstäblich Jahre brauchen, um so etwas auf die Beine zu stellen.
IPsec und OpenVPN bieten eine Funktion zur Verschlüsselungsverhandlung. Daher funktioniert für einige Zeit, nachdem Sie die neue Verschlüsselung aktiviert haben, auch die alte. Dies ermöglicht Bestandskunden ein Upgrade auf die neue Version. Nach der Einführung des Updates schalten Sie einfach die anfällige Verschlüsselung aus. Und alle! Bereit! Du bist wunderschön! Kunden werden es nicht einmal bemerken.
Dies ist tatsächlich ein sehr häufiger Fall bei großen Bereitstellungen, und selbst OpenVPN hat damit einige Schwierigkeiten. Abwärtskompatibilität ist wichtig, und auch wenn Sie eine schwächere Verschlüsselung verwenden, ist dies für viele kein Grund, ein Unternehmen zu schließen. Denn es wird die Arbeit von Hunderten von Kunden lahmlegen, weil sie ihre Arbeit nicht erledigen können.
Das WireGuard-Team hat sein Protokoll einfacher gemacht, ist aber für Leute, die nicht die ständige Kontrolle über beide Peers in ihrem Tunnel haben, völlig unbrauchbar. Meiner Erfahrung nach ist dies das häufigste Szenario.
Kryptographie!
Aber was ist diese interessante neue Verschlüsselung, die WireGuard verwendet?
WireGuard verwendet Curve25519 für den Schlüsselaustausch, ChaCha20 für die Verschlüsselung und Poly1305 für die Datenauthentifizierung. Es funktioniert auch mit SipHash für Hash-Schlüssel und BLAKE2 für Hashing.
ChaCha20-Poly1305 ist für IPsec und OpenVPN (über TLS) standardisiert.
Es ist offensichtlich, dass die Entwicklung von Daniel Bernstein sehr häufig verwendet wird. BLAKE2 ist der Nachfolger von BLAKE, einem SHA-3-Finalisten, der aufgrund seiner Ähnlichkeit zu SHA-2 nicht gewann. Wenn SHA-2 gebrochen würde, bestünde eine gute Chance, dass auch BLAKE kompromittiert würde.
IPsec und OpenVPN benötigen aufgrund ihres Designs kein SipHash. Das einzige, was derzeit nicht mit ihnen verwendet werden kann, ist BLAKE2, und das nur, bis es standardisiert ist. Das ist kein großer Nachteil, denn VPNs nutzen HMAC zur Herstellung der Integrität, was auch in Verbindung mit MD5 als starke Lösung gilt.
Daher kam ich zu dem Schluss, dass in allen VPNs fast die gleichen kryptografischen Tools verwendet werden. Daher ist WireGuard weder sicherer noch weniger sicher als jedes andere aktuelle Produkt, wenn es um die Verschlüsselung oder die Integrität der übertragenen Daten geht.
Aber auch das ist nicht das Wichtigste, worauf es laut offizieller Dokumentation des Projekts zu achten lohnt. Schließlich geht es vor allem um Geschwindigkeit.
Ist WireGuard schneller als andere VPN-Lösungen?
Kurz gesagt: Nein, nicht schneller.
ChaCha20 ist eine Stream-Verschlüsselung, die einfacher in Software zu implementieren ist. Es verschlüsselt jeweils ein Bit. Blockprotokolle wie AES verschlüsseln einen Block jeweils mit 128 Bit. Für die Implementierung der Hardware-Unterstützung sind viel mehr Transistoren erforderlich, daher sind größere Prozessoren mit AES-NI ausgestattet, einer Befehlssatzerweiterung, die einige der Aufgaben des Verschlüsselungsprozesses übernimmt, um ihn zu beschleunigen.
Es wurde erwartet, dass AES-NI niemals in Smartphones Einzug halten würde [aber es geschah – ca. pro.]. Hierfür wurde der ChaCha20 als leichte, batterieschonende Alternative entwickelt. Deshalb ist es vielleicht eine Neuigkeit für Sie, dass jedes Smartphone, das Sie heute kaufen können, über eine Art AES-Beschleunigung verfügt und mit dieser Verschlüsselung schneller und mit geringerem Stromverbrauch läuft als mit ChaCha20.
Offensichtlich verfügt nahezu jeder Desktop-/Serverprozessor, der in den letzten Jahren gekauft wurde, über AES-NI.
Daher gehe ich davon aus, dass AES ChaCha20 in jedem einzelnen Szenario übertreffen wird. In der offiziellen Dokumentation von WireGuard wird erwähnt, dass ChaCha512-Poly20 mit AVX1305 AES-NI übertreffen wird, diese Befehlssatzerweiterung jedoch nur auf größeren CPUs verfügbar sein wird, was wiederum bei kleinerer und mobilerer Hardware nicht hilft, die mit AES immer schneller sein wird - N.I.
Ich bin mir nicht sicher, ob dies bei der Entwicklung von WireGuard vorhersehbar war, aber heute ist die Tatsache, dass es nur auf die Verschlüsselung beschränkt ist, bereits ein Nachteil, der sich möglicherweise nicht besonders positiv auf die Funktionsweise auswirkt.
Mit IPsec können Sie frei wählen, welche Verschlüsselung für Ihren Fall die beste ist. Und das ist natürlich notwendig, wenn Sie beispielsweise 10 oder mehr Gigabyte Daten über eine VPN-Verbindung übertragen möchten.
Integrationsprobleme in Linux
Obwohl WireGuard sich für ein modernes Verschlüsselungsprotokoll entschieden hat, verursacht dies bereits viele Probleme. Anstatt also das zu nutzen, was der Kernel standardmäßig unterstützt, verzögert sich die Integration von WireGuard aufgrund des Fehlens dieser Grundfunktionen in Linux um Jahre.
Ich bin mir nicht ganz sicher, wie die Situation auf anderen Betriebssystemen ist, aber es ist wahrscheinlich nicht viel anders als unter Linux.
Wie sieht die Realität aus?
Leider stoße ich jedes Mal, wenn ein Kunde mich auffordert, eine VPN-Verbindung für ihn einzurichten, auf das Problem, dass er veraltete Anmeldeinformationen und Verschlüsselung verwendet. 3DES in Verbindung mit MD5 ist nach wie vor gängige Praxis, ebenso AES-256 und SHA1. Und obwohl Letzteres etwas besser ist, sollte dies im Jahr 2020 nicht genutzt werden.
Zum Schlüsselaustausch immer Es wird RSA verwendet – ein langsames, aber ziemlich sicheres Tool.
Meine Mandanten sind mit Zollbehörden und anderen staatlichen Organisationen und Institutionen verbunden, aber auch mit großen Konzernen, deren Namen auf der ganzen Welt bekannt sind. Sie alle verwenden 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 es sich irgendwie eindeutig auf den technologischen Fortschritt auswirkt, aber offensichtlich verlangsamt es den Unternehmensprozess.
Es tut mir weh, das zu sehen, denn IPsec unterstützt ohne weiteres elliptische Kurven seit dem Jahr 2005. Curve25519 ist ebenfalls neuer und zur Verwendung verfügbar. Es gibt auch Alternativen zu AES wie Camellia und ChaCha20, aber offensichtlich werden nicht alle von großen Anbietern wie Cisco und anderen unterstützt.
Und die Leute nutzen es aus. Es gibt viele Cisco-Kits, es gibt viele Kits, die für die Zusammenarbeit mit Cisco konzipiert sind. Sie sind Marktführer in diesem Segment und haben kein großes Interesse an Innovationen jeglicher Art.
Ja, die Situation [im Unternehmensbereich] ist schrecklich, aber wir werden durch WireGuard keine Änderungen sehen. Anbieter werden wahrscheinlich nie Leistungsprobleme mit den Tools und der Verschlüsselung feststellen, die sie bereits verwenden, werden keine Probleme mit IKEv2 sehen und suchen daher nicht nach Alternativen.
Haben Sie überhaupt jemals darüber nachgedacht, Cisco aufzugeben?
Benchmarks
Kommen wir nun zu den Benchmarks aus der WireGuard-Dokumentation. Obwohl es sich bei dieser [Dokumentation] nicht um einen wissenschaftlichen Artikel handelt, habe ich dennoch erwartet, dass die Entwickler einen wissenschaftlicheren Ansatz verfolgen oder einen wissenschaftlichen Ansatz als Referenz verwenden würden. Jegliche Benchmarks sind nutzlos, wenn sie nicht reproduziert werden können, und noch nutzloser, wenn sie im Labor ermittelt werden.
In der Linux-Version von WireGuard werden die Vorteile von GSO (Generic Segmentation Offloading) genutzt. Dank ihm erstellt der Client ein riesiges Paket von 64 Kilobyte und verschlüsselt/entschlüsselt es in einem Rutsch. Dadurch werden die Kosten für das Aufrufen und Implementieren kryptografischer Operationen reduziert. Wenn Sie den Durchsatz Ihrer VPN-Verbindung maximieren möchten, ist dies eine gute Idee.
Aber wie immer ist die Realität nicht so einfach. Um ein so großes Paket an einen Netzwerkadapter zu senden, muss es in viele kleinere Pakete aufgeteilt werden. Die normale Sendegröße 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 Weile die Arbeit des Netzwerkadapters vollständig, da sie zusammen und auf einmal gesendet werden müssen. Dadurch kommt es zu einem Prioritätssprung und Pakete wie z. B. VoIP werden in die Warteschlange gestellt.
Somit wird der hohe Durchsatz, den WireGuard so kühn behauptet, auf Kosten einer Verlangsamung der Vernetzung anderer Anwendungen erreicht. Und das WireGuard-Team ist es bereits das ist mein Fazit.
Aber lasst uns weitermachen.
Laut Benchmarks in der technischen Dokumentation weist die Verbindung einen Durchsatz von 1011 Mbit/s auf.
Beeindruckend.
Dies ist besonders beeindruckend, da der maximale theoretische Durchsatz einer einzelnen 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 beträgt der WireGuard selbst. Es gibt einen weiteren IP-Header im gekapselten Paket und einen weiteren im TCP für 20 Bytes. Woher kommt also diese zusätzliche Bandbreite?
Bei großen Frames und den oben erwähnten Vorteilen von GSO läge das theoretische Maximum für eine Framegröße von 9000 Byte bei 1014 Mbit/s. Normalerweise ist ein solcher Durchsatz in der Realität unerreichbar, da er mit großen Schwierigkeiten verbunden ist. Daher kann ich nur davon ausgehen, dass der Test mit noch dickeren übergroßen Frames von 64 Kilobyte und einem theoretischen Maximum von 1023 Mbit/s durchgeführt wurde, was nur von einigen Netzwerkadaptern unterstützt wird. Unter realen Bedingungen ist dies jedoch überhaupt nicht anwendbar bzw. kann nur zwischen zwei direkt verbundenen Stationen, ausschließlich innerhalb des Prüfstands, eingesetzt werden.
Da die Weiterleitung des VPN-Tunnels zwischen zwei Hosts jedoch über eine Internetverbindung erfolgt, die überhaupt keine Jumbo-Frames unterstützt, kann das am Prüfstand erzielte Ergebnis nicht als Maßstab herangezogen werden. Dies ist einfach eine unrealistische Laborleistung, die unter realen Kampfbedingungen unmöglich und nicht anwendbar ist.
Selbst wenn ich im Rechenzentrum saß, konnte ich keine Frames übertragen, die größer als 9000 Byte waren.
Das Kriterium der Anwendbarkeit im wirklichen Leben wird absolut verletzt und der Autor der durchgeführten „Messung“ hat sich meiner Meinung nach aus offensichtlichen Gründen ernsthaft diskreditiert.
Letzter Hoffnungsschimmer
Auf der WireGuard-Website wird viel über Container gesprochen und es wird deutlich, wofür sie eigentlich gedacht sind.
Ein einfaches und schnelles VPN, das keine Konfiguration erfordert und mit umfangreichen Orchestrierungstools, wie sie Amazon in seiner Cloud hat, bereitgestellt und konfiguriert werden kann. Insbesondere verwendet Amazon die neuesten Hardwarefunktionen, die ich zuvor erwähnt habe, wie beispielsweise den AVX512. Dies geschieht, um die Arbeit zu beschleunigen und nicht an x86 oder eine andere Architektur gebunden zu sein.
Sie optimieren den Durchsatz und Pakete mit mehr als 9000 Bytes – dabei handelt es sich um riesige, gekapselte Frames für die Kommunikation von Containern untereinander oder für Sicherungsvorgänge, die Erstellung von Snapshots oder die Bereitstellung derselben Container. Selbst dynamische IP-Adressen haben in dem von mir beschriebenen Szenario keinerlei Einfluss auf den Betrieb von WireGuard.
Gut gespielt. Brillante Implementierung und sehr dünnes, fast Referenzprotokoll.
Aber es passt einfach nicht in eine Welt außerhalb eines Rechenzentrums, das Sie vollständig kontrollieren. Wenn Sie das Risiko eingehen und mit WireGuard beginnen, müssen Sie bei der Gestaltung und Implementierung des Verschlüsselungsprotokolls ständig Kompromisse eingehen.
Abschluss
Es fällt mir leicht, den Schluss zu ziehen, dass WireGuard noch nicht bereit ist.
Es wurde als einfache und schnelle Lösung für eine Reihe von Problemen mit bestehenden Lösungen konzipiert. Leider hat er zugunsten dieser Lösungen viele Funktionen geopfert, die für die meisten Benutzer relevant sein werden. Deshalb kann es IPsec oder OpenVPN nicht ersetzen.
Damit WireGuard konkurrenzfähig wird, muss es mindestens eine IP-Adresseinstellung sowie eine Routing- und DNS-Konfiguration hinzufügen. Offensichtlich sind dafür verschlüsselte Kanäle da.
Sicherheit hat für mich oberste Priorität und im Moment habe ich keinen Grund zu der Annahme, dass IKE oder TLS irgendwie kompromittiert oder kaputt sind. In beiden wird moderne Verschlüsselung unterstützt, die sich im jahrzehntelangen Betrieb bewährt hat. Nur weil etwas neuer ist, heißt das nicht, dass es besser ist.
Interoperabilität ist äußerst wichtig, wenn Sie mit Dritten kommunizieren, deren Stationen Sie nicht kontrollieren. IPsec ist der De-facto-Standard und wird fast überall unterstützt. Und er funktioniert. Und egal wie es aussieht, theoretisch wird WireGuard in Zukunft möglicherweise nicht einmal mit anderen Versionen von WireGuard kompatibel sein.
Jeder kryptografische Schutz wird früher oder später gebrochen und muss dementsprechend ersetzt oder aktualisiert werden.
All diese Fakten zu leugnen und blind WireGuard nutzen zu wollen, um Ihr iPhone mit Ihrem Heimarbeitsplatz zu verbinden, ist nur eine Meisterleistung darin, den Kopf in den Sand zu stecken.
Source: habr.com
