Grundschulserver

Im folgenden Artikel wird beschrieben, wie das Netz der Schule Max-Eichholz-Ring in Hamburg-Lohbrügge eingerichtet wurde, was für Probleme auftraten und wie man diese lösen konnte. Die Schule besteht aus 11 Gebäuden, die im Zuge einer Vollvernetzung von Dataport vollvernetzt wurden und jetzt über ein 100MBit-Netz verfügen. Als wir ankamen bestand das Netz aus ca. 74 Rechnern, einem Cisco 2600-Router und einem Synology-NAS. Da wir das Passwort für den Router leider nicht bekommen haben, haben wir uns entschieden, einen eigenen Server aufzustellen.

Grundsystem

Als Grundsystem haben wir uns für Ubuntu Server 12.04 LTS entschieden, da Long-Time-Support-Distributionen (=Lang-Zeit-Unterstützte-Distributionen; kurz: LTS) lange mit Sicherheits-Patches versehen werden und man so nicht alle 6 Monate einen kompletten Versions-Sprung vornehmen muss. Das System läuft auf einem normalen Dell-Rechner, der mit einer zusätzlichen Netzwerkkarte ausgestattet wurde. Bei der Installation wurde gleich der SSH-Server und der DNS-Server mit installiert, damit man den Server auch aus der Ferne warten kann. Die Frage, ob Aktualisierungen automatisch installiert werden sollen, beantworten wir mit "Nur Sicherheitsaktualisierungen automatisch installieren". Dann müssen wir uns zwar selber um die Aktualisierung kümmern, haben aber mehr Kontrolle darüber was und vor allem wann es installiert wird. (Denn wer will schon, dass mitten im Urlaub ein Anruf a lá "Hilfe! Es funktioniert nichts mehr" kommt, weil das letzte Update irgendwas zerschossen hat).

Aufgaben

Der Server soll die folgenden Aufgaben erledigen:

• File-Server (Auf den Schulcomputern laufen mehrere Programme, die aus dem Netz starten und somit zentral auf einem Server laufen sollen)
• DHCP-Server (Der Server versorgt das interne Netz mit IP-Adressen, die teils fest vergeben sind)
• DNS-Server/Gateway (Der Server dient als Gateway für das interne Netz über den Router nach draußen [siehe dazu mehr unter Netzaufbau])

Netzaufbau

Der Cisco-Router fungiert als Gateway zum Internet (über das FHH-WAN von Dataport). An ihm hing früher das gesamte Netz über mehrere Switches (er war einfach mit einer Dose am Switch aufgelegt). Dieser Stecker steckt jetzt im Server. Zwischen den beiden ist ein 10.0.2.0er-Netz aufgespannt (vergeben vom Dataport-Router). Dieses liegt an eth0 am Server auf. Der Server selbst hängt mit der anderen Karte (eth1) im internen Netz am Switch. Dahinter dann die Clients:

INTERNET <- Cisco-Router (10.0.2.1) <-eth0/10.0.2.104-  Tux-Server -172.16.1.1/eth1-> INTRANET (172.16.0.0/255.255.0.0)

Einrichtung

Nach der Installation haben wir folgende Dienste installiert:

• apache2 mit php5 und den entsprechenden Modulen
• openssh (schon bei der Installtion)
• samba (File-Server)
• dnsmasq (kleiner, aber feiner DHCP- und DNS-Server)
• bind9 (DNS-Server)
• squid3 (Proxy-Server)

Die Pakete wurde ganz einfach über den Befehl

root@tux:~# apt-get install apache2 php5 openssh-server samba samba-common dnsmasq bind9 squid3

installiert.

Apache

Die Einrichtung von Apache ist kinderleicht. Man installiert die Pakete und kann den Server prinzipiell sofort benutzen. Da der Standard-DocumentRoot-Pfad (/var/www/) uns nicht in die Quere kam, haben wir das auch so gelassen.

openSSH

Nachdem der Server installiert wurde, kann man ihn auch sofort einsetzen. Man muss nur darauf, dass der Firewall-Port auf Port 22 offen ist, sonst bleibt man beim Anmeldeversuch über SSH an der Firewall hängen. Aber auch das wurde automatisch erledigt. Somit ist an dieser Stelle auch keine weitere Konfiguration notwendig. Wenn man möchte, kann man der Sicherheit halber noch dem root die direkte Anmeldung per SSH verbieten. Dazu ändert man in der Datei /etc/sshd/sshd_config den Befehl

PermitRootLogin yes

einfach auf

PermitRootLogin no

Nun kann sich der root-Benutzer nicht mehr direkt anmelden. Authentifizierte Benutzer können sich dann mit dem Befehl

peter@tux:~# su
Passwort: (hier dann das root-Kennwort eingeben)

Root-Rechte verschaffen.

Samba

Die Konfiguration des Samba-Servers ist dagegen schon etwas komplexer, aber wenn man sich eingearbeitet hat, ist das auch kein Problem. Zuerst kopieren wir die Standard-Konfiguration (/etc/samba/smb.conf) zur Sicherheit. Das machen wir mit dem folgenden Befehl:

root@tux:~# cp /etc/samba/smb.conf /etc/samba/smb.conf.org

Damit können wir uns nun einen Fehler erlauben, ohne, dass die Konfiguration völlig verloren geht. Die Datei /etc/samba/smb.conf bearbeiten wir nun mit unserem Lieblingseditor (meiner ist vim):

root@tux:~# vi /etc/samba/smb.conf

Die Datei besteht standardmäßig zu 90% aus Dokumentation. Wenn einem das zu viel ist, kann man die Datei auch vor dem Öffnen löschen (bitte unbedingt vorher sichern!; s.o.):

root@tux:~# rm /etc/samba/smb.conf

und dann erst zum Schreiben öffnen. Das hat den Vorteil, dass man dann wirklich nur das sieht, was man auch sehen möchte. Für Anfänger empfiehlt sich allerdings, die Standard-Konfiguration einfach zu verändern. Interessant für uns sind die Variablen unter [global]:

[global]

Hier wird die Arbeitsgruppe (in Windows-Netzen standardmäßig WORKGROUP oder (wie in unserem Fall) ARBEITSGRUPPE) eingetragen:

workgroup = ARBEITSGRUPPE

Die folgende Variable legt die Beschreibung des Server fest. Der Platzhalter %h wird automatisch durch den Server-Namen ersetzt:

server string = Samba server at %h (Ubuntu, Samba)

Sofern kein anderer Windows-Domänen-Controller oder WINS-Server im Netz läuft, setzen wir die folgende Variable auf yes:

wins support = yes

Ab hier können wir erstmal alles auf der Standard-Einstellung lassen:

;   wins server = w.x.y.z
dns proxy = no
;   name resolve order = lmhosts host wins bcast

Wenn der Server nur aus einem (oder mehreren) Netzen oder einer(/einigen) bestimmten Netzwerkschnittstellen erreichbar sein soll, kann die folgende aktiviert und entsprechend angepasst werden. (Hier werden zum Beispiel nur Verbindungen aus dem Netz 172.16.0.1 - 172.16.255.255 und/oder auf der Netzwerkschnittstelle eth1 angenommen). Falls der Server aus allen Netzen/auf allen Interfaces erreichbar sein soll, kann man das hier mit einem ; auskommentieren.

   interfaces = 172.16.0.0/16 eth1

Jetzt kommen wir zum Logging. Hier konfiguriert man, wo Samba loggen soll und ob zusätzlich (oder überhaupt) in der /var/log/syslog geloggt werden soll: Pfad zu den späteren Log-Files:

log file = /var/log/samba/log.%m

Wie groß die Log-File werden darf:

max log size = 1000

Soll nur in der Syslog geloggt werden (dann würden die oberen beiden Einstellungen überflüssig sein):

syslog only = no

Wenn in der Syslog geloggt werden soll, muss das hier höher als 0 gesetzt werden:

syslog = 0

Was Samba machen soll, falls ein schwerwiegender Fehler passiert (kann auch so bleiben)

panic action = /usr/share/samba/panic-action %d

Die in der smb.conf folgenden Einstellungen können alle so bleiben. Es geht dort um Benutzer- und Domainanmeldung. Das ist für uns erstmal nebensächlich. Der interessanteste Teil findet sich am Ende der Datei. Hier werden die Freigaben konfiguriert. Da wir einige Programme laufen haben, erstellen wir auch einige Freigaben. Die standardmäßig eingestellten Freigaben können wir fast alle (bis auf die Homes-Freigabe, welche wir nur auskommentieren) löschen oder, falls notwendig, nur auskommentieren. Die Freigaben werden dann nach dem folgenden Prinzip untereinander eingetragen: Freigabe-Name (ohne Leerzeichen; alles klein):

[public]

Lange Beschreibung der Freigabe:

comment = Oeffentliches Verzeichnis

Pfad zum Ordner (nicht vergessen, diesen zu erstellen!)

path = /home/samba/public

Dürfen Gäste darauf zugreifen?

guest ok = yes

Ist die Freigabe bei der Freigabe-Abfrage des Servers sichtbar? (Ansonsten kann nur per \\tux\public darauf zugegriffen werden).

browseable = yes

Dürfen die Benutzer schreiben?

writeable = yes

Falls writeable auf no steht, kann man hier eintragen, welche Benutzer schreiben dürfen. Ganzen Gruppen kann man per @GRUPPENNAME den Schreibzugriff gestatten:

write list = lukas,admin,@support

Falls guest ok auf no steht, kann man hier eintragen, welche Benutzer das Verzeichnis betreten dürfen:

valid users = lukas,admin,@support

Hier werden die Datei- und Verzeichnisrechte festgelegt, die beim Anlegen einer Datei/eines Verzeichnisses standardmäßig gesetzt werden:

create mode = 0664
directory mode = 0775

Hier wird angegeben, welchem Benutzer/Gruppe die angelegten Dateien/Verzeichnisse gehören werden.

force user = samba
force group = support

Dann siehts so aus:

[public]
comment = Oeffentliches Verzeichnis
path = /home/samba/public
guest ok = yes
browseable = yes
writeable = yes
write list = lukas,admin,@support
valid users = lukas,admin,@support
create mode = 0664
directory mode = 0775
force user = samba
force group = support

Für die Programme wurden dann jeweils die Verzeichnisse erstellt:

root@tux:/home/samba/# mkdir public
root@tux:/home/samba/# mkdir lernwerkstatt
root@tux:/home/samba/# mkdir budenberg
root@tux:/home/samba/# mkdir gut1

Wenn man alles richtig gemacht hat, sollte der folgende Befehl zum Testen der Konfiguration keine Fehler ausspucken:

root@tux:/home/samba/# testparm

Danach kann man den Samba-Server neu starten und alles sollte laufen:

root@tux:/home/samba/# service smbd restart

Probleme

Der Zugriff auf die Verzeichnisse klappte erst nicht. Es wurde mit der Fehlermeldung "Zugriff verweigert" abgebrochen. Das lag daran, dass die Verzeichnisse extra angelegten Benutzern (budenberg, gut1, lws) gehörten. Nach langem Ausprobieren haben wir dann alle Verzeichnisse dem Benutzer samba und der Gruppe samba übergeben:

root@tux:/home/samba/# chown -R *

Danach lief alles wieder sauber und zufriedenstellend.

dnsmasq

DHCP

dnsmasq ist ein DNS-Forwarder und DHCP-Server. Der Server ist mit zwei Netzwerkkarten in verschiedenen Netzen angebunden (Siehe Netzaufbau weiter oben). Im einen Netz hängt der Cisco-Router mit DNS und DHCP-Server. Auf der anderen Karte hängt der Server im internen Netz, wo er als DNS/DHCP-Server laufen muss. Die Konfiguration von dnsmasq mag anfangs etwas kompliziert klingen, ist aber kinderleicht, wenn man sich eingearbeitet hat. Sie liegt in /etc/dnsmasq.conf. Zuerst dumpen wir die Datei sicherheitshalber wieder, damit wir danach eine neue erstellen können. Hier lohnt es sich die Datei zu verschieben, da die Datei recht umfangreich ist und die benötigte Konfiguration prinzipiell nur drei Zeilen lang ist:

root@tux:/etc# mv dnsmasq.conf dnsmasq.conf.org

Danach öffnen wir die (dann neue) Datei dnsmasq.conf:

root@tux:/etc# vi dnsmasq.conf

Hier tragen wir nun die folgenden drei Zeilen ein: Das Interface, auf dem der DHCP-Server aktiv sein soll:

interface=eth1

Das Interface, auf dem der DHCP-Server nicht aktiv sein soll:

no-dhcp-interface=eth0

Und schließlich den dynamischen IP-Bereich (mit Lease-Time):

dhcp-range=172.16.10.10,172.16.10.254,255.255.0.0,12h

Darunter kann man dann auf noch feste IPs vergeben. Die Befehle werden folgendermaßen aufgebaut:

dhcp-host=<MAC-Adresse>,<Rechnername>,<IP-Adresse>,infinite

oder

dhcp-host=<MAC-Adresse>,<IP-Adresse>,infinite

oder

dhcp-host=<Rechnername>,<IP-Adresse>,infinite

"infinite" ist hier die Lease-Time. Da feste IPs "nie" oder besser sehr lange nicht wieder freigegeben werden müssen, kann man sie auf "für immer" (begrenzt auf 16 Jahre) setzen. Für unser Netz haben wir das folgende Muster gewählt. Hier bekommt jedes Gebäude ein eigenes Subnetz und die beiden Computerräume, die Verwaltung und die DHCP-Clients ebenfalls. Die Netze sind dank Subnetzmaske 255.255.0.0 untereinander routbar:

Haus A -> 172.16.1.*
Haus B -> 172.16.2.*
Haus C -> 172.16.3.*
Haus D -> 172.16.4.*
Haus E -> 172.16.5.*
Haus F -> 172.16.6.*
Haus G -> 172.16.7.*
Haus Verwaltung -> 172.16.8.*
DHCP -> 172.16.10.*
Computerraum 1 -> 172.16.12.*
Computerraum 2 -> 172.16.14.*

DNS/Gateway

Damit das interne Netz nun auch ins Netz kommt (und anders herum auch die Daten aus dem Internet wieder zurück ins lokale Netz), müssen wir die Datenpakete maskieren, dazu muss man folgende Befehle ausführen. Die Einstellungen dazu tragen wir in die Datei /etc/network/interfaces ein. Die Datei sichern wir vorher:

root@tux:/etc/network/# cp interfaces /root/

Danach können wir sie öffnen:

root@tux:/etc/network/# vi interfaces

Nun ergänzen wir die feste IP-Adresse auf eth1, damit der Server auf immer unter einer Adresse erreichbar ist (Achtung: Das Interface lo wird unbedingt benötigt, also nicht löschen!):

# externes Netz
auto eth0
iface eth0 inet dhcp
# internes Netz
auto eth1
iface eth1 inet static
address 172.16.1.1
netmask 255.255.0.0
broadcast 172.16.255.255

Nun kommen wir zur Konfiguration der Firewall. Die Einstellungen ebenfalls - unterhalb der IP-Konfiguration - in der /etc/network/interfaces eingetragen werden, damit sie, falls notwendig, bei jedem Start neu gesetzt werden: Die folgende Anleitung stammt leicht verändert aus dem ubuntuusers-Wiki/Router:

up /sbin/iptables -F
up /sbin/iptables -X
up /sbin/iptables -t nat -F

# Forwarding für alle verwendeten Schnittstellen im lokalen Netz aktivieren 
up /sbin/iptables -A FORWARD -o eth0 -i eth1 -s 172.16.0.0/16 -m conntrack --ctstate NEW -j ACCEPT
up /sbin/iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
up /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 
up /sbin/sysctl -w net.ipv4.ip_forward=1 

# dnsmasq neu starten
up /etc/init.d/dnsmasq restart

Damit ist das Netz prinzipiell betriebsbereit, allerdings müssen wir noch die Netzwerkinterfaces neustarten:

root@tux:~# /etc/init.d/networking restart

Allerdings stoßen wir hier auf einen Fehler, a lá

RTNETLINK answers: File exists
failed to bring up eth1

Das lässt sich einfach mit einem kompletten Server-Neustart lösen. Allerdings müssen wir vorher noch eine Sache ergänzen. In der Datei /etc/bind9/named.conf.options muss unter "forwarders" noch die IP des Cisco-Routers eingetragen werden. Dazu öffnen wir sie und geben folgendes ein bzw. ergänzen es:

forwarders {
10.0.2.1
8.8.8.8
}

Das sorgt dafür, dass die DNS-Anfragen, die unser Server nicht lokal routen kann an den Router weitergegeben werden. Falls dieser sie ebenfalls nicht beantworten kann oder gerade zu viel zu tun hat, macht das der Google-Server (IP: 8.8.8.8) für uns.

Neustart!

Jetzt können wir einen kompletten Neustart machen:

root@tux:~# shutdown -r now

Danach sollte alles ordnungsgemäß funktionieren.