pfSense Usergroup #016 - 2022-03-04 - 17:00
-
@jegr Abend, auch der Wechsel auf AES-256-GCM hat die Lage nicht geändert, 100% CPU Last auf dem Windows VPS.
C:\iperf>iperf3.exe -c 10.0.9.2 -R -P 5 Connecting to host 10.0.9.2, port 5201 Reverse mode, remote host 10.0.9.2 is sending [ 4] local 192.168.1.10 port 63195 connected to 10.0.9.2 port 5201 [ 6] local 192.168.1.10 port 63196 connected to 10.0.9.2 port 5201 [ 8] local 192.168.1.10 port 63197 connected to 10.0.9.2 port 5201 [ 10] local 192.168.1.10 port 63198 connected to 10.0.9.2 port 5201 [ 12] local 192.168.1.10 port 63199 connected to 10.0.9.2 port 5201 [ ID] Interval Transfer Bandwidth [SUM] 0.00-10.00 sec 164 MBytes 138 Mbits/sec sender [SUM] 0.00-10.00 sec 164 MBytes 138 Mbits/sec receiverIch werde also morgen nochmal WG einrichten und gucken, ob der Vorteil von damals noch besteht. Bin jetzt auch frohen Mutes was das NATing betrifft, denke das kriege ich dieses mal hin auf dem WinServer.
PS: Auch mit AES-128-GCM keine Änderung.
-
Also bei mir ist die Sache eindeutig, wenn ich nicht vorher beim OVPN Server noch irgendeine nicht optimal Einstellung drin habe.
Mit Wireguard:
C:\iperf>iperf3.exe -c 10.1.9.1 -R -P 5 Connecting to host 10.1.9.1, port 5201 Reverse mode, remote host 10.1.9.1 is sending [ 4] local 192.168.1.10 port 65281 connected to 10.1.9.1 port 5201 [ 6] local 192.168.1.10 port 65282 connected to 10.1.9.1 port 5201 [ 8] local 192.168.1.10 port 65283 connected to 10.1.9.1 port 5201 [ 10] local 192.168.1.10 port 65284 connected to 10.1.9.1 port 5201 [ 12] local 192.168.1.10 port 65285 connected to 10.1.9.1 port 5201 [ ID] Interval Transfer Bandwidth [SUM] 0.00-10.00 sec 304 MBytes 255 Mbits/sec sender [SUM] 0.00-10.00 sec 304 MBytes 255 Mbits/sec receiverNAT und Autostart unter Windows habe ich auch hinbekommen, damit fliegt OVPN raus.
-
@bob-dig AMD K6? Das war doch ein Duron oder Chomper? Die sind doch 19-vorm-Krieg. Das der keine ordentliche AES-GCM hinbekommt würde mich jetzt nicht super wundern. Ist das nur ne falsche Anzeige oder wirklich so ne alte Kiste? Wenn ja - kein Wunder. AES-NI war 2010 von Intel eingeführt. K6 ist definitiv älter. Dass der mit der Crypto zu Knabbern hat wundert nicht. Da kann Wireguard im Kernel mit CHACHA20 und stärkerer Parallelisierung mehr rausholen.
-
@jegr Das war der VPS bei netcup für unter drei Öcken/M.
WG läuft bis jetzt auch rund. Diesen stateless approach habe ich jetzt auch mal umgesetzt, kein monitoring mehr, kein keep alive, sondern beide Seiten können die Verbindung jederzeit herstellen. Wahrscheinlich nix für den Profi-Bereich aber es hat was, komme mir so öko vor. -
@bob-dig said in pfSense Usergroup #016 - 2022-03-04 - 17:00:
@jegr Das war der VPS bei netcup für unter drei Öcken/M.
WG läuft bis jetzt auch rund. Diesen stateless approach habe ich jetzt auch mal umgesetzt, kein monitoring mehr, kein keep alive, sondern beide Seiten können die Verbindung jederzeit herstellen. Wahrscheinlich nix für den Profi-Bereich aber es hat was, komme mir so öko vor.Hrhr ;) Ey wenns läuft ist doch gut. Ich habe ja selbst gesagt dass ich denke, dass WG da gerade im S2S Mode den Rang ablaufen wird. Aber Einwahl für >5-10 Leute ist halt ein Krampf wenn du das alles selbst konfigurieren und bei Leuten einrichten musst. Da muss noch mehr Feinschliff und Support via Export Assistenten oder QR Code oder Kram her :)
-
@jegr Das auf jeden Fall. Es gibt weitere Sachen, die mich wundern.
Wireguard für Windows erlaubt mir meinen "eigenen" privaten Key zu exportieren, zusammen mit dem öffentlichen Key der Gegenseite.
Ich habe dies nun gemacht und anschließend den Tunnel komplett im Programm gelöscht. Anschließend habe ich das ganze wieder importiert und mein öffentlicher (edit) Key, der nicht Teil des Exportes war, wurde ebenfalls wieder verwendet. Sprich, mein öffentlicher (edit) Key ist wohl Teil der Installation geworden(?), aber ist selbst, zumindest nicht offensichtlich, exportierbar.
Das macht ein Deployen natürlich ebenfalls schwierig. Für mich privat natürlich kein Problem... Vielleicht werde ich mal WG für Android probieren, um mir ein noch besseres Bild der Lage zu machen.
Edit: Musste was korrigieren. -
Holy... der öffentliche Schlüssel kann bei WG jederzeit aus dem Privaten Schlüssel gebildet werden? Okay, ich habe das Protokoll nicht verstanden.
Edit: Verstanden wäre eh zu viel gesagt, aber nach etwas Recherche auf youtube: Nicht nur, dass es genauso ist, der öffentliche kann jederzeit aus dem privaten gebildet werden, auch gibt es keinerlei "Verhandlungen", also den ungeschützten Port auf dem VPS zu öffnen ist völlig risikolos und darauf antwortet auch nichts gegenüber einem Dritten, sehr geil.
-
@bob-dig said in pfSense Usergroup #016 - 2022-03-04 - 17:00:
Holy... der öffentliche Schlüssel kann bei WG jederzeit aus dem Privaten Schlüssel gebildet werden? Okay, ich habe das Protokoll nicht verstanden.
Hö? Na klar wird der öffi Schlüssel AUS dem privaten gebildet. Ist ja ein Schlüsselpaar. So funktioniert GPG/PGP etc. genauso. Oder SSH. Oder whatever. Aus dem private Key ist IMMER logischerweise der öffentliche ableit-/errechenbar. Warum auch nicht? Darum ists ja der PRIVATE Schlüssel
Darum gibt es ja die Möglichkeit bei WG zusätzlich zum reinen Schlüsselaustausch als 2. Faktor noch einen PSK on top zu definieren. Damit müssen die Schlüssel auf beiden Seiten passen UND der gemeinsame Verbindungs-PSK.
Naja antwortet "nichts" ist ja so auch nicht richtig. Es antwortet Wireguard. Und wartet, dass du was tust und dich mit deinem Schlüssel etc. vorstellst. Und wenn er dich nicht kennt - fliegste halt raus. Auch nicht signifikant anders als bei SSH mit "Pubkey only" Setup, dann gibts auch kein Passwortrategedöns und die andere Seite fliegt direkt bei nicht-senden eines Keys hochkant raus.
-
@jegr Also ich meine mal gehört zu haben, dass die beiden Schlüssel zwar in einer Beziehung stehen, aber quasi gleichwertig sind, also man könnte sie rein technisch auch tauschen, hier scheint es mir aber anders zu sein.
Der PSK scheint wohl eher gegen quanten-computer zu schützen, hab ich natürlich auch eingerichtet.
Ich hab keine Ahnung von SSH, leider, aber bei WG schlägt nicht mal ein Portscan an, weil WG halt nichts antwortet, solange du nicht autorisiert bist. Keine Ahnung, ob das bei SSH genauso ist.
Kurz, auch ich bin jetzt begeistert.
-
@bob-dig said in pfSense Usergroup #016 - 2022-03-04 - 17:00:
@jegr Also ich meine mal gehört zu haben, dass die beiden Schlüssel zwar in einer Beziehung stehen, aber quasi gleichwertig sind, also man könnte sie rein technisch auch tauschen, hier scheint es mir aber anders zu sein.
Nope, never. Sonst wäre das eine kein öffentlicher Schlüssel. Einem public key ist die Tatsache zu eigen, dass ich ihn problemlos weitergeben und bekannt machen darf und kann ohne Rückschlüssel auf den private key zu haben. Normalerweise wird das mathematisch via Falltür Algorithmus gemacht, also ne Rechnung, die nicht reversibel ist aber immer den gleichen Quark ausgibt einfach ausgedrückt. Somit kannst du aus Priv immer Pub machen aber aus Pub niemals Priv.
Andernfalls wäre das ja brandgefährlich weil du aus den öffentlichen Keys private ableiten könntest
Bei SSH antwortet natürlich der Server - ist eine TCP Verbindung. Wireguard läuft ja auf UDP und das ist normalerweise stateless. UDP Ports zu erkennen ist daher etwas tricky aber IMHO kann man WG Ports schon erkennen. Man kommt halt nur nicht sehr weit ;) Und das ist ja auch sinnvoll, denn man will den ja nicht verschließen müssen
OVPN macht an der Stelle eben beides, kann UDP oder TCP und verhält sich daher anders. Nicht schlechter oder besser einfach anders. Man muss sich nur im Hinterkopf behalten, dass WG eben noch jung ist, es auch was schiefgehen könnte und es aktuell noch "beta" ist. Alpha nicht mehr, aber auch nicht "rock solid super stable". Wenn man das auf'm Schirm hat - let's go :)
-
@jegr said in pfSense Usergroup #016 - 2022-03-04 - 17:00:
Nope, never.
Danke, keine Ahnung, wie sich das bei mir eingeschlichen hatte.
