• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Wireguard [gelöst]

/dev/null

Moderator
Teammitglied
Hallo Freunde!

Ich habe gerade mal im Forum nach dem Wort "Wireguard" gesucht => nix da.
Bin ich der einzige, der sich damit beschäftigt? Oder haben diejenigen, die es nutzen "nur" keinerlei Probleme? <= Auf den Busch klopf ...

Nur so viel:
Ich habe auf allen Fritz!Boxen, welche "der IT-Rentner" zur Wartung "übernommen" hat, bislang ein AVM-VPN eingesetzt. Und es läuft auch ein gleiches VPN zwischen ggw. 2 Heimnetzen (in "Hengasch" und Leipzig). Alles problemlos, wenn nicht der sehr geringe Durchsatz selbst bei den modernsten F!B zu verzeichnen wäre.
Nun habe ich mal schnell drei herumliegende betagte Raspberry Pi B1 genommen und drei WG-Server aufgesetzt. Selbige funktionieren an den drei Standorten problemlos und nutzen vor allem den jeweiligen Uplink voll aus. Von allen meinen eigenen Geräten komme ich problemlos ins jeweilige Netz und die betreffenden User selbstverständlich auch. Nur, die Vernetzung der Standorte untereinander funktioniert (noch) nicht.

Also, sollte jemand Erfahrung damit haben, würde ich mich über eine rege Diskusson sehr freuen :p

MfG Peter
(und wie immer: Grüße nach Leipzig ...)
 
Hi

Ich habe mich vor etwa einem Jahr damit beschäftigen müssen.
Es ist deshalb durchaus möglich, dass das Folgende nicht mehr dem neuesten Stand entspricht.

Verglichen habe ich Wireguard mit OpenVPN und SSH. IPSec bezeichne ich als obsolet.
1. Im Gegensatz zu OpenVPN, das mit Zertifikaten arbeitet, verwendet Wireguard ein Verfahren,
das auf Salsa20 (für Verschlüsselung) und Poly1305-AES (für Schlüssel Authentifizierung) beruht.
Um das zu gewährleisten, benötigt der Wireguard server vom client eine statische VPN-IP, die natürlich
die Anonymität aushebelt.
2. Weiters bietet Wireguard kein TCP, das aber für Tunnel im Tunnel unerlässlich ist.
Je nach Wunsch sollte z.B. SSH-Tunnel in Wireguard und umgekehrt möglich sein, um dem Serverbetreiber
nicht vertrauen zu müssen.
3. Der höhere Datendurchsatz von Wireguard gegenüber z.B. OpenVPN ist nicht wirklich berauschend
und im Vergleich zu einem SSH-Tunnel kaum bemerkbar, obwohl SSH nur über TCP arbeitet.

Das erste Problem sehe ich kritisch. Eine verschlüsselte Verbindung sollte auch Anonymität gewährleisten.
Das zweite Problem verstärkt den Umstand der DeAnonymisierung weiter, da der client den Wireguard_server
nicht Durchtunneln kann. Man muß dem Wireguard Serverbetreiber schon ein großes Vertrauen entgegenbringen,
was ich aber in keinem Fall bringen will. Deshalb habe ich Wireguard verworfen. Das gilt aber nur für unsere
Anwendungen. Bei anderen Konstellationen, wie z.B. Wireguard auf Wireguard, wobei beide Seiten im Bereich
desselben Betreibers liegen, gelten meine Bedenken natürlich nicht.

Gruß
Gräfin Klara
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
Hallo Gräfin Klara,

und vielen Dank für deine Antwort.
[OT]
Dass IPSec obsolet ist, kann ich nicht so stehen lassen. Mir ist jedenfalls kein Verfahren bekannt, welches dafür zugelassen ist, eingestufte Daten aller nationalen Geheimhaltungsgrade zu übertragen. Dafür gibt es IMHO nur zwei Geräte, welche beide IPsec nutzen. Aber, ich bin jetzt auch schon ein paar Jahre "raus".
Auf jeden Fall mag das geschriebene für "Pillepalle-privat" und "Firmenintern" gelten, wofür die Anforderungen hier viel geringer sind.
[/OT]

Wie Wireguard funktioniert, ist mir schon gut bekannt. Ich finde es auch sehr gut, dass hier kein Aushandeln der zu verwendenden Verfahren für Verschlüsselung und Schlüsselaustausch erforderlich ist, weil eben alles klar vorgegeben wird. Ich habe auch keinerlei Problem mit der statischen IP der udp-Verbindung, denn mir geht es hier auch nicht im Anonymität (welche es im Netz nie gegeben hat und in der Praxis auch nie geben wird). Mir geht es wirklich nur um eine möglichst sichere Verschlüsselung und um eine gute Ausnutzung der vorhandenen Bandbreite. Was das erstere betrifft, da brauche ich auch als Privatmensch keine Evaluierung. Meine Datensicherung ist ja nicht eingestuft. Und irgendwann wird sich jemand finden, der auch WG evaluiert oder zumindest gründlich untersucht.

Was die erreichbare Bandbreite betrifft, so geht es mir um den Vergleich mit der Fritz!Box als dem in Deutschland üblichen Plastikrouter. Und zwei alte RasPi B1 schaffen immerhin in der direkten Verbindung so um die 40-50Mbit/s. Damit dürfte der Uplink einer üblichen DSL-Anbindung voll ausgelastet werden können. (Meine 10 Mbit/s werden voll genutzt.) Und genau so, wie die SINA-Box jetzt im Gbit-Bereich arbeitet, so wird wohl auch der Raspi B4 für die Glücklichen mit einem FTTH-Zugang volle Bandbreite bereistellen.

Und da es mir nicht um kommerzielle VPN-Anbieter geht, sondern ich selbst der "VPN-Anbieter" bin, ist für mich auch alles was Anonymität betrifft, kein Thema.

Wie ich schon in meinem Eingangsposting angedeutet habe, funktionieren meine 3 WG-Server(chen) völlig problemlos. Zugriff bei Wartungsarbeiten, Datenaustausch, Telefonie und auch die tägliche vollautomatische Datensicherung mit backintime auf ein weit entferntes NAS - alles perfekt.
Das einzige, was ich bis jetzt noch nicht realisiert habe, ist die direkte Vernetzung der drei (oder zumindest von zwei) Heimnetzen. Und genau das ist mein ggw. "Problem".


MfG Peter
 
Hallo Peter,

/dev/null schrieb:
Ich habe auch keinerlei Problem mit der statischen IP der udp-Verbindung, denn mir geht es hier auch nicht im Anonymität ...

/dev/null schrieb:
Und da es mir nicht um kommerzielle VPN-Anbieter geht, sondern ich selbst der "VPN-Anbieter" bin, ist für mich auch alles
was Anonymität betrifft, kein Thema.

Ich kannte den Aufbau deines Vorhabens nicht, deshalb habe ich das Thema völlig verfehlt.

Die Aufgabenstellung des oben beschriebenen Tests war
"Die sichere Verwendung unterschiedlicher Angebote von fremden, (kommerzielle oder freie) VPN-Anbieter",
denen man natürlich kein Vertrauen entgegenbringen kann. Ein solch anonymer Anbieter darf deshalb niemals
mein finaler Exit-Node sein, weil ich ihm damit meine Identität und meinen Traffic überlassen würde. Die Lösung des
Problems ist das Tunneln durch einen solchen VPN-Anbieter mit einem für diesen Anbieter artfremden Tunnel, was aber
mit Wireguard nicht möglich ist. Das waren meine Bedenken, die aber auf deine Anforderungen NICHT zutreffen.
Deshalb ist mein vorheriges Schreiben belanglos,... außer du traust dir selbst nicht mehr.

Gruß
Gräfin Klara
 
spoensche schrieb:
Gräfin Klara schrieb:
Verglichen habe ich Wireguard mit OpenVPN und SSH. IPSec bezeichne ich als obsolet.

IPSec ist nicht obsolet. Wie kommst du darauf, dass IPSec obsolet ist?
ICH bezeichne IPSec als obsolet, das bedeutet nichts.
Warum ich das tue? Kurzform:
IP Security steht unter ETSI (sowas wie Hüterin der Protokolle in der Telekommunikation) und ist somit auch Thema der
ETSI LI (Lawful Interception) an sehr prominenter Position seit 2017.
Grund: encryption on mobile devices, gegen die seit 3 Jahren (seit "Going Dark" von Europol) ein Krieg geführt wird.
Was ETSI LI von Außen nicht regeln kann, soll ja der Staatstrojaner von innen erledigen.
IPSec ist über IKE (Internet Key Exchange) erledigt, was das LIMS (Lawful Interception of Telecommunication Services) beweist.
Das sind nicht nur Metadaten, sondern der CC (Contents of Communication), also alle Inhalte.
Wer das nicht will, für den ist IPSec obsolet, wem es egal ist, für den ist es nicht obsolet.
Deshalb ist das nur eine individuelle und persönliche Ansicht, die aber keinesfalls eine Wertigkeit vorgibt.

Gruß
Gräfin Klara
 

spoensche

Moderator
Teammitglied
Gräfin Klara schrieb:
spoensche schrieb:
Gräfin Klara schrieb:
Verglichen habe ich Wireguard mit OpenVPN und SSH. IPSec bezeichne ich als obsolet.

IPSec ist nicht obsolet. Wie kommst du darauf, dass IPSec obsolet ist?
ICH bezeichne IPSec als obsolet, das bedeutet nichts.
Warum ich das tue? Kurzform:
IP Security steht unter ETSI (sowas wie Hüterin der Protokolle in der Telekommunikation) und ist somit auch Thema der
ETSI LI (Lawful Interception) an sehr prominenter Position seit 2017.

ETSI ist keine Hüterin, der Protokolle. Wenn dem so wäre, dann würden sie ja nicht versuchen, Standards zu untergraben um Hintertüren zum schnüffeln zu schaffen, weil diverse Institutionen mehr Arbeit, bei weniger Erfolg, in moderner Stasi Manier gerne alles Wissen möchten.

Mit nem Ü- Wagen gehts zielgerichtet und ist sogar datenschutzkonform. ;)

Die Verantwortlichen könnten ja mal mit gutem Beispiel voran gehen und Livestreams, ihrer Webcams, die ihren privaten Lebensbereich betreffen, online stellen. Sie haben ja nichts zu verheimlichen und Privatsphäre ist ja egal, weil man ja gerne unter Generallverdacht steht.

Gräfin Klara schrieb:
Grund: encryption on mobile devices, gegen die seit 3 Jahren (seit "Going Dark" von Europol) ein Krieg geführt wird.
Was ETSI LI von Außen nicht regeln kann, soll ja der Staatstrojaner von innen erledigen.
IPSec ist über IKE (Internet Key Exchange) erledigt, was das LIMS (Lawful Interception of Telecommunication Services) beweist.
Das sind nicht nur Metadaten, sondern der CC (Contents of Communication), also alle Inhalte.
Wer das nicht will, für den ist IPSec obsolet, wem es egal ist, für den ist es nicht obsolet.

Ich habe mir gerade mal das Produktblatt vom LIMS angesehen. IPSec wird da nur als Security Feature, von dem ach so tollen Produkt aufgeführt.

ETSI befürwortet ja auch Bugs der übelsten Sorte als Superduper Feature von TLS.

Alles in allem hat Etsi was von der Aktion, wir fällen Bäume, bauen Sollaranlagen für den Klimaschutz.
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
So, wieder zurück zum Thema ;-)

Ich habe das Problem gelöst. (Eine Nacht überschlafen, in Ruhe darüber nachdenken, testen, freuen ...)
Es war einfach nur ein Level 8-Fehler. Der Administrator hat eine Route nicht richtig gesetz. :p <= den roten Kopf habe ich nicht gefunden.

Fazit:
Auch mit einem uralten RasPi B1 (an jedem Endpunkt) kann man ein VPN-bauen, welches unsere 10Mbit/s Uplink voll auslastet. Und beide nur mit einem Stückchen Kabel verbunden, reizen übers VPN ihren 100Mbit/s-Anschluss auch so ziemlich aus. Aber mehr als 50/10 werde ich wohl in Hengasch nie erhalten.

Hier als "Beleg":
Code:
Aus dem entfernten Netz auf meinen Desktop:

pi@raspi-b1:~ $ sudo iperf3 -c 192.168.188.10 <== mein Desktop
Connecting to host 192.168.188.10, port 5201
[  5] local 192.168.42.150 port 60452 connected to 192.168.188.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.40 MBytes  11.7 Mbits/sec    0   94.3 KBytes
[  5]   1.00-2.00   sec  1.28 MBytes  10.7 Mbits/sec    0    157 KBytes
[  5]   2.00-3.00   sec  1.34 MBytes  11.2 Mbits/sec    0    218 KBytes
[  5]   3.00-4.00   sec  1.46 MBytes  12.3 Mbits/sec    1    247 KBytes
[  5]   4.00-5.00   sec  1.10 MBytes  9.20 Mbits/sec    1    147 KBytes
[  5]   5.00-6.00   sec  1.28 MBytes  10.7 Mbits/sec    1    114 KBytes
[  5]   6.00-7.00   sec  1.28 MBytes  10.7 Mbits/sec    7   25.2 KBytes
[  5]   7.00-8.00   sec   999 KBytes  8.18 Mbits/sec    6   27.9 KBytes
[  5]   8.00-9.00   sec  1.22 MBytes  10.2 Mbits/sec    1   35.9 KBytes
[  5]   9.00-10.00  sec  1.22 MBytes  10.2 Mbits/sec    6   14.6 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  12.6 MBytes  10.5 Mbits/sec   23             sender
[  5]   0.00-10.05  sec  11.7 MBytes  9.77 Mbits/sec receiver

iperf Done.
pi@raspi-b1:~ $


MfG Peter
Und wie immer:
Grüße nach Leipzig ...
 
Oben