Beiträge von frank_m

Ähh, was sind diese Screenshots? Mit iperf hat das jedenfalls nichts zu tun. Außerdem sehe ich da wg0 in der Übersicht. Das ist falsch, es geht ja darum, die Geschwindigkeit ohne VPN festzustellen. Vor allem bei der Verbindung übers VLAN kann wg0 ja keine Rolle spielen. Außerdem sind die Ergebnisse exakt gleich. Irgendwas stimmt da nicht.

iperf auf der Konsole, am besten iperf3. Mit 10 parallelen TCP Streams, und natürlich separate Messungen in beide Richtungen. Davon dann bitte das Ergebnis als Text in CODE Tags hier reinkopieren.

Ah, ok. Das hatte ich falsch verstanden.

Wie sieht denn die Netzwerkperformance zwischen Netcup OpenSense und Server aus und von der Netcup Opensense zu dir nach Hause? Am besten jeweils mit iperf messen.

Dann musst du herausfinden, welche Firewall und Routing Regeln die OpenSense aufsetzt. Macht sie NAT fürs VPN? Das braucht ja eigentlich nicht sein.

Zitat von Antijurist

1. Woher weiß ich, ob ich die userspace oder die kernel Version bzw. wo kann ich dies ersehen?

Du hast es ja mal installiert und musstest dich dabei entscheiden. Das heißt, du solltest es am besten wissen.

Zitat von Antijurist

Was genau meinst du mit Routing ins VLAN?

Machst du NAT Routing? Oder vollwertig? Oder bridged du die Interfaces vielleicht? Sind Filter aktiv, z.B. IP-Blacklisten und wie sind die realisiert? Halt alles rund um IP-Forwarding, IP-Tables, EP-Tables und nftables, was du so eingestellt hast. Da musst du dir ja Gedanken drüber gemacht haben, um zum einen deinen Server zu schützen und zum anderen den Zugriff auf den Windows Server zu realisieren. Unten schreibst du was von VM. Bei VMs hast du ja virtuelle Netzwerke im Host und zur VM, und das VLAN ist ja eine Netzwerkkarte auf dem Host. D.h., dein Routing muss vom Host durch die VM zum VLAN realisiert werden. Wie genau hast du das gemacht?

Zitat von Antijurist

5. OPNsense läuft als VM auf einem VPS.

Als VM? Was kommt als Hypervisor zum Einsatz? Viele VMs lassen sich ja nicht einrichten aufgrund der fehlenden nested virtualization bei Netcup. Das kostet natürlich auch Performance.

Wenn ich mal mein Bauchgefühl rauslassen darf: Du hast das Routing Setup durch die VM verdaddelt. Dazu passt auch, dass die Performance einbricht, sobald die OpenSense im Spiel ist.

Danke.

Das können wir dir alles nicht sagen, ohne Hintergrundinformationen über deinen Aufbau. Deshalb würde ich empfehlen, du beantwortest die offenen Fragen von oben, dann sehen wir weiter.

Vom Bauchgefühl her hätte ich das Problem eher in der vorgefertigten OpenVPN Distri gesucht. Solche Distris setzen gern auf NAT für den VPN Zugang, damit ist man mit Verbindungen von außen natürlich raus. Außerdem unterbinden sie gern die Kommunikation zwischen den VPN Clients. Für solche speziellen Setups empfehle ich immer eine manuelle Konfiguration. Und ggf. auch Wirwguard anstatt OpenVPN.

ABER:

Zitat von donald.polzin

Der Draytek Support sagt nach diversen Test-Session: das geht nicht ... mit deren L2L OpenVPN Client. Nun kann ein Draytek Router neben OVPN-AS andere L2L Verbindungen aufbauen mit diversen weiteren Protokollen (PPTP, IPsec Tunnel, L2TP with IPsec Policy, SSL Tunnel).

Warum geht es nicht? Und du schreibst, dass der Draytek neben OVPN auch andere L2L aufbauen kann. Das ist doch exakt das, was du willst.

Zitat von H6G

aus Erfahrung: es gibt bei Kabel Deutschland / Vodafone Kabel seit jeher Geschwindigkeitsprobleme mit UDP VPNs

Das mag ja sein, das bestreite ich ja auch gar nicht. Man müsste halt schauen, woran es genau liegt.

Die Frage ist: Ist das wirklich ein VPN im eigentlichen Sinne, oder so ein Dienst wie NordVPN. Wenn es um NordVPN etc. geht, dann kommen halt Peering Effekte zum tragen. Ich hab gestern mal gegoogelt, und konnte keine Belege oder Threads finden, die von einem generischen Problem bei Wireguard oder OpenVPN berichteten. Von NordVPN und Konsorten allerdings viele.Für mich sieht das im Moment so aus, als ob man da mal wieder klassisch am Problem vorbei diskutiert.

Zitat von readyfornix

Dazu gibt es einen interessanten Artikel

https://vpntester.org/blog/int…uer-vpn-services-umgehen/

Ich hab jetzt gerade noch mal in einer freien Minute in den Artikel geschaut: Der meint gar nicht VPN im eigentlichen Sinne. Der redet von NordVPN und diesen komischen Proxy-Alternativen und ähnlichen Bauernfängern. Wenn es da Probleme im Kabelnetz gibt, dann hat das Millionen Gründe, aber mit Sicherheit nicht irgendwelche Signalisierungsdaten zwischen den Kabelmodems.

Je mehr ich davon lese, desto mehr regt der mich auf:

Zitat

IPsec/IKEv2 wird wie SSL Datenverbindungen (Webseiten gehandhabt. Da aber auch Downloads eine hohe Datenlast erzeugen können, werden diese Daten üblicherweise bis zu einem erlaubten reservierten Maximum durchgelassen. Daher sind Beschränkungen meistens nur dann vorhanden, wenn zu viele Teilnehmer dieses Protokoll parallel verwenden oder zur selben Zeit auch Streaming von Netflix oder anderen Portalen verwenden.

Damit haben OpenVPN Nutzer gewonnen. Denn OpenVPN macht nichts anderes, als eine SSL Verbindung aufzubauen und darüber den Traffic zu tunneln. Demnach müsste VPN im Kabelnetz von allen Diensten am besten funktionieren.

Ich könnte jetzt noch seine Beispielrechnung auseinandernehmen, die mit den 50 TV Programmen und den Management Daten usw, aber ich lasse es lieber, im Sinne meiner Gesundheit.

Vergiss alles, was du je aus diesem Artikel mitgenommen hast. Wer auch immer das geschrieben hat: Er hatte wirklich überhaupt keine Ahnung. Aber wirklich so überhaupt nicht.

Nur so am Rande, hab gerade eine Mail von Microsoft bekommen, dass sich die Microsoft 365 Business Preise erhöhen, und zwar ab sofort bereits mit der nächsten Abrechnung und um 24%. Aber mir wird angeboten, die "Automatische Verlängerung" des Abos zu beenden.

Zitat von readyfornix

Nur im Büro oder zuhause in D (beides Kabel) ist es langsam. Egal ob Provider- oder eigenes Kabelmodem.

Ich will gar nicht ausschließen, dass es im Kabel-Internet ein Problem gibt. Aber so, wie es im Artikel beschrieben wurde, ist es einfach nur grober Unfug. Da müsste man sich genauer ansehen, was schief geht.

Zitat von readyfornix

Außer die MTU zu verändern kann ich ja wenig machen. Hat leider nichts gebracht.

Das sehe ich komplett anders. Bei Wireguard ist die Einflussnahme zwar begrenzter, dennoch gibt es auch da Ansätze abseits der MTU. Bei OpenVPN sind die Konfigurationsmöglichkeiten schier unendlich - allein die Kombinationen aus den verschiedenen Algorithmen, Topologien und Transportprotokollen erlauben tausende Konfigurationen mit Einfluss auf die Performance.

Zitat von readyfornix

Dazu gibt es einen interessanten Artikel

https://vpntester.org/blog/int…uer-vpn-services-umgehen/

Ich hab selten einen Artikel gelesen, in dem so viele grundlegende Fehler drin sind, wie der. Beispiel:

Zitat

OpenVPN UDP Daten sind Layer3 basiert und da dies für die Verwaltung des Netzwerkes selbst relevant ist, werden die Rückdaten von OpenVPN meistens bewusst gedrosselt um übermässige Nutzung die die Verwaltung des DOCSIS Netzwerkes beeinflussen würde zu vermeiden.OpenVPN TCP Daten sind Layer2 basiert und entsprechen damit meistens einer anderen Übermittlungsmethodik im Netzwerk. In vielen Fällen ist daher OpenVPN mit TCP schneller als über UDP.

UDP und TCP arbeiten beide auf Layer 4. Bei TCP können sich die Congestion Control der Payload und der Übertragungsebene ins Gehege kommen und sich gegenseitig beeinflussen: Das ist keinesfalls bedingungslos zu empfehlen.

Zitat

Mit OpenVPN sind üblicherweise nie mehr als 350MB/s nutzbar, nur in Ausnahmen auch bis zu 400MB/s, was an der Architektur des Protokolles „OpenVPN“ selbst liegt.

Bei der Aussage kann man echt nur weglaufen. Ob und wie schnell OpenVPN nutzbar ist, hängt von vielen Faktoren ab, vor allem aber von der Rechenleistung der Endpunkte und der Geschwindigkeit der Übertragungsstrecke. Auf 2.5 GBIt/s Verbindungen lassen sich mehr als 350 oder 400 MBIt/s erreichen, auch mit OpenVPN.

Zitat von readyfornix

Ich bin kein Netzwerkprofi, aber es könnte an UDP und Traffic Shaping seitens des Providers liegen. Die Kabelmodems kommunizieren intern über UDP Layer 3. Damit die Verwaltung des Netzwerks sichergestellt bleibt, gibt es meistens eine Drosselung der eingehenden Daten.

Davon höre ich zum ersten Mal. Ich kann es allerdings auch nicht vollständig ausschließen. Fakt ist jedenfalls, dass der Zusammenhang in dem Artikel vollkommen falsch dargestellt wird: Das ist einfach nur Bullshit. Wenn die Ursache für langsame VPN Verbindungen wirklich in der Signalisierung der Kabelmodems liegt, dann müssten die anderen Dienste wie TCP ja auch betroffen sein. Oder warum sollte man nur UDP ausbremsen, wenn jede TCP Verbindung die Modem-Signalisierung dann ausbremst? Das macht ja gar keinen Sinn. Außerdem zeigen seine Messungen über VPN gut 100 MBit/s auf einer 1 GBIt/s Verbindung: Wenn 90% der Leitung für Signalisierung draufgehen, dann geht aber irgendwas schief ...

Ganz ehrlich: Der Artikel ist vollkommen substanzlos. Das ist in dieser Form einfach nur Quatsch. Ich könnte zig weitere Argumente finden, wo Dinge in diesem Artikel einfach nachweislich falsch beschrieben werden. Deshalb glaube ich auch nicht an einen Einfluss der Signalisierung auf die UDP Datenraten. Jedenfalls nicht in der Größenordnung.

Ohne weitere Informationen zum Aufbau des Netzes werden wir nicht helfen können. Erste Frage: Nutzt du die Kernel-Version von Wireguard oder die Userspace Version? Wie ist das Routing ins VLAN realisiert? NAT? Vollwertig? Wie ist die Auslastung des Netcup Rechners? Wie schnell ist die Internetverbindung zwischen deinem Heimnetz und dem Netcup Rechner? Wie ist OpenSense in deinem Netcup Rechner realisiert? EIn Conttainer?

Ich erreiche mit einem RS 2000 locker 100 MBit/s über Wireguard ins VLAN des RS. Wiregaurd läuft native im Kernel-Modus auf dem RS und kein NAT Routing zwischen den Instanzen (VLAN IPs sind im Allowed Net).

I am using also virtio.

iperf3 -c fra.speedtest.clouvider.net -p 5202 -4
Connecting to host fra.speedtest.clouvider.net, port 5202
[  5] local 46.38.255.110 port 57070 connected to 91.199.118.184 port 5202
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   290 MBytes  2.43 Gbits/sec  2719    938 KBytes
[  5]   1.00-2.00   sec   198 MBytes  1.66 Gbits/sec    1    809 KBytes
[  5]   2.00-3.00   sec   215 MBytes  1.80 Gbits/sec    0    994 KBytes
[  5]   3.00-4.00   sec   259 MBytes  2.17 Gbits/sec    0   1.15 MBytes
[  5]   4.00-5.00   sec   266 MBytes  2.23 Gbits/sec   45    971 KBytes
[  5]   5.00-6.00   sec   252 MBytes  2.12 Gbits/sec    0   1.13 MBytes
[  5]   6.00-7.00   sec   272 MBytes  2.29 Gbits/sec   45    946 KBytes
[  5]   7.00-8.00   sec   245 MBytes  2.06 Gbits/sec    0   1.10 MBytes
[  5]   8.00-9.00   sec   279 MBytes  2.34 Gbits/sec   45    912 KBytes
[  5]   9.00-10.00  sec   236 MBytes  1.98 Gbits/sec    0   1.07 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.45 GBytes  2.11 Gbits/sec  2855             sender
[  5]   0.00-10.00  sec  2.44 GBytes  2.09 Gbits/sec                  receiver

iperf Done.

It is an RS 2000 G9.5 SE, so results are compareable.

Are you using firewalls? Traffic Shaping? Is the host very occupied?

Zitat von ASS

Auf welcher Grundlage kommst du zu dieser Annahme?

Weil ich noch nie erlebt habe, dass jemand für https://www verwarnt wurde. Wohl aber für https:///aaa.bbb.de, wenn aaa.bbb entsprechende Inhalte hatten. Und das muss ja bei dir der Fall gewesen sein, du schreibst ja selber

Zitat von ASS

Die Forensoftware hat Worte aus meinem Fließtext genommen, eine URL draus gemacht und diese gleich auch noch anklickbar verlinkt.

Die "Worte aus dem Fließtext" sind das Problem, völlig egal, ob sie als URL oder als Fließtext im Beitrag standen.

Wann wirst du verstehen, dass nicht die Darreichungsform, sondern der Inhalt das Problem war?

Zitat von ASS

Selbst wenn es für dich "keine Neuheit" ist, so ist es doch recht Fragwürdig, wenn einem durch diese ungefragte Abänderung, die dann auch noch Sinnentstellend ist, vom Forenbetreiber eine "Abmahnung" mit 20 Punkten und Ablaufdatum "Nie" ins Profil geknallt wird.

Aber dieser Automatismus fügt doch lediglich ein "https://www" davor ein. An der eigentlichen Domain ändert er doch nichts. Die Verwarnung wird es dagegen eher für die Domain, aber nicht für das www gegeben haben.

Man kann sich über CCP ins SCP einloggen (SCP Autologin). Hast du das schon probiert?

Du brauchst das Original AVM Kabel. Die Kabel von AVM haben keine standardmäßige Belegung, da häufig auch ISDN und DSL Signale über einen RJ45 Anschluss geführt wurden. Gerade bei der 7583 dürfte das noch der Fall gewesen sein. Die hat dazu noch 2 WAN Anschlüsse, was meines Wissens keine andere AVM Box hat. Wenn das original AVM Kabel zu kurz ist, dann kaufe eine Standard-TAE Verlängerung.

Ob dieses Amazon Kabel RJ45 oder RJ11 hat, kann man kaum erkennen. In der Beschreibung steht RJ45, das Foto sieht aber eher nach RJ11 aus. Wenn es RJ45 ist, dann ist es ein qualitativ minderwertiger Stecker.

Was mich ein bisschen wundert: die 7582 ist für G.fast, die 7583 unterstützt 2xVDSL für Bonding. Beide sind also für komplett unterschiedliche Anschlusstypen gedacht. Bist du sicher, dass du den passenden Anschluss für solche Exoten hast?

Stimmt, sorry, da war ein Fehler, Ich habs korrigiert.

iptables -A FORWARD -i eth0 -p tcp --dport portxy -d ip-zerotier-intern -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -d 37.120.x.y -p tcp --dport portxy -j DNAT --to-destination ip-zerotier-intern:portxy

Zitat von KrisAusEU

Jetzt muss ich doch eigentlich "nur" dem Netcup-Server beibringen, dass er Anfragen an 37.120.x.y:portxy an ip-zerotier-intern:portxy durchreicht ?!

Geht das? Wenn ja, wo bzw. wie?

Ja, genau so geht das.

iptables -A FORWARD -i eth0 -p tcp --dport portxy -d ip-zerotier-intern -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -d 37.120.x.y -p tcp --dport portxy -j DNAT --to-destination ip-zerotier-intern:portxy

Ich hab für Ports und Adressen mal deine Beispiele von oben übernommen. Generell IP-Forwarding einschalten nicht vergessen.

Zitat von aRaphael

Hab das schnell mal abgeschaltet und hoffe nun, dass die bots noch nicht dort waren.

Darf ich fragen,wie? Mit einem Plugin?