Router, Backup/Fileserver , HTPC in one?

LIghthammer

Enthusiast
Thread Starter
Mitglied seit
08.12.2005
Beiträge
788
Ort
Stuttgart
Hallo,

ich plane einen Backup/Fileserver + HTPC, beides in einem Gerät sollte ja ohne Probleme möglich sein, aber ich Frage mich, ob man auch noch den Router integrieren könnte?

Gibt es da einen sinnvollen Weg? Mir ist, klar, dass ein virtualisiertes Fli4l nicht optimal ist.
Aber vielleicht mit einem ESXi? Oder hat das auch keine Vorteile gegenüber der Variante, dass ich alle die Virtualisierungen auf ein Ubuntu aufsetz?

Hardware wird wohl ein Phenom II Quad + 4gb ram, HDD hab ich mir noch keine Gedanken gemacht.

Wär über Hilfe sehr dankbar ;)

Lighthammer
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
HTPC auf einem ESXi wird nicht gut gehen schätze ich mal.
kannst das ja in einer VM starten, die von normalen System gehostet wird, aber ich würde andere Hardware verwenden oder den Rechner halt einfach routen lassen vielleicht noch mit einer firewall.

Aber hardware-router sind einfach wunderbar unkompliziert und haben relativ geringe Ausfallraten.
 
Okay, sprich lieber 2 Systeme. Hab ich mir fast schon gedacht. Dann kommt der Quad in den HTPC, trotzdem danke!
 
Mir ist, klar, dass ein virtualisiertes Fli4l nicht optimal ist.

Warum?
Hier im Forum gabs schon mal eine Diskussion darüber.
Hypervisor aushebeln und so ein Gelaber. Ist davon bisher auch nur ein Fall bekannt? Warum bieten große Hersteller ihre Firewalls als VM an? Welcher Angreifer scannt den noch 24h Disconnect dial-up Leitungen ab?
Es gibt 4.294.967.296 IP(v4) Adressen. Falls es dann doch mal ein Superhirn schafft VMware auszuhebeln, sucht er sich natürlich ausgerechnet deine IP raus und legt los. Nur dumm dass er dazu leider max. 24h Zeit hat.

Bevor ich mich weiter aufreg :d Tu mir und dir einen Gefallen und setz das ding in der VMware auf. Damit tust du übrigens auch was für die Umwelt! :fresse: :d
 
Über mich brauchst du dich nicht aufregen, ich wollts wegen genau den Gründen machen, die du genannt hast :d
Also nen HTPC/Backup unter Linux aufbauen und darauf Fli4l/oder was auch immer virtualisieren?
 
Zuletzt bearbeitet:
Hehe, ne ich reg mich nur über Leute auf, die virtualisierte Firewalls für unsicher halten, speziell im Home Bereich.

Ja, HTPC/Backup auf OS deiner Wahl aufsetzen und Router virtualisieren und halt möglichst in den Autostart mit reinnehmen. Am besten noch eine Kopie der VM irgendwo wegspeichern, damit du auch, falls dein HTPC mal die grätsche macht, ruck zuck wieder online bist.
Wenn du noch mehr auf Nummer sicher gehen willst, baust du in den HTPC noch eine weitere NIC ein für dein WAN. Ist aber auch so n Glaubensding :d
 
Hab eh nochn 15€ Router hier rumfahren, der springt dann zur Not ein.

Muss eh ne Wlan Karte einbauen, wenns ein ATX Mainboard wird, sind 2 Nics drauf.
Mal schaun, danke dir. Hoffentlich klappt die konfiguration ;)
 
Hehe, ne ich reg mich nur über Leute auf, die virtualisierte Firewalls für unsicher halten, speziell im Home Bereich.

Daran gibt es nix zu rütteln, ob du das nun glauben magst oder nicht...
Ob das nun im Homebereich vertretbar ist oder nicht, muss jeder selbst entscheiden...

Im übrigen, glaube nicht das es aufgrund dynamischer IPs im Homebereich weniger Angriffe gibt, dem ist nicht wirklich so ;)
Auf meinen SFTP Zuhause gibt es täglich tausende Versuche sich auf die Kiste einzuklinken. Bis jetzt ist es aber niemanden gelungen :fresse:
 
Ich hab auf meinen FTP Server auch dauernd irgendwelche Zugriffsversuche, meistens mit IPs aus China, Japan etc.
Wird Zeit mal wieder den Port zu wechseln, ich frag mich wieso die sich immer die Mühe machen 64k Ports abzuscannen, wenn es genug ungesicherte FTPs auf Port 21 gibt?!
 
Neja, ich denke das geht alles vollautomatisch... Da gibts genügend gute Tools um einen IP Range zu scannen und gleich noch die offenen Ports angezeigt zu bekommen.
Portwechsel nutzt da irgendwie ziemlich wenig.

Aber mit dem richtigen Sicherheitskonzept ist da auch kein Reinkommen... Ich nutz bei mir Zertifikate. Und das hat bis jetzt niemand geknackt ;)
 
Ich nutze auch SFTP, aber per Passwort, um von jedem PC Zugreifen zu können. Das PW ist aber abartig lang, um die 30 Stellen mit Sonderzeichen und alle möglichen.
In Kombination mit der "nach 3 gescheiterten Zugriffsversuchen IP blocken"-Regel sollte es recht wirksam sein.

Alle paar Monate ändere ich noch ein paar Buchstaben im Passwort und hoffe einfach mal das es niemand schafft in 3 Versuchen die richtige aus 30^98 möglichen Kombinationen zu erraten.
 
Zuletzt bearbeitet:
Du meinst 98^30 ;)
Aber sei es drum... Wobei natürlich so ein abartig langes Password für den Gebrauch auch hinderlich ist. Da nutz ich lieber Zertifikate :fresse:
 
Um mal wieder BTT zu kommen.

Für diesen Anwendungsbereich den der TE abdecken möchte, wären ja zwei wenn nicht gar drei Netzwerkkarten zu empfehlen oder?

1. WAN
2. LAN für Router
3. LAN für HTPC
 
Na wohl im Mindestens zwei... Theoretisch dürfte sogar eine einzige reichen... Aber ich halte nach wie vor die Methode Router virtualisiert für Quark.
Die LAN Seite Router und HTPC auf zwei NICs zu splitten muss denke ich nicht unbedingt sein. Es sei denn man hat eine Internetleitung in Größenordnung 100MBit udn aufwärts, lastet die voll aus und gleichsam bei HTPC fährt man NIC Volllast.
 
Problematisch bei virtualisierten Routern ist in der Praxis eher, falls das Ding langsamer startet als andere Systeme und dann kein DHCP da ist --> kann schnell mal Chaos mit den IP Adressen geben oder ein paar "Gedenkminuten" bis dann die Clients beschließen ihre IP neu zu holen.
 
Ein Router ohne DHCP ist doch mist. Wenn jemand mal eben mit seinen Laptop vorbei kommt muss er erst eine Feste IP vergeben.
 
Problematisch bei virtualisierten Routern ist in der Praxis eher, falls das Ding langsamer startet als andere Systeme und dann kein DHCP da ist --> kann schnell mal Chaos mit den IP Adressen geben oder ein paar "Gedenkminuten" bis dann die Clients beschließen ihre IP neu zu holen.

Wo ist das Problem?
Die Thematik ist immer und allgegenwertig. Der jenige der DHCP Server spielt, sollte möglichst zeitig starten. Ob das nun virtualisiert abläuft oder nicht.
 
Wenn man das z.B. mit irgendwas in Richtung VirtualBox macht, ist das Hostsystem meist schon recht "weit" hochgefahren (da ja dann auch LAN-Adapter weitergereicht werden müssen etc.).

Bei Virtualisierung ala HyperV/ESXi ist das vielleicht nicht so ausgeprägt, da dann beide (Gast-)Systeme eher zugleich starten (und die meisten kleinen Routerdistris recht flott sind).
 
Ja aber wo ist da jetzt das Problem?

Ob du nun virtualisierst oder nicht spielt doch keine Rolle. Startest du den Router (in welcher Form auch immer der vorhanden ist) weit nach dem Client, so kann es zu DHCP Problemen kommen.
Verstehe hier die Aufregung nicht...
 
Ich wollte mich auhc nicht wirklich aufregen, sorry falls das so rübergekommen ist.

Das war ja auch nur ein kleiner Punkt, der mich dann aber nach einigen solchen Ärgernissen wieder davon abgebracht hat eine pfsense-Instanz laufen zu lassen. Stattdessen habe ich jetzt einfach DD-WRT auf einen Billigrouter geflasht und gut ist.

Das Problem ist:
Wenn man nicht virtualisiert, kann man ja wenigstens noch dem/den DHCP client(s) per Nichtbetätogung des Powertasters mitteilen, noch ein bisschen mit dem Hochfahren zu warten. Wenn aber zwei Herzen in des Servers Brust schlagen, können es auch solche nervigen Kleinigkeiten sein, die das Ökosystem dann aus dem Takt bringen (besonders wenn man von SSD arbeitet und Betriebssysteme recht schnell im Laden sind - dann aber irgendwelche obskuren timeouts auf LAN-Anschlüssen abwarten).
 
verstehe immernoch nicht was du willst...
Die VMs starten nicht alleine... Das ist mal Fakt. Du kannst selbst definieren, wie und wann diese starten. Und in welchem Abstand. Stell halt die Zeiten so ein, wie es nötig ist und gut.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh