danone
Goto Top

OpenVPN Speed Probleme - Grundsatz Frage

Hallo zusammen,

ich muss ein bisschen ausholen damit ihr meine Frage versteht.

Aktuell läuft eine OpenVPN Site to Site Konfiguration zwischen mir und meinem Vater.

Wir möchten Zugriff auf die Ressourcen des jeweilig andern bekommen.

Da ich bereits einen Edgerouter ER-X besitze, habe ich günstig noch einen zweiten für den Anschluss von meinem Vater gekauft.

Wir hatten so einige Einrichtungs Probleme, die wir aber durch das ubiquiti Forum lösen konnten.

Das Problem, wir haben keine zwei gleichen Anschlüsse:
Auf meiner Seite habe ich einen FTTH von der Deutschen Glasfaser (DSLite).
Auf der Seite von meinem Vater haben wir einen VDSL von der Telekom (Dual Stack)

Die aktuelle OpenVPN Site to Site, wird ausschließlich über die IPv6 (inkl DynDNS) hergestellt, da mein DSlite ja nur über diese erreichbar ist.

Jetzt ist es jedoch so, dass die Hardware Leistung der ER-X nicht ausreicht um mehr als18 Mbps innerhalb des Tunnels zu erzeugen.
Diese wird weiter gemindert wenn eine Verschlüsselung eingesetzt wird (aktuell unverschlüsselt!!)

Die mit nperf gemessenen Leistungen an unseren Anschlüssen sieht wie folgt aus:

Meiner: 430 Mbps DOWN / 211 Mbps UP
Vater: 98 Mbps DOWN / 45 Mbps UP

Mein Ziel ist es zumindest die 45 Mbps (ca 5Mb/s) für einen Download vom Vater zur mir, nutzen zu können
Anders rum denke ich sollte ein Download von mir zum Vater 98 Mbps (ca 12Mb/s) möglich sein.

Jetzt zu den Optionen, die mir selbst im Kopf rum schwirren:

1. IPsec Site to Site der beiden Edgerouter einrichten. Dies konnte ich schon mehrfach lesen, jedoch haben alle unsere Versuche fehlgeschlagen. Kann es sein, dass Provider seitig etwas rausgefiltert wird, oder ist dies grundsätzlich überhaupt untereinander mit IPv6 möglich? Finde immer nur IPv4 Szenarios...

2. Hardware aufrüsten und weiter OpenVPN nutzen, ich habe selber noch einen Intel NUC mit J3455? Müsste dann noch einen für die Vater Seite kaufen. Reichen die Büchsen aus? Gibt es noch günstige alternativen?

3. Server mieten ("die 2-3€ im Monat Dinger"), da den OpenVPN Server einrichten und mit den Edgeroutern (ka ob die das können) eine client to client Verbindung aufbauen. Die Frage dabei, bleibt das Bottleneck (hardware offload) der ER-X bestehen oder wird dabei nur die Leistung des Servers genutzt?

Ich hoffe ihr könnt mir dabei etwas unter die Arme greifen. Gerne bin auch für alternativen offen um am ende eine gut funktionierende VPN zwischen beiden Netzen zu erhalten.

LG
Dan0ne

Content-ID: 621139

Url: https://administrator.de/contentid/621139

Ausgedruckt am: 22.11.2024 um 18:11 Uhr

aqui
aqui 11.11.2020 aktualisiert um 10:39:20 Uhr
Goto Top
Zwei Dinge sind etwas wirr:
wird ausschließlich über die IPv6 (inkl DynDNS) hergestellt, da mein DSlite ja nur über diese erreichbar ist.
In Bezug auf einen IPv4 Tunnelaufbau ist diese Aussage Unsinn. Dein Daddy hat ja an seinem Telekom Anschluss eine öffentliche IP. Solange also dein Anschluss der VPN Initiator ist (also der, der den Tunnelaufbau initiiiert) und die Seite deines Daddys der Responder ist, ist auch ein v4 Tunnelaufbau problemlos möglich.
Diese o.a. Logik von dir ist also falsch. Gleichwohl kann man natürlich auch den Tunnel mit IPv6 aufbauen und darüber v4 tunneln, keine Frage und wird hier ja auch genau beschrieben.
Diese wird weiter gemindert wenn eine Verschlüsselung eingesetzt wird
Auch das ist irgendwie völlig unverständlich, denn OpenVPN ist ohne eine Verschlüsselung gar nicht nutzbar. Logisch, denn wozu sollte dann ein VPN Tunnel nütze sein ? Das würde ein VPN völlig ad absurdum führen.

Leider machst du keinerlei Angaben zur Konfig deiner OpenVPN Verbindung. Insbesondere keinerlei Angaben zur OpenVPN Konfigurations Datei. Diese wäre aber essentiell wichtig für eine Beurteilung deines Setups. Sowas weiss man eigentlich auch als Netzwerk Laie.
Ein Schlüsselpunkt ist hier die verwendete Encapsulation also die Frage ob TCP oder UDP. TCP ist hier immer kontraproduktiv weil es durch den viel größeren Paket Overhead, der MTU Problematik und daraus ggf. Fragmentierung einen erheblichen Anteil an der Performance hat. OpenVPN selber rät deshalb dringenst von einer TCP Encapsulierung ab.
Ein Punkt von vielen.... Hier kann man aber nur im freien Fall raten da du leider keinerlei Informationen zu deinem Setup lieferst.
Wie es richtig zu lösen ist erklärt dir z.B. das hiesige OpenVPN Tutorial:
Merkzettel: VPN Installation mit OpenVPN
bzw. auch
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Ziel ist es zumindest die 45 Mbps (ca 5Mb/s) für einen Download vom Vater zur mir,
Was denn nun ?? 45 oder 5 ?? Wenn, dann solltest du hier in einem Administrator Forum auch schon die richtige Nomenklatur benutzen Megabit oder Megabyte 45Mb/s = 5,6 MB/s
Dir sollte auch klar sein das der physisch mögliche Upload von 45Mbit/s niemals zu einem gleichen VPN Upload führen kann. Sowas anzunehmen wäre naiv. Du musst bedenken das du den IP Overhead hast und den VPN Overhead der die Nettoleistung entsprechend limitiert. Einen massgeblichen Anteil hat die CPU bzw. Krypto Performance des VPN Devices auf beiden Seiten. Hat das keinerlei Krypto Hardware an Board und muss alles in Software machen hat das einen massiven Einfluss auf die VPN Tunnelperformance. Hier ist Hardware die mindestens AES NI supportet zwingend. Auch dazu von dir keinerlei Infos. face-sad
Zu den 3 Punkten:
1.)
Wir vermutlich wenig bringen. Die Performance Unterschiede der einzelnen VPN Protokolle sind eher geringfügig. IPsec ist eigentlich eine Lachnummer aber dadurch das du DS-Lite Opfer bist muss hier auch zwingend wieder gelten: DU bis Initiator und dein Daddy Responder. Außerdem ist IPsec NAT Traversal über UDP 4500 Pflicht.
Diese Tutorials beschreiben das HowTo in einer Router Kaskade:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
bzw. die Einrichtung:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
IPsec IKEv2 Standort VPN Vernetzung mit Cisco, pfSense OPNsense und Mikrotik
usw.
2.)
Wenn die CPU des NUC AES NI supportet wäre das eine Option. Die andere Seite natürlich auch.
Preiswertere Alternative: Raspberry Pi 4 (siehe o.a. OVPN Tutorial)
3.)
Macht sehr wenig Sinn, denn du hast dann 2 sinnlose Hops mehr dazwischen die wieder Performance kosten und über Netze gehen dessen Auslastung und damit Bandbreite du nicht kennst. Sowas macht man nur wenn man 2 DS-Lite Opfer hat was bei dir ja glücklicherweise nicht der Fall ist.
Dieser_Thread beschreibt so ein Design mit OpenVPN.
LordGurke
LordGurke 11.11.2020 um 13:50:20 Uhr
Goto Top
Zitat von @aqui:

Zwei Dinge sind etwas wirr:
wird ausschließlich über die IPv6 (inkl DynDNS) hergestellt, da mein DSlite ja nur über diese erreichbar ist.
In Bezug auf einen IPv4 Tunnelaufbau ist diese Aussage Unsinn. Dein Daddy hat ja an seinem Telekom Anschluss eine öffentliche IP. Solange also dein Anschluss der VPN Initiator ist (also der, der den Tunnelaufbau initiiiert) und die Seite deines Daddys der Responder ist, ist auch ein v4 Tunnelaufbau problemlos möglich.

Aber dann musst du trotzdem durch ein CGN hindurch den Tunnel aufbauen und das will man aus Gründen der Performance und Stabilität vermeiden. IPv6 ist also weiterhin dringend zu bevorzugen.


Diese wird weiter gemindert wenn eine Verschlüsselung eingesetzt wird
Auch das ist irgendwie völlig unverständlich, denn OpenVPN ist ohne eine Verschlüsselung gar nicht nutzbar.

Du kannst OpenVPN mit NULL-Ciphers betreiben. Dann ist da keine Verschlüsselung mehr drin.
Es gibt Anwendungszwecke, wo man nur tunneln will ohne zu verschlüsseln, aber die sind selten und dieser Anwendungsfall vom TO ist keiner davon face-wink


Zu den 3 Punkten:
1.)
Wir vermutlich wenig bringen. Die Performance Unterschiede der einzelnen VPN Protokolle sind eher geringfügig. IPsec ist eigentlich eine Lachnummer aber dadurch das du DS-Lite Opfer bist muss hier auch zwingend wieder gelten: DU bis Initiator und dein Daddy Responder.

Naja, außer man nimmt IPv6, was wie oben beschrieben zu bevorzugen ist face-wink


Eine wichtige Frage wäre noch, welche Ciphers verwendet werden.
In Freier Wildbahn anzutreffen ist in der heutigen Zeit eigentlich nur AES-Beschleunigung, selten noch 3DES.
Aber 3DES will man nicht mehr nutzen, also müsstest du AES als Verschlüsselung verwenden. OpenVPN nutzt aber standardmäßig Blowfish, was eine vergleichsweise langsame Verschlüsselung ist, die dann natürlich nicht von AES-Acceleration profitieren kann.
AES128 mit SHA256 ist in Puncto Sicherheit und Performance ein guter Wert.

Hier findest du eine Übersicht, welche Ciphers mit Hardware-Offloading außerhalb der CPU verwendet werden können:
https://help.ui.com/hc/en-us/articles/115006567467-EdgeRouter-Hardware-O ...

Da taucht allerdings OpenVPN nicht auf, eventuell musst du also auf IPsec wechseln. Auch das sollte per IPv6 aufgebaut werden können.
aqui
aqui 11.11.2020 aktualisiert um 15:26:38 Uhr
Goto Top
Guter Punkt mit der Krypto Beschleunigung bezogen auf die verwendeten Chiffren und Silizium ! Sowas übersieht man oft im Eifer des Gefechts.
Mit der native IPv6 Anbindung ist zweifelsohne natürlich ebenso richtig. Danke für die Korrektur hier... face-wink
danone
danone 11.11.2020 um 20:07:39 Uhr
Goto Top
Hi danke dir erstmal für deine "teilweise" nützlichen Antworten

Falls du Interesse am meiner laufenden Config hast dann hier:

https://community.ui.com/questions/OpenVPN-Site-to-Site-with-IPv6-DNS-Me ...

Zitat von @aqui:

Zwei Dinge sind etwas wirr:
wird ausschließlich über die IPv6 (inkl DynDNS) hergestellt, da mein DSlite ja nur über diese erreichbar ist.
In Bezug auf einen IPv4 Tunnelaufbau ist diese Aussage Unsinn. Dein Daddy hat ja an seinem Telekom Anschluss eine öffentliche IP. Solange also dein Anschluss der VPN Initiator ist (also der, der den Tunnelaufbau initiiiert) und die Seite deines Daddys der Responder ist, ist auch ein v4 Tunnelaufbau problemlos möglich.
Diese o.a. Logik von dir ist also falsch. Gleichwohl kann man natürlich auch den Tunnel mit IPv6 aufbauen und darüber v4 tunneln, keine Frage und wird hier ja auch genau beschrieben.

Naja ich baue ja keine Server / Client Verbindung auf sondern eine SITE TO SITE, also wird die Verbindung von beiden Seiten aus initiiert. Wenn also mein Dad die Verbindung zu mir aufbaut, kann dieser mich nicht erreichen. Einen Tunnel/Portmapper möchte ich tunlichst vermeiden!

Zitat von @aqui:

Diese wird weiter gemindert wenn eine Verschlüsselung eingesetzt wird
Auch das ist irgendwie völlig unverständlich, denn OpenVPN ist ohne eine Verschlüsselung gar nicht nutzbar. Logisch, denn wozu sollte dann ein VPN Tunnel nütze sein ? Das würde ein VPN völlig ad absurdum führen.

Klar kann man OpenVPN ohne Verschlüsselung betreiben: --cipher none
Dies setze ich jetzt gerade ein um die Geschwindigkeit der Hardware zu testen ohne Verschlüsselung. Und dabei ist nun mal bei 18 Mbps (verzeihe 18Mbit ;) ) Schluss!
aes128, liefert mir ca 720kb/s
aes256 liefert mir ca 330kb/s
--ciper none liefert mir 2,25mb/s

Ich teste kopier Vorgänge von meinem NAS auf der Seite vom Vater. Dann steht mein "hoher" Upload (200Mbit) zur Verfügung.

Zitat von @aqui:

Ein Schlüsselpunkt ist hier die verwendete Encapsulation also die Frage ob TCP oder UDP. TCP ist hier immer kontraproduktiv weil es durch den viel größeren Paket Overhead, der MTU Problematik und daraus ggf. Fragmentierung einen erheblichen Anteil an der Performance hat. OpenVPN selber rät deshalb dringenst von einer TCP Encapsulierung ab.

Auf beiden Seiten UDP6

Zitat von @aqui:

Ziel ist es zumindest die 45 Mbps (ca 5Mb/s) für einen Download vom Vater zur mir,
Was denn nun ?? 45 oder 5 ?? Wenn, dann solltest du hier in einem Administrator Forum auch schon die richtige Nomenklatur benutzen Megabit oder Megabyte 45Mb/s = 5,6 MB/s
Dir sollte auch klar sein das der physisch mögliche Upload von 45Mbit/s niemals zu einem gleichen VPN Upload führen kann. Sowas anzunehmen wäre naiv. Du musst bedenken das du den IP Overhead hast und den VPN Overhead der die Nettoleistung entsprechend limitiert. Einen massgeblichen Anteil hat die CPU bzw. Krypto Performance des VPN Devices auf beiden Seiten. Hat das keinerlei Krypto Hardware an Board und muss alles in Software machen hat das einen massiven Einfluss auf die VPN Tunnelperformance. Hier ist Hardware die mindestens AES NI supportet zwingend. Auch dazu von dir keinerlei Infos. face-sad

Ich schrieb doch, dass es sich bei der Hardware um Edgerouter ER-X handelt, also was ist daran nicht zu verstehen. Natürlich liefert die Hardware kein AES NI Support, sonst würde es ja nicht zum "hardware offload" kommen ...: https://help.ui.com/hc/en-us/articles/115006567467#3

Ansonsten: Mbps = Mbit/s
und die 5MB/s waren nur grob überschlagen, da die Geschwindigkeit oft schwank.

Zitat von @aqui:
1.)
Wir vermutlich wenig bringen. Die Performance Unterschiede der einzelnen VPN Protokolle sind eher geringfügig. IPsec ist eigentlich eine Lachnummer aber dadurch das du DS-Lite Opfer bist muss hier auch zwingend wieder gelten: DU bis Initiator und dein Daddy Responder. Außerdem ist IPsec NAT Traversal über UDP 4500 Pflicht.

... und wie müsste es aussehen, wenn ipv6 only genutzt wird? Kann das überhaupt funktionieren? Soll ja am ende eine SITE TO SITE sein, sodass beide Seiten Initiator sind...


2.)
Wenn die CPU des NUC AES NI supportet wäre das eine Option. Die andere Seite natürlich auch.
Preiswertere Alternative: Raspberry Pi 4 (siehe o.a. OVPN Tutorial)

Nur leider liefert der Raspberry PI 4 leider auch keinen AES NI support daher scheiden die PI's für OpenVPN aus
Quelle: https://raspberrypi.stackexchange.com/questions/106474/does-raspberry-pi ...
Ja die CPU vom NUC hat AES NI support


3.)
Macht sehr wenig Sinn, denn du hast dann 2 sinnlose Hops mehr dazwischen die wieder Performance kosten und über Netze gehen dessen Auslastung und damit Bandbreite du nicht kennst. Sowas macht man nur wenn man 2 DS-Lite Opfer hat was bei dir ja glücklicherweise nicht der Fall ist.
Dieser_Thread beschreibt so ein Design mit OpenVPN.

Das mit einem gewissen Verlust zu rechnen ist, ist mir vollkommen bewusst. Die Frage geht eher in die Richtung ob mir ein Client - Client mode am ende den fehlenden AES NI Support in den Edgeroutern ER-X erspart, wenn der gemietete Server (zb von hetzner) einen AES NI Support liefert. Oder wird hierbei auch die Verschlüsselungsleistung auf den "Clients" benötigt.


Mit den Raspberry PI bin ich dann auch nochmal auf die Suche gegangen. Im Keller habe ich noch aus irgendwelchen Tests 2x PI's 3B+.
Ich werde am Wochenende mal die Wireguard Lösung probieren.

Mit Wireguard sollen alle Kerne genutzt werden können und so sind beim PI 2 schon 95Mbit möglich.
Beim PI 3B+ dann entsprechend 280Mbit (Interface kann ja nur 300Mbit auch wenns 1Gbit ist jedoch über USB angebunden intern)