Heimnetzwerk
In diesem Beitrag dokumentiere ich noch einmal ausführlich mein Heimnetzwerk (hier der erste Beitrag zu diesem Thema) und stelle ein paar Überlegungen darüber an, ob dieses so geeignet ist, oder ob es noch bessere Varianten gibt. Der interessierte Computerheimwerker sollte daher weiterlesen. Ich würde mich sehr freuen, Kommentare dazu zu lesen.
Grundkomponenten meines Heimnetzwerkes sind:
- Büro-LAN mit an Switch angeschlossenem PC, Server und Drucker. Zusätzliche Geräte anschliessbar nach Bedarf, etwa ein Surf-PC für Gäste oder ein Firmenlaptop. Der Server läuft unter Debian/Adamantix und bietet alle möglichen und nützlichen Linux-Dienste nach Bedarf, insbesondere DHCP, DNS, Firewall, NAT, Samba, SSH.
- WLAN mittels der beiden Basisstationen AVM Fritz! Box und D‑Link-WLAN-Bridge. Sie bilden eine Brücke zum Anschluss des kabelgebundenen MP3-Spielers im Schlafzimmer. Das WLAN wird selbstverständlich WPA2-verschlüsselt betrieben. Zusätzliche Geräte wie etwa der Firmenlaptop können sich jederzeit von jedem Ort der Wohnung her einklinken.
- Die Fritz! Box betreibt zusätzlich einen VoIP Knoten mit zwei angeschlossenen Telefonapparaten. Dies erfordert freien Zugang zum Internet mittels SIP, sowie idealerweise bevorzugtes Routing der VoIP-Daten. Die Fritz! Box selber beherrscht entsprechendes Traffic Shaping.
- Anschluss ans Internet mittels Cablecom-Modem, also durchs TV-Kabelnetz.
Folgende Bedürfnisse möchte ich gerne durch gelungene Verbindung dieser Teile erfüllen:
- Der MP3-Player benötigt Zugriff auf die auf dem Server gespeicherte Musik, sowie auf Radiostationen im Internet. Das erfordert freien Zugang aufs Internet inklusive funktionierendem DNS, sowie Kommunikation mit dem Server mittels SMB bzw. Samba.
- Alle Teile sollen vom Büro-LAN (PC) aus wartbar sein. Die Konfigurationsseiten der Fritz-Box, beispielsweise, sind nur aus dem (aus der Sicht der Fritz-Box) internen LAN (LAN B) oder dem WLAN her erreichbar.
- Der Server soll mittels SSH und/oder FTP aus dem Internet erreichbar sein für mich selber, aber auch für meine Freunde.
- Traffic Shaping über alle relevanten Knoten soll gewährleisten, dass
- VoIP-Telefonie ungestört arbeitet
- Verkehr, der von aussen angestossen wird (von meinen Freunden, etwa SFTP) den eigenen Verkehr, den ich selber auslöse von innen (HTTP, FTP, sonstige Downloads), nicht ausbremst.
- Die Sicherheit der restlichen Infrastruktur soll so hoch wie möglich sein.
- Es wäre vorteilhaft, wenn das WLAN in einer besonderen Sicherheitszone wäre (weil der WLAN-Sicherheit generell nur bedingt zu trauen ist).
- Eine DMZ wäre ebenfalls von Vorteil. Diese kann möglicherweise mit der WLAN-Zone zusammenfallen.
Es stellt sich nun die Frage, wie genau diese Teile miteinander verschaltet werden sollen. Die einfachste Lösung ist im folgenden Bild dargestellt. Und das ist auch die, die ich als erstes in Betrieb genommen habe:
Die Fritz-Box dient als Haupt-Firewall, VoIP und WLAN-Gateway, sowie Router ins Büro-LAN. Der Server dient nur als Server im internen LAN. Seine Firewall-Funktionalität wird nicht benutzt, da seine zweite Ethernet-Schnittstelle ungenutzt bleibt. Grundsätzlich wird an der Fritz-Box jegliche Kontaktaufnahme von aussen gesperrt, ausser SSH und FTP, die mittels Port Forwarding an den Server weitergeleitet werden. Dies ist auch gleichzeitig die einzige Schwachstelle an dem Ganzen: Falls ein Passwort kompromittiert wird und jemand auf den Server kommt, hat er von da aus Zugriff auf den ganzen Rest meines Netzwerks. Diese Problematik gilt allerdings bei genauerer Betrachtung für alle Szenarien, auch für die weiter unten folgenden.
Verglichen mit der obigen Wunschliste weist diese Konfiguration folgende Probleme auf:
- Traffic-Shaping: Nur VoIP-Verkehr wird bevorzugt behandelt. Die Fritz-Box kümmert sich darum (aber nur darum). FTP-Uploads können normales Browsen ausbremsen.
- Es gibt keine DMZ und keine WLAN-Zone.
Ich überlege jetzt, ob die Firewall-Funktionalität des Servers nicht doch auch noch sinnvoll in Betrieb genommen werden kann. Das könnte dann ungefähr so aussehen:
Das Büro-LAN ist hier also nicht mehr direkt mit der Fritz-Box verbunden, sondern der Server dient als Router dazwischen. Dadurch kann er als Firewall sowie als Traffic Shaper den Verkehr nach innen steuern. Somit wird das gesamte WLAN und das angeschlossene Schlafzimmer-LAN zur DMZ. Das ist sicherlich eine Erhöhung der Sicherheit des Büro-LANs. Allerdings erfüllt das die Forderungen nur teilweise:
- Traffic Shaping auf dem Server kann zwar die Bandbreite des von aussen ausgelösten Verkehrs beschränken. Allerdings ist es schwierig, dabei zwischen Verkehr aus dem Internet und Verkehr vom MP3-Player zu unterscheiden. Es besteht somit die Gefahr, dass der MP3-Player eingeschränkt wird. Die Zugriffsgeschwindigkeit des via WLAN angeschlossenen Firmenlaptops auf die Dateien auf dem Server würde dabei möglicherweise ebenfalls auf DSL-Geschwindigkeit reduziert.
- Es müssen zwei getrennte Firewalls unterhalten werden. Dabei darf der Server den SMB bzw. Samba-Verkehr von und zum MP3-Player nicht unterbinden.
Oder als dritte Variante:
Hier dient der Server als Haupt-Firewall, anstelle der Fritz-Box. Jene dient stattdessen nur noch als WLAN-AP sowie als VoIP-Knoten. Dies hat folgende Vor- und Nachteile:
- + Es ist nur noch eine Firewall zu unterhalten und diese Firewall bietet viel feinere Einstellungsmöglichkeiten als das simple Port-Forwarding der Fritz-Box.
- - Dafür ist auch das Risiko grösser, bei fehlerhaften Firewall-Einstellungen Tür und Tor zu öffnen.
- + Das Traffic-Shaping lässt sich mit Hilfe der üblichen Linux-Hilfsmittel viel feiner und vielfältiger einstellen als das VoIP-Traffic-Shaping der Fritz-Box.
- - Die Fritz-Box lässt sich nur noch aus dem WLAN bzw. aus dem Schlafzimmer konfigurieren, weil Zugriff auf die Konfigurationsseiten über das aus Sicht der Fritz-Box nun externe Büro-LAN gesperrt sind.
- - WLAN und Schlafzimmer-LAN bilden jetzt ebenfalls ein eigenes Netzwerksegment. Allerdings ist der Zugriff vom Büro-LAN zum WLAN gesperrt und nicht umgekehrt. Der Sicherheitsaspekt läuft also genau in der anderen Richtung als eigentlich gewünscht.
- - Damit ich telefonieren kann, müssen jetzt noch mehr Geräte eingeschaltet sein und funktionieren, als in den anderen Szenarien. Bisher musste Cablecom-Modem und Fritz-Box laufen, um die Telefonfunktion zu gewährleisten. Jetzt müssen zusätzlich der Server sowie der Switch aktiv sein.
Genau genommen war diese dritte Variante meine allererste. Wegen der obigen Punkte 4 und 6 ging ich allerdings rasch zur aktuellen und nun als Variante 1 bezeichneten Kombination über.
Nach all diesen Ãœberlegungen bin ich noch unschlüssig, ob und wie ich etwas ändern soll und belasse daher erst mal alles so, wie es grade ist, sondern bitte um Kommentare.
Hoi Daniel
ich würde beim aktuellen Layout bleiben. Um gute VoIP Qualität zu gewährleisten, ist der direkteste Anschluss immer der beste (und die FritzBox hat zumindest das Shaping/QoS fürs VoIP am besten im Griff).
Was du dir auch noch bewusst sein musst betreffend Shaping: Wirklich beeinflussen kannst du generell nur ausgehenden Traffic (egal, ob die Verbindung von innen nach aussen oder von extern zu dir hergestellt wurde, relevant ist dann nur die Richtung des Datentransfers). Denn nur ausgehender Traffic kann (ob bei FritzBox oder Linux Firewall) auf der Firewall ausgebremst (zurückgehalten) werden und in genau der gewünschten Geschwindigkeit und Priorisierung in Richtung Kabelmodem losgelassen werden. Eingehender Traffic kommt einfach mal so schnell wie möglich bis zum Shaping Gerät (Fritbox oder Linux) und kann dort höchstens noch durch gezielte Paket Drops künstlich heruntergebremst werden. Wir haben daher auf den eingehenden Traffic keinen wirklichen Einfluss auf die QoS/Priorisierung.
Auf der FritzBox müsste somit vorallem der Uplink Speed angegeben werden können (z.B. bei einem 25000/1500 Abo würdest du vielleicht 1450 als Uplink speed konfigurieren (damit der Ausgehende Firewall Verkehr auf jeden Fall ein klein wenig langsamer ist als der real zur Verfügung stehende Link (um zu verhindern, dass es dann nicht doch beim Modem nochmals zum stauen kommt –> QoS Kontrolle wäre dahin).
wenn das Shaping richtig eingestellt ist (sprich: eben der Uplink speed auf dem Shaping Gerät sicher leicht tiefer ist als physisch verfügbar), solltest du den erwähnten Effekt nicht haben. Sprich voller Upload dürfte den Download nicht gross ausbremsen und umgekehrt.
Du kannst es selber tunen/ermitteln, indem du jeweils während eines vollen Up- bzw. Downloads ein ping ausführst und die Shaping Werte solange nach unten korrigierst, bis die Antwortzeiten der Pings auch trotz laufendem Up- oder Download noch OK sind.
Um die Sicherheit zu erhöhen, kannst du folgendes beachten:
— Überlege dir, ob du wirklich SSH nach aussen offen haben willst. SSH/Shell Zugriff ermöglich wie korrekt bemerkt auch ohne Probleme den Zugriff aufs restliche Netz und erweiterten Zugriff auf den Server. Bietest du stattdessen nur FTP (ohne Shell: d.h. die User erhalten als Shell /bin/false (siehe /etc/passwd)) an, sind zwar die übertragenen Daten unverschlüsselt (je nach Daten dürfte dies nur untergeordnet von Bedeutung sein), dafür kann der Server nicht als Hop in dein Netz missbraucht werden (empfehle vsftpd mit chroot=~ (sprich: jeder User kann sein persönliches Home-Dir nicht verlassen)).
Gruss
Martin
Vielen Dank, Martin
Die Sache mit dem Traffic Shaping ist doch die: Ankommende TCP-Datenpakete müssen vom TCP/IP-Stack quittiert werden. Das Quittungspaket geht an den Absender zurück und enthält die Information, ob das gesendete Paket fehlerfrei angekommen ist oder nicht. Damit ein von mir veranlasster Download (z.b. beim Browsen) flüssig hereinkommt, müssen diese Quittungspakete rasch und ungehindert über den Upstream-Kanal fliessen können. Wenn nun gleichzeitig ein FTP-Upload die gesamte Upstream-Übertragungskapazität belegt, dann gehen die Quittungspakete nicht sofort los, sondern müssen jeweils ein bisschen warten, bis im FTP-Datenstrom die nächste Lücke kommt. Die für dieses Warten benötigte Zeit hängt davon ab, wie gross die FTP-Datenpakete sind, und wie gross der Sendepuffer ist, der vom TCP/IP-Stack benutzt wird. Die Quittungspakete selber sind klein (nur wenige dutzend Bytes), die FTP-Datenpakete so gross wie möglich (normalerweise im Bereich 1500 Bytes). Die Grösse des Sendepuffers ist mir grade nicht bekannt. Aber jedenfalls führt dies dazu, dass bei gleichzeitig laufendem FTP-Upload ein HTTP-Download nur stockend hereinkommt, obwohl die Downstream-Datenrate bei weitem nicht voll ausgenutzt wird.
Darum ist Traffic Shaping eminent wichtig, nicht nur für VoIP, sondern auch dann, wenn damit zu rechnen ist, dass die Leitung nicht nur von einem selbst benutzt wird. Deshalb werde ich, sobald ich dazu komme, mir die Zeit dafür zu nehmen, mein Heimnetzwerk in Richtung Variante 2 weiterentwickeln.
Gruss
— Daniel