|
Mittels diesem Attribut kann man einen Dienst an eine IP Adresse binden.
Besitzt der Rechner sowieso nur eine Adresse, ist dies nicht sehr
sinnig. Ein Rechner allerdings, der einerseits an einem lokalen
Netzwerk, andereseits an das Internet angebunden ist, besitzt mindestens
zwei Adressen.
Angenommen, eine Firma möchte einen FTP Server für ihre Angestellten
installieren, etwa, damit diese auf interne Dokumente zugreifen und
diese lesen können. Desweiteren sollen Kunden mittels FTP auf die
Firmenprodukte zugreifen können. bind ist wie geschaffen für diesen Fall.
Es werden zwei FTP Dienste definiert. Diese müssen allerdings von
xinetd unterschieden werden können.
Dazu wird das Attribut id verwendet.
Durch dieses wird ein Dienst eindeutig identifiziert. Sollte ein Dienst
dem Attribut keinen Wert zuweisen, so wird standardmäßig der Dienstname
als Wert verwendet.
service ftp
{
id = ftp-public
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l
instances = 4
nice = 10
only_from = 0.0.0.0/0 #allows every client
bind = 212.198.253.142 #public IP address for this server
}
service ftp
{
id = ftp-private
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l
only_from = 192.168.1.0/24 #only for internal use
bind = 192.168.1.1 #local IP address for this server (charly)
}
|
Durch den Einsatz von bind kann das jeweilige Daemonprogramm
angesprochen werden, abhängig von der Zieladresse der Pakete. Will ein
Client im lokalen Netzwerk auf interne Daten zugreifen, so muss er die
lokale Adresse (bzw. den assoziierten Rechnernamen) des FTP Servers
verwenden. In der Protokolldatei steht dann:
00/9/17@16:47:46: START: ftp-public pid=26861 from=212.198.253.142
00/9/17@16:47:46: EXIT: ftp-public status=0 pid=26861 duration=30(sec)
00/9/17@16:48:19: START: ftp-internal pid=26864 from=192.168.1.1
00/9/17@16:48:19: EXIT: ftp-internal status=0 pid=26864 duration=15(sec)
|
Der erste Teil stammt vom Befehl ftp 212.198.253.142, während der zweite
Teil vom Aufruf von charly auf sich selbst resultiert: ftp 192.168.1.1.
Was passiert aber nun, falls ein Rechner keine zwei statischen IP
Adressen hat? Dies ist zum Beispiel bei  PPP Verbindungen
oder beim Einsatz von DHCP der Fall.
Es wäre besser, könnten Dienste an
Netzwerkschnittstellen selbst, anstatt an Adressen gebunden werden. Dies
jedoch ist bei xinetd noch nicht in Sicht und stellt ein wirkliches
Problem dar. Das Design eines C Modules beispielsweise, dass auf ein
Netzwerkinterface oder eine Adresse zugreifen soll, ist stark vom
jeweiligen Betriebssystem abhängig, und da xinetd auf vielen Plattformen
arbeiten soll, ist dies problematisch. Unter Verwendung eines Skriptes
kann das Problem gelöst werden:
#!/bin/sh
PUBLIC_ADDRESS=`/sbin/ifconfig $1 | grep "inet addr" | awk '{print $2}'| awk -F: '{print $2}'`
sed s/PUBLIC_ADDRESS/"$PUBLIC_ADDRESS"/g /etc/xinetd.base > /etc/xinetd.conf
|
Dieses Skript liest die gewünschte Konfiguration aus der Datei
/etc/xinetd.base aus, wobei PUBLIC_ADDRESS als Platzhalter für die
dynamische Adresse steht und nimmt die entsprechenden Änderungen in
/etc/xinetd.conf vor. Hierbei wird PUBLIC_ADDRESS durch die Adresse
ersetzt, die dem Interface zugeordnet ist, welches dem Skript als
Parameter übergeben wird. Der Aufruf des Skriptes hängt von der Art der
Verbindung ab: Am einfachsten ist es, den Aufruf in die jeweilige ifup-*
Datei einzutragen und xinetd neu zu starten.
|
SelfLinux 
