Processing Power VPN 100Mbps / NAS 1Gbps

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

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.

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.

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.

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.

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...

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.

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...

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.

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.