mikrocontroller.net

Forum: PC Hard- und Software Processing Power VPN 100Mbps / NAS 1Gbps


Autor: Kai (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Ich will mir einen VPN-Server basteln. Software soll Soft-Ether werden. 
Am Anschluss liegt zur Zeit VDSL 50/10 an, will später aber auf 100/40 
oder vielleicht zukunftssicher Kabel 500/50 updaten.
OS: Linux (arch, Gentoo)
Für den VPN Server zählt vermutlich nur der Upload ?

Das interne Netz arbeitet mit 1Gbps. Der VPN-Server muss gleichzeitig 
Firewall / NAT-Router sein.
Hier muss ich auch nur den Upload betrachten ?

Der VPN Server soll hinter dem Modem als DMZ geschaltet werden (Modem 
ist EasyBox). Die Easy-Box hat zwar einen OpenVPN drauf, aber den kann 
man nicht konfigurieren und es gibt wohl MTU Probleme. Wenn ich den 
Server hinter dem Modem auf meinem Rechner installiere, läüft die 
Verbindung. Der Rechner ist aber normalerweise ausgeschaltet, wenn ich 
nicht da bin.

Was schätzt ihr, brauche ich hier für eine Leistung für maximale 
Performance ?

Wenn der Server jetzt noch als NAS dienen soll, welche Performace 
brauche ich dann, um die 1Gbps ausnützen zu können ?
Bei meinem alten NAS bekomme ich nur ca. 15-20MB/s per smb durch die 
Leitung.

Reicht der kleinste Ryzen 3 oder i3 dafür aus ?

Alles natürlich  stromsparend und leise.

Gruß Kai

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai schrieb:
> Für den VPN Server zählt vermutlich nur der Upload ?

Wieso sollte das so sein? Auch der über das VPN empfangene Traffic 
muss entschlüsselt werden, also zählt auch der Downstream. Und der kann, 
je nach Anzahl verbundener Clients, die etwas an den VPN-Server senden, 
durchaus auch höher sein als der Upstream.

Autor: Kai (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Ich habe Annahmen getroffen, die ich nicht erwähnt habe:

Hauptsächlich will ich aus meinem Netz in der Ferne Sachen downloaden 
und VNC benutzen. Das ganze dann über WLAN (Laptop) in einem "fremden" 
Netz.

Und normalerweise ist dieses "fremde" Netz auch asymmetrisch. Meist 16/1 
oder 50/10.

Also nicht an einer T1 Standleitung mit 500MB Upload.

Gruß Kai

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha. Na, dann wird nicht mehr nötig sein, als der Upstream Deines 
Heimanschlusses.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai schrieb:
> Wenn der Server jetzt noch als NAS dienen soll, welche Performace
> brauche ich dann, um die 1Gbps ausnützen zu können ?
> Bei meinem alten NAS bekomme ich nur ca. 15-20MB/s per smb durch die
> Leitung.
>
> Reicht der kleinste Ryzen 3 oder i3 dafür aus ?

Mit Kanonen auf Spatzen...

Ich würde erst mal schauen ob die VPN Software überhaupts die 
Hardwarebeschleunigung der CPU unterstützt. Wenn ja reicht ggf. sogar 
ein SoC von Intel (kp was da AMD inzwischen im Programm hat) aus. Wenn 
nicht kann man natürlich einen Pentium oder gleich i3/Ryzen 3 in 
Erwägung ziehen, das wäre aber nur für VPN etwas überdimensioniert. Es 
stellt sich natürlich auch noch die Frage ob die Kiste auch gleich noch 
als z.B. Fileserver/Buildserver agieren soll, da kann es dann mit einem 
SoC eng werden.

OpenVPN und tinc sind auch interessante VPN Lösungen. Wobei für 
VNC/Datenübetragungen auch (auto)ssh bzw. rsync ausreichend sind. Ggf. 
wäre auch ein Webserver mit webdavs eine Alternative, dann bist du auf 
keinen fixen Client angewiesen.

Samba ist immer relativ lahm, ich rate eher zu NFS (hierbei bei NFS UDP 
aktivieren), nachdem du auf eine VPN setzt wäre die Verschlüsselung eh 
vollkommen unnötig (wobei diese meistens eh noch aktiviert werden 
müsste). Achte aber auf jeden Fall darauf, dass du dich mittels UDP 
verbindest, eine TCP Verbindung über einen TCP Tunnel ist in der Regel 
sehr träge, solang du durch keine Firewall tunneln musst sollte man 
immer auf UDP setzen.


Willst du auf deinem Server wirklich Gentoo oder Arch einsetzen? 
Letzteres ist zwar eine tolle Distri, auf einem Server ist man mit z.B. 
Debian jedoch besser beraten. PfSense wäre auch eine Lösung bei der die 
Einrichtung über eine Weboberfläche erfolgen könnte, zudem haben die 
irgendwo eine Tabelle mit Hardwareanforderungen.

Autor: Reinhard S. (rezz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai schrieb:
> Also nicht an einer T1 Standleitung mit 500MB Upload.

T1 wären grad mal 1,5 MBit/s. Und wäre mir neu, das es da eine 
Volumenbegrenzung/Drosselung gibt ;)

: Bearbeitet durch User
Autor: Vka (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai schrieb:
> zukunftssicher Kabel 500/50

Seit wann ist so ein shared medium "zukunftssicher"? Bandbreite auf dem 
Papier ist nicht alles, besonders weil die Kabelanbieter gerne mal nicht 
das liefern was sich versprechen, oder dich durch ein grottiges NAT 
quetschen.
Tipp am Rande, schmeiß die Easybox raus bzw. schalte sie "doof" auf 
Modem Betriebsart. Das Ding wird am Ende der Flaschenhals sein. Routing 
und Firewall mache ich auch selbst auf meinem Server, der ist dann auch 
direkt VPN Endpoint, bekommt die öffentliche IP usw.

Zum Thema Leistung, ich habe hier einen HP Microserver mit Xeon CPU und 
16GB RAM laufen. Da drauf laufen ein paar virtuelle Maschinen für 
diverse Dienste (Router, NAS, Cloud, ...).
Damit kann ich das hausinterne Gigabit locker auslasten. Stromverbrauch 
hält sich in Grenzen (Xeon L), die Kiste läuft so mit +/- 30W vor sich 
hin.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vka schrieb:
> Kai schrieb:
>> zukunftssicher Kabel 500/50
>
> Seit wann ist so ein shared medium "zukunftssicher"? Bandbreite auf dem
> Papier ist nicht alles, besonders weil die Kabelanbieter gerne mal nicht
> das liefern was sich versprechen, oder dich durch ein grottiges NAT
> quetschen.

Das Problem ist tatäschlich NAT.

Anscheinend muss man sich da bei einem privaten Anschluss inzwischen 
echt eine gute Begründung einfallen lassen, die rücken kaum noch eigene 
IPv4 Adressen raus.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz vergessen:

http://lowendspirit.com/locations.html

Sowas ist als Reversetunnel bei so ekelhaften NAT Geschichten eine 
schöne Lösung. 3-4€ im Jahr sind nichts, man bekommt dafür leider auch 
nur eine geteilte IPv4 Adresse, aber die 20+2 Ports langen für die 
meisten Anwendungen.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieter schrieb:

> Das Problem ist tatäschlich NAT.

Einfach nur NAT ist kein Problem, jedenfalls kein großes, selbst wenn es 
an beiden Enden der Verbindung passiert.

Zum Problem wird es erst, wenn man nicht wenigstens an einem Ende der 
Verbindung die Kontrolle über das Teil hat, was das NAT betreibt...

Autor: Reinhard S. (rezz)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Vka schrieb:
> Kai schrieb:
>> zukunftssicher Kabel 500/50
>
> Seit wann ist so ein shared medium "zukunftssicher"? Bandbreite auf dem
> Papier ist nicht alles, besonders weil die Kabelanbieter gerne mal nicht
> das liefern was sich versprechen, oder dich durch ein grottiges NAT
> quetschen.

Früher oder später ist alles Shared. Man kann ja auf das "grottige NAT" 
(was jeder DSL-Nutzer betreibt) verzichten, indem man auf IPv6 
ausweicht. Aber da sind die Softwerker nicht fähig zu...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard S. schrieb:
> Aber da sind die Softwerker nicht fähig zu...

Denkst du dabei an ganz bestimmte Softwerker, oder sind da so ganz 
allgemein alle gemeint? ;-)

AVM könnte man aus dem Quark kommen und ihre Boxen hinsichtlich VPN 
IPv6-fähig machen.

Autor: Vka (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard S. schrieb:
> Früher oder später ist alles Shared.

Klar. Es macht aber einen Unterschied ob du schon mit dem ganzen 
Häuserblock auf einem Coax hängst oder dich erst im Provider Backbone in 
die Warteschlange reihen musst.

Recherchiere das mal, es ist abenteuerlich was die Kabelnetz Anbieter da 
teilweise an Segmentgröße und over provisioning fahren. Dazu noch ein 
überlastetes CGNAT und du liest abends besser ein Buch, offline.
Mit VDSL hast du damit deutlich weniger Probleme. Richtig flott läuft es 
dann bei kleinen Anbietern z.B. den Stadtwerken, die nicht nur das 
künstlich beschränkte Telekom Peering nutzen sondern selbst routen.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Dieter schrieb:
>
>> Das Problem ist tatäschlich NAT.
>
> Einfach nur NAT ist kein Problem, jedenfalls kein großes, selbst wenn es
> an beiden Enden der Verbindung passiert.
>
> Zum Problem wird es erst, wenn man nicht wenigstens an einem Ende der
> Verbindung die Kontrolle über das Teil hat, was das NAT betreibt...

Das NAT bei Kabelanschlüssen erfolgt leider wie bei Mobilfunksystemen 
anbieterseitig, sprich eingehende IPv4 Verbindungen sind ausgeschlossen. 
Deren Plasterouter filtern aber eh alles weg was bei drei nicht auf dem 
Baum ist.

Der Standardrouter der Telekom filtert bei IPv6 alles eingehende "aus 
Sicherheitsgründen" weg, man kann nicht mal einen exposed Host 
freigeben, würde wohl den üblichen Nutzer verunsichern, ich mein, 
schönes IPv6 hast du da, wäre ja eine Schande wenn ich da alle Pakete 
droppen würde...

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dieter schrieb:

>> Zum Problem wird es erst, wenn man nicht wenigstens an einem Ende der
>> Verbindung die Kontrolle über das Teil hat, was das NAT betreibt...
>
> Das NAT bei Kabelanschlüssen erfolgt leider wie bei Mobilfunksystemen
> anbieterseitig

Sag' ich doch. Damit hast du schon auf auf einer Seite der Verbindung 
keine Kontrolle über den NAT-Router. Und bei "roadwarrior"-VPNs hast du 
üblicherweise eben auch keine Kontrolle über den NAT-Router auf der 
anderen Seite. Genau das ist halt das Szenario, was zum "geht nicht" 
führt.

In "net2net"-VPN-Szenarios kann das aber anders aussehen, da wäre dann 
so ein kastrierter Kabelanschluss auf einer Seite allein noch kein 
K.O.-Kriterium, wenn man eben wenigstens die Kontrolle über das NAT der 
anderen Seite hat.

Also nochmal ganz deutlich: NAT an sich ist NICHT das Problem. Das 
Problem ist die fehlende Kontrolle über den/die NAT-Router.

Richtig frech sind übrigens die Mobilfunkprovider. Die sperren teilweise 
absichtlich die (ausgehende IPSEC)-VPN-Funktionalität. Auch das hat nix 
mit NAT zu tun, dafür gibt es nur einen Grund: Profitmaximierung. Denn 
mit dem "richtigen" (natürlich deutlich teuereren) Tarif geht es dann 
doch und zwar über die gleiche Infrastruktur. Das ist also reine 
ungeschminkte Abzocke.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Das ist also reine ungeschminkte Abzocke.

Auch als "Geschäftsmodell" bekannt. ;-)

Immerhin gibts zunehmend IPv6 im Mobilfunknetz. Dann ist ein IPv6 Tunnel 
für die VPN denkbar, denn zumindest in den Kabelnetzen sind die IPv6 
Adressblöcke zwar nicht nominell zugeordnet, aber faktisch stabil.

: Bearbeitet durch User
Autor: Reinhard S. (rezz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vka schrieb:
> Recherchiere das mal, es ist abenteuerlich was die Kabelnetz Anbieter da
> teilweise an Segmentgröße und over provisioning fahren.

Und es ist manchmal echt erstaunlich, das es nicht immer zu einer 
Überlastung kommt, bei der Anzahl an Kunden im Segment.

> Richtig flott läuft es
> dann bei kleinen Anbietern z.B. den Stadtwerken, die nicht nur das
> künstlich beschränkte Telekom Peering nutzen sondern selbst routen.

Das mit den "kleinen Anbietern" kann man aber auch nicht so pauschal 
sagen.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Auch als "Geschäftsmodell" bekannt. ;-)

Ja, so kann man das wohl auch nennen. ;o)

> Immerhin gibts zunehmend IPv6 im Mobilfunknetz. Dann ist ein IPv6 Tunnel
> für die VPN denkbar, denn zumindest in den Kabelnetzen sind die IPv6
> Adressblöcke zwar nicht nominell zugeordnet, aber faktisch stabil.

Sobald das in nennenswertem Ausmaß genutzt wird, werden wohl auch neue 
"Geschäftsmodelle" auftauchen, die letztlich darauf basieren, diese 
Möglichkeit zu erschweren oder gar ganz zu unterbinden.

Darauf würde ich jede Wette eingehen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.