Schlagwort-Archive: ipfire

IPCop is back

Es war nicht mehr auszuhalten mit IPFire. Das Ding frisst sich bei mir innerhalb weniger Tage fest und dann ist man nur noch am Proxy-Cache leeren, URL-Filter neu starten und rebooten, in der Hoffnung, dass danach das Netz wieder performant läuft. Außerdem bekomme ich die Logik der Firewall nicht in meinen Kopf. Egal welches Netzsegment ich für welche Uhrzeit oder welchen Dienst sperre … entweder läuft gar nix mehr im ganzen Haus oder alles flutscht durch.

Jetzt hab ich mir wieder einen IPCop installiert und muss sagen: Die Installation von IPCop 2.x hat sich gegenüber 1.x nicht geändert – man fühlt sich sofort zu Hause. URL Filter und BOT sind mit an Bord und tun auch, was man einstellt. Und das Netz im Haus? Fühlt sich nicht nur schneller an, ist auch messbar flotter. Außerdem sind die Sperrmeldungen von IPCop einfach schön 😉

LM 6.1

Auf linuxmuster.net liegt seit ein paar Tagen die Beta der nächsten Version als VM für alle möglichen VM Hostsysteme. Ich hab das hier mal unter VirtualBox auf meinem Laptop für eine Konfiguration ausprobiert, die nur green und red als Interfaces nutzt.

Die heruntergeladenen Archive lokal mit tar xvfJ archiv.tar.xz entpacken und dann in VBox über das Menü /Datei /Appliance importieren in VBox … naja, eben: importieren. Dann erfolgen einige Anpassungen.

Da ich auf meinem, doch etwas älteren, Laptop als VMHost nur 4GB RAM habe, gab ich der Firewall die voreingestellten 256MB, dem Server 1GB und dem Client unter Lubuntu 512MB. Da musste mein Laptop zwar schwer schnaufen – und auch der virtualisierte Server – aber es läuft, wenn man Lubuntu 12.04 von der Alternate CD installiert .

Firewall

Die MAC Adresse der Netzwerkkarte, die später die rote Schnittstelle werden soll, habe ich hinten mit einer 0 versehen und lasse diese NATen.

Die Schnittstelle, die später mal grün sein soll, versah ich am Ende der MAC mit einer 1 und stellte diese auf „Internes Netzwerk“.

Blau will ich hier auf dem Laptop zum Testen nicht nutzen, also hab ich das „Kabel“ schlicht entfernt und die Schnittstelle nicht angeschlossen.

Beim Hochfahren des IPCop wählte ich nicht den voreingestellten PAE Kernel. Die Firewall kommt mit 256 MB RAM. Da erschien mir das nicht sinnvoll zu sein.

IPFire motzt dann beim Hochfahren, dass es seine Schnittstellen nicht finden kann, was an dieser Stelle nicht weiter stört.

Hat man sich als root und dem Passwort muster einmal eingeloggt, kann man sich durch den Setup-Prozess von IPFire hangeln, den ein setup auslöst.

Die bestehende Zuordnung der Netzwerkkarten muss man zuerst entfernen und dann neu vornehmen. Die vorher vergebenen MAC Adressen helfen bei der Orientierung.

Ein Ping ins Netz zeigt nach Beendigung des Setups, ob alles geklappt hat.

Server

Das Netzwerkinterface des Servers konfiguriert man sich in VBox wie die grüne Schnittstelle des IPFire als „Internes Netzwerk“.

Im Detail ist der Setup-Prozess im Handbuch für Version 6.0 beschrieben.

Nach dem Hochfahren des Servers einloggen (linuxadmin, muster), etwas Zeit verstreichen lassen, bis der Server Kontakt über die VBox interne Schnittstelle zum IPFire erhalten hat und dann mit ping testen, ob die Namensauflösung klappt. Dann mit sudo apt-get update ; sudo apt-get dist-upgrade evtl. vorhandene Updates einspielen und nun – nach einem Wechsel in eine Root-Shell mit sudo su – – das eigentliche Setup beginnen durch Eingabe von

linuxmuster-setup –first

Das kann dauern. LM6.1 zieht nun alle möglichen Pakete aus dem Netz, bis der eigentliche Installationsdialog beginnt (zu diesem siehe den Link zum Handbuch weiter oben).

Subnetting hab ich nicht aktiviert. Ich will vor allem mit Linbo spielen, weil wir schulintern gerade einige Höllenprobleme mit einer zickigen Hardwareklasse (Lenovo T410) haben. Alle anderen Einstellungen habe ich deswegen so übernommen, wie vom Installer als default vorgesehen.

Clients

Die Netzwerkkarten von virtuellen Clients werden wie die grüne Schnittstelle am IPFire bzw. wie die Serverschnittstelle als Internes Netzwerk konfiguriert.

Will man echte Clients testen, dann muss man sich mehr Arbeit machen. In diesem Fall legt man sich auf dem Host-System eine Netzwerkbrücke auf einer unkonfigurierten physischen Schnittstelle ethX an und verpasst dieser eine passende interne IP (siehe Netzwerksetup Homeserver NXT). Statt mit dem Internen Netzwerk von VBox verbindet man dann IPFire und Server mit dieser Bridge.

Ich weiß nicht, ob ich das extra schreiben muss, aber das klappt nur mit Netzwerkschnittstellen am Host in die man ein Kabel stecken kann. WLAN Interfaces sind außen vor. Wer WLAN virtualisiert und keine AccessPoints hierzu nutzen will, kann sich mit USB WLAN Sticks helfen, die man als USB Gerät an die VM durchreicht.

An diese physikalische Schnittstelle des Hosts hängt man einen Switch und an den Switch wiederum den physikalischen Client. Voila.

Sofern die MAC Adressen gleich bleiben, kann man dann zwischen dem physikalischen, ge-bridge-ten Netz und dem VBox internen Netz an den ausgeschalteten VMs hin- und her-schalten wie man will.

Homeserver NXT

Bin grad kaum zum Bloggen gekommen, weil mein Kopf voll war mit Heimnetzkram. Da ist aber nun der Knoten geplatzt und in den nächsten Posts schildere ich dann Schritt für Schritt, wie ich dieses aufgesetzt habe.

Angefangen hatte alles damit, dass meine Smoothwall auf ihrem P III langsam zu lahm wurde. Je älter die Kinder desto mehr Geräte im Haus und desto heftiger die Belastung auch für die Firewall. Außerdem wollte ich ausmisten. In den letzten Jahren hatte sich eine solch große Zahl an Computern bei mir im Arbeitszimmer versammelt, dass auf dem Fußboden schon kein Platz mehr war.

Jedes Stück Hardware hatte einen Platz im Hinterkopf, irgendein Projekt, das ich unbedingt mal machen wollte … aber die Zeit war nie da. Am Ende standen da 8 ungenutzte Rechner der Pentium IV Klasse rum, dazu Tastaturen, Mäuse, Bildschirme, weitere Netzwerk- und Grafikkarten … Nerdbastelkram eben. Nichts, was man heute noch wirklich haben will und auch nichts, was ich als Firewall nutzen wollte, weil selbst der Sparsamste von diesen Kisten (ein FSC mit Siemens-Mainboard) noch 90 Watt die Stunde beim Nixtun verbriet.

Energiesparend und vor allem auch möglichst klein sollte die neue Lösung sein.

Zuerst dachte ich an einen Nachbau des in der c’t beschriebenen 11-Watt-Servers, konnte aber das Netzteil nicht auftreiben. Auf der Suche nach einem Standort für diesen Rechner in meinem Arbeitszimmer fiel mir auf, dass diese Kiste schon wieder in Midi-Tower-Größe anrücken würde. Möglichst klein wäre das auch nicht.

Ein Raspberry Pi dann also? Dem traute ich nicht zu, als Firewall ausreichend zügig zu arbeiten. Außerdem trieb mich die Idee um, doch noch andere Dienste zu betreiben. Die Projekteideen – einst für die P4 Hardware vorgesehen – ploppten immer wieder aus dem Hinterkopf wieder ins Bewusstsein und verhinderte eine schnelle Entscheidung zwischen Mini und Midi …

Ein permanent laufenden Fileserver als Backup-Rechner und Tauschordner, ein eigener Nameserver als Ergänzung zur Firewall für eine noch bessere Kontrolle der Webzugriffe und noch weniger Schnüffelei von Außen … und für uns Jungs und Freunde noch ein dezidierter Gameserver für Minecraft, OpenArena und World of Padman.

Am Ende und nach viel Hin und Her wurde es nun ein Zotac ID 88 mit Core i3-3220T CPU mit 16 GB Ram und einer WD NAS Festplatte mit 1 TB. Der schluckt Idle 18 Watt und unter Last bisher nicht mehr als 23 Watt, was ein wenig unter dem Verbrauch der alten Firewall liegt. Dem Basteltrieb ist damit eine physikalische Grenze gesetzt: Erweiterungen sind unmöglich, das Kästchen ist voll.

Installiert sind inzwischen IPFire als Firewall, ein Fileserver unter Samba und ein Nameserver mit Bind. Der Gameserver muss bis zu den Ferien warten.

Unter dem Tag homeserver nxt geht es dann bald weiter mit Hinweisen zur Einrichtung und meinen Erfahrungen …

/localhost

127.0.0.1