Schlagwort-Archive: ipcop

IPCop is back

ipcopisback

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 😉

Netzwerkkartenwechsel

Bei der Virtualisierung bestehender Maschinen erhalten diese in ihrer dann virtuellen Umgebung einen anderen Netzwerkkarten Typ und damit auch eine neue Schnittstellen-Bezeichnung. Dies sorgt dann für Probleme, wenn z.B. eth0 auf eine fixe IP Adresse gelegt war, sich nun die virtuelle Maschine mit der „neuen“ Karte aber so fühlt, als hätte diese nur eth1. Diese Schnittstelle ist dann nämlich nicht konfiguriert und die VM kommt nicht ins Netz.

Abhilfe schafft die Bearbeitung der Datei

/etc/udev/rules.d/70-persistent-net.rules

In diese trägt Ubuntu ein, welcher Karte es welche Schnittstellen-Bezeichnung zugewiesen hat und hier kann man dann die nicht benötigten Zuweisungen (an die nicht mehr vorhandenen Karten) löschen und die bestehenden anpassen (also eth1 durch eth0 ersetzen).

Reboot und tut.

Auch praktisch ist dieses Vorgehen auf einem IPCop, der zwei identische NICs verbaut hat. Da darf man im Setup nämlich raten, welche NIC nun welches Netz erhalten hat. Kein Drama, wenn es den IPCop in real gibt. Da steckt man schlicht die Kabel um. Wenn man jedoch einen UnCop aufgesetzt hat und ein Interface an einer Bridge hängt, dann ist das schon fummeliger, weil die Re-konfiguration im Virtualisierer erfolgen muss.

Einfacher geht es durch Anpassung dieser Datei auf dem IPCop selbst:

/var/ipcop/ethernet/settings

Nach einem Reboot klappt es dann wieder mit der Verbindung.

 

SmoothWall

… unser IPCop ist nach mehreren Jahren Arbeit heute Morgen verschieden. Egal was ich mach – booten tut die Kiste nicht mehr. Die Probleme mit dem DHCP Server des Cops waren wohl nur der erste Gruß aus dem Grab.

Ich bin dann, weil der IPCop 2.0 mit 2.6er Kernel immer noch Beta ist, auf Smoothwall Express umgestiegen. Wie vom IPCop gewohnt – auch hier lässt sich ein URL Filter mit Zugriff auf die Shallalist und der Advancedproxy nachinstallieren und eine Funktion wie Block Outgoing Traffic ist schon in der Basisinstallation mit an Bord.

Bisher lässt sich die „neue“ Firewall ganz gut an: 512 MB SDRam auf einem P 3 mit 450 Mhz reichen locker. Womit ich im Moment allerdings noch zu Kämpfen habe, ist die Oberfläche. So altbacken der IPCop auch aussah – ich fand mich schneller auf ihm zurecht.

Dafür hat Smoothwall mehr bells and whistles – z.B. sich in Echtzeit verändernde Balkengrafiken zum Netzwerkverkehr. Sieht cool aus, braucht aber eigentlich keiner.

Smoothwall überzeugt mich im Moment eher dadurch, dass eine ganze Reihe von Tools mit an Bord sind, die ich auf dem IPCop gelegentlich schon vermisst habe: locate ist ebenso anwesend wie eine echte crontab oder top. Außerdem liegen die Konfigurationsdateien meist da, wo man diese nach Linux Filesystem Hierarchy auch erwartet bzw. wo diese auf vielen anderen gebräuchlichen Distris auch liegen. Lediglich die Start-Stop Skripte scheinen etwas verteilt in der Gegend herumzu liegen – clustern aber hier:

/usr/bin/setuids/restartdhcp
/usr/bin/setuids/restartdnsproxy
/usr/bin/setuids/restartntpd
/usr/bin/setuids/restartsnort
/usr/bin/setuids/restartsquid
/usr/bin/setuids/restartssh
/usr/bin/setuids/restartupnp

Mehr hierzu gibt es da.

dhcp trouble

Meinem IPCop schienen die IPs ausgegangen zu sein und er weigerte sich, einem neuen Gerät eine IP aus der Liste der „verfallenen dynamischen Zuordnungen“ zu geben – warum auch immer.

Also bearbeitete ich auf dem IPCop die Datei

/var/state/dhcp/dhcpd.leases

und löschte eine (der nur scheinbar freien) IP händisch heraus, dann klappt wieder alles: Einstöpseln und das Neugerät bekommt einen Platz im Heimnetz.

Quelle: Hier gefunden und hier wird ausgeführt, dass das keine gute Idee ist.