Die Informationen in den folgenden Abschnitten sind jeweils spezifisch für die jeweilige Technologie. Die darin gemachten Aussagen gelten nicht automatisch auch für andere Netzwerk Technologien.
Die Device Namen für ARCNET sind arc0s, arc1e, arc2e usw.
Der ersten gefundenen Karte wird automatisch der Eintrag arc0
zugewiesen, den weiteren Karten die folgenden Nummern in der Reihenfolge
ihrer Erkennung. Der Buchstabe am Ende des Devicenamens gibt an, ob als
Paketformat Ethernet Encapsulation oder RFC 1051 ausgewählt wurde.
Optionen beim Kernel kompilieren:
Network device support --->
[*] Network device support
<*> ARCnet support
[ ] Enable arc0e (ARCnet "Ether-Encap" packet format)
[ ] Enable arc0s (ARCnet RFC1051 packet format)
Ist die Unterstützung für die Karte erst einmal im Kernel eingebunden, ist die Konfiguration einfach. Typischerweise geschieht das etwa so:
# ifconfig arc0e 192.168.0.1 netmask 255.255.255.0 up
# route add 192.168.0.0 netmask 255.255.255.0 arc0e
/usr/src/linux/Documentation/networking/arcnet-hardware.txt
enthält weitere Informationen zu diesem Thema.
Die ARCNet Unterstützung wurde von
Avery Pennarun (apenwarr@foxnet.net) entwickelt.
Hierfür gibt es keine speziellen Device-Einträge, da bestehende Netzwerk-Devices genutzt werden.
Optionen beim Kernel kompilieren:
Networking options --->
<*> Appletalk DDP
netatalk. Wesley Craig
(netatalk@umich.edu) steht stellvertretend für ein Team an
der University of Michigan, das sich »Research Systems Unix Group«
nennt. Sie haben das Paket netatalk mit der notwendigen Software
entwickelt, nämlich der Implementation des Appletalk Protocoll Stack
sowie weitere nützliche Hilfsprogramme. Das Paket netatalk ist
entweder bereits Bestandteil ihrer Linux Distribution oder kann über FTP
von der University of Michigan bezogen werden
terminator.rs.itd.umich.edu:/unix/netatalk/Um das Paket zu übersetzen und zu installieren geht man folgendermaßen vor:
# cd /usr/src
# tar xvfz .../netatalk-1.4b2.tar.Z
Makefile
editieren, um die Software an das eigene System anzupassen. So legt z.B.
die Variable DESTDIR fest, wohin die Dateien installiert werden.
# make
# make install
Damit später alles einwandfrei funktioniert, sind zunächst einige
zusätzliche Einträge in der Datei /etc/services nötig. Diese
sind:
rtmp 1/ddp # Routing Table Maintenance Protocol
nbp 2/ddp # Name Binding Protocol
echo 4/ddp # AppleTalk Echo Protocol
zip 6/ddp # Zone Information Protocol
Als nächstes müssen die Konfigurationsdateien im Verzeichnis
/usr/local/atalk/etc angelegt werden. Eventuell hat das
Verzeichnis auch einen anderen Namen. Das hängt davon ab, wo das
Paket installiert wurde.
Die erste Datei ist atalkd.conf. Man benötigt hier vorläufig nur
eine einzige Zeile, in der festgelegt wird, über welches Netzwerk Device
die Apple Rechner erreicht werden:
eth0
Der Appletalk Daemon wird nach seinem Start weitere Details hinzufügen.
Man kann Dateisysteme des Linuxrechners auch an Apple-Rechner exportieren, sodaß diese von beiden Rechnern gemeinsam genutzt werden können.
Dafür muß man die Datei
/usr/local/atalk/etc/AppleVolumes.system entsprechend
konfigurieren. Im selben Verzeichnis gibt es außerdem noch die Datei
AppleVolumes.default. Sie hat dasselbe Format und legt fest,
welche Dateisysteme für Nutzer zur Verfügung stehen, die sich als
Gastnutzer anmelden.
Die genauen Details für diese Konfiguration entnehmen sie bitte der
manual page zum afpd. Eine einfache Konfiguration könnte etwa so aussehen:
/tmp Scratch
/home/ftp/pub "Public Area"
Dadurch wird das lokale Verzeichnis /tmp als AppleShare Volume
Scratch und das öffentliche FTP-Verzeichnis als AppleShare Volume
Public Area exportiert. Die Namen für die Volumes müssen nicht
angegeben werden. Wenn sie fehlen, weist der Daemon automatisch passende
Namen zu.
Die gemeinsame Nutzung eines Druckers läßt sich einfach
verwirklichen. Man muß dazu das Programm papd starten, den
Appletalk Printer Access Protocol Daemon. Dieses Programm übernimmt die
Druckaufträge von Applerechnern im Netz und leitet sie an den lokale
Drucker Spool Daemon weiter.
Zur Konfiguration dieses Daemon dient die Datei papd.conf. Die
Syntax entspricht dabei der der Datei /etc/printcap. Der Name,
der in der Datei definiert wird, wird dann über das Appletalk Naming
Protokoll, NBP, registriert.
Hier eine Beispielkonfiguration:
TricWriter:\
:pr=lp:op=cg:
Dadurch wird im Appletalk Netzwerk ein Drucker namens TricWriter zur
Verfügung gestellt. Alle Druckaufträge an diesen Drucker werden durch
den Drucker-Daemon lpd über den Linux-Drucker lp, der in der
Datei /etc/printcap definiert sein muß, ausgedruckt. Der
Eintrag op=cg legt fest, daß der Druckauftrag unter der ID des
Linux-Nutzers cg abgewickelt wird.
Nun ist alles soweit konfiguriert; der erste Test kann beginnen. Zum
Paket netatalk gehört eine Datei rc.atalk, die für
Normalanwendungen funktionieren sollte. Alles was zu tun bleibt, ist
diese Datei aufzurufen:
# /usr/local/atalk/etc/rc.atalk
Alles sollte nun einwandfrei laufen. Fehlermeldungen sollten keine auftreten. Der Start der Software wird, ebenso wie weitere Statusmeldungen, über die Konsole ausgegeben.
Um zu überprüfen ob alles einwandfrei funktioniert, begeben Sie sich an einen ihrer Apple Rechner, öffnen sie das Apple Menue, wählen »Chooser« aus und klicken auf AppleShare. Ihr Linux-Rechner sollte sich nun melden.
/etc/rc.d/rc.inet1 zu starten.afpd (der Apple Filing Protocol Daemon) bringt die Festplatte
ziemlich durcheinander. Er legt im gemounteten Verzeichnisbaum eine
Vielzahl von Verzeichnissen an: .AppleDesktop und Network
Trash Folder. Weiterhin wird darin für jedes angesprochene
Verzeichnis ein .AppleDouble angelegt, um darin Resource Forks
usw. zu speichern. Überlegen Sie es sich genau, bevor sie ihr
Rootverzeichnis / exportieren. Die Aufräumarbeiten hinterher
haben es in sich.afpd erwartet von Macs Paßworte in Klartext,
Sicherheitsbedenken sind also berechtigt. Benutzen Sie diesen Daemon auf
einer Maschine, die selber am Internet hängt, müssen Sie sich an die
eigene Nase fassen, wenn hinterher jemand diese Schwachstellen
ausnutzt.netstat oder ifconfig
unterstützen kein Appletalk. Die Information ist - unformatiert - über
/proc/net zugänglich.
Eine sehr viel detailliertere Beschreibung, wie man Appletalk für Linux konfiguriert, finden Sie auf der Seite Linux Netatalk HOWTO von Anders Brownworth unter folgender Adresse:
http://thehamptons.com/anders/netatalk/
Werner Almesberger (werner.almesberger@lrc.di.epfl.ch)
leitet ein Projekt mit dem Ziel, auch unter Linux ATM (Asynchronous
Transfer Mode) zu unterstützen. Den aktuellen Stand des Projektes
erfährt man über:
http://lrcwww.epfl.ch/linux-atm/
AX.25 Devicenamen sind sl0, sl1 usw. in 2.0.x Kernels bzw.
ax0, ax1 usw. in 2.1.x Kernels.
Optionen beim Kernel kompilieren:
Networking options --->
[*] Amateur Radio AX.25 Level 2
Der Großteil der Arbeit bei der Implementation dieser Protokolle wurde
von Jonathon Naylor (jsn@cs.not.ac.uk) geleistet.
An der Unterstützung von DECNet wird derzeit gearbeitet. Es wird
vermutlich in den späten 2.1.x Kernels auftauchen.
EQL Devices haben den Namen eql. Bei den Standard Kernels gibt es nur
eines dieser Devices. Es nutzt mehrere Point-to-Point Verbindungen
(PPP, SLIP, PLIP) und faßt sie zu einer einzigen logischen Leitung
zusammen, um darüber eine TCP/IP Verbindung aufzubauen. Der Hintergrund
dabei ist, daß mehrere langsame Leitungen oft billiger als eine schnelle
sind.
Optionen beim Kernel kompilieren:
Network device support --->
[*] Network device support
<*> EQL (serial line load balancing) support
Um diesen Mechanismus zu nutzen, müssen beide Rechner EQL unterstützen. Dies ist bei Linux, neueren Dial-in Servern und Livingstone Portmastern möglich.
Um EQL richtig zu konfigurieren, benötigt man die EQL Tools:
metalab.unc.edu:/pub/linux/system/Serial/eql-1.2.tar.gzDie Konfiguration ist sehr logisch aufgebaut. Zunächst wird das
EQL Interface konfiguriert. Es verhält sich wie jedes andere
Netzwerkinterface auch; man konfiguriert IP Adresse und MTU mittels
ifconfig, also etwa so:
# ifconfig eql 192.168.10.1 mtu 1006
# route add default eql
Als nächstes müssen die zu nutzenden Verbindungen von Hand aufgebaut werden. Jede denkbare Kombination von Point-to-Point Verbindungen ist möglich. Lesen sie diesbezüglich die entsprechenden Abschnitte dieses Dokumentes.
Nun müssen diese seriellen Verbindungen mit dem EQL Device verknüpft werden.
Man nennt das »enslaving«, der entsprechende Befehl lautet
eql_enslave, z.B.:
# eql_enslave eql sl0 28800
# eql_enslave eql ppp0 14400
Um eine Leitung wieder aus dem EQL Verbund zu entfernen, dient der Befehl
eql_emancipate. Wieder ein Beispiel:
# eql_emancipate eql sl0
Das Routing wird wie für jede andere Point-to-Point Verbindung aufgesetzt. Der einzige Unterschied ist, das anstelle des seriellen Device das EQL-Device angegeben wird:
# route add default eql0
Der EQL Treiber wurde von
Simon Janes (simon@ncm.com) entwickelt.
Die Devicenamen für Ethernet sind eth0, eth1, eth2 usw.
Der ersten gefundenen Karte wird eth0 zugewiesen, die weiteren
werden fortlaufend durchnumeriert.
Zur Inbetriebnahme einer Ethernetkarte unter Linux existiert ein eigenes HOWTO, das Ethernet HOWTO.
Ist der Kernel mit Unterstützung für Ethernetkarten kompiliert, ist die Konfiguration der Karte einfach. Typischerweise verwendet man etwa folgende Befehle:
# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
# route add 192.168.0.0 netmask 255.255.255.0 eth0
Die meisten der Treiber für Ethernetkarten wurden von Donald Becker
(becker@CESDIS.gsfc.nasa.gov) entwickelt.
Die Devicenamen für FDDI sind fddi0, fddi1, fddi2 usw.
Der ersten gefundenen Karte wird fddi0 zugewiesen, die weiteren
werden fortlaufend durchnumeriert.
Lawrence V. Stefani (stefani@lkg.dec.com) hat einen Treiber für die
EISA und PCI Karten der Digital Equipment Corporation entwickelt.
Optionen beim Kernel kompilieren:
Network device support --->
[*] FDDI driver support
[*] Digital DEFEA and DEFPA adapter support
Ist der Kernel mit Unterstützung für FDDI kompiliert, ist die Konfiguration praktisch identisch zu derjenigen eines Ethernet Interface: Es müssen lediglich die entsprechenden FDDI-Devicenamen angegeben werden.
Die Devicenamen für Frame Relay sind dlci00, dlci01 usw. für
Devices mit DLCI Encapsulation und sdla0, sdla1 usw. für
solche mit FRAD.
Frame Relay ist eine neue Netzwerktechnologie. Sie wurde speziell für Umgebungen entwickelt, in denen die Netzauslastung intermittierend ist, also oft kurzzeitig scharfe Spitzen auftreten. Für den Zugang zu einem Frame Relay Netzwerk benötigt man ein Frame Relay Access Device (FRAD). Die Frame Relay Unterstützung unter Linux hält sich an RFC 1490.
Optionen beim Kernel kompilieren:
Network device support --->
<*> Frame relay DLCI support (EXPERIMENTAL)
(24) Max open DLCI
(8) Max DLCI per device
<*> SDLA (Sangoma S502/S508) support
Die Frame Relay Treiber und Konfigurationsprogramme wurden von
Mike McLagan (mike.mclagan@linux.org) entwickelt.
Derzeit werden allerdings nur diese Karten unterstützt:
Sangoma Technologies (
http://www.sangoma.com)
S502A, S502E und S508.
Um die FRAD und DLCI Devices zu konfigurieren, benötigen Sie spezielle Programme, die Frame Relay Configuration Tools. Diese bekommen Sie bei
ftp.invlogic.com:/pub/linux/fr/frad-0.15.tgz
# cd /usr/src
# tar xvfz .../frad-0.15.tgz
# cd frad-0.15
# for i in common dlci frad; do cd $i; make clean; make; \
cd ..; done
# mkdir /etc/frad
# install -m 644 -o root -g root bin/*.sfm /etc/frad
# install -m 700 -o root -g root frad/fradcfg /sbin
# install -m 700 -o root -g root dlci/dlcicfg /sbin
Nach der Installation müssen Sie die Datei
/etc/frad/router.conf anlegen. Dafür ist folgende Vorlage
hilfreich, bei der es sich um eine abgeänderte Version der dem
Paket beiliegenden Beispieldatei handelt:
# /etc/frad/router.conf
# Dies ist eine Beispielkonfiguration für Frame Relay.
# Alle möglichen Einträge sind aufgeführt, die Standard-
# einstellungen basieren auf dem Code des DOS-Treibers
# für die Karte S502A von Sangoma.
#
# Ein "#" irgendwo in der Zeile leitet einen Kommentar
# ein. Leerzeilen werden ignoriert (TAB ist auch erlaubt).
# Unbekannte Einträge [] oder Zeichen werden ignoriert.
[Devices]
Count=1 # Anzahl zu konfigurierender Devices
Dev_1=sdla0 # Name eines Device
#Dev_2=sdla1 # Name eines Device
# An dieser Stelle angegeben, gelten die Einträge für
# alle Devices. Sie koennen für einzelne Karten in den
# entsprechenden Abschnitten verändert werden.
Access=CPE
Clock=Internal
KBaud=64
Flags=TX
# MTU=1500 # Maximum transmit IFrame length,
# # default is 4096
# T391=10 # T391 value 5 - 30, default is 10
# T392=15 # T392 value 5 - 30, default is 15
# N391=6 # N391 value 1 - 255, default is 6
# N392=3 # N392 value 1 - 10, default is 3
# N393=4 # N393 value 1 - 10, default is 4
# An dieser Stelle angegeben, werden Standardwerte für
# alle Devices festgelegt.
# CIRfwd=16 # CIR forward 1 - 64
# Bc_fwd=16 # Bc forward 1 - 512
# Be_fwd=0 # Be forward 0 - 511
# CIRbak=16 # CIR backward 1 - 64
# Bc_bak=16 # Bc backward 1 - 512
# Be_bak=0 # Be backward 0 - 511
#
# Device spezifische Konfiguration
#
#
# Das erste Device ist eine Sangoma S502E
#
[sdla0]
Type=Sangoma # Art des Device
# SANGOMA ist bekannt
#
# Diese Einträge sind spezifisch für Sangoma
#
# Typ der Sangoma Karte - S502A, S502E, S508
Board=S502E
# Name der Test-Firmware für das Sangoma Board
# Testware=/usr/src/frad-0.10/bin/sdla_tst.502
# Name der FR Firmware
# Firmware=/usr/src/frad-0.10/bin/frm_rel.502
Port=360 # Port für diese Karte
Mem=C8 # Adresse für Memory Window, A0-EE
IRQ=5 # IRQ Nummer, für S502A nicht angeben
DLCIs=1 # Anzahl der DLCIs an diesem Device
DLCI_1=16 # DLCI #1's Nummer, 16 - 991
# DLCI_2=17
# DLCI_3=18
# DLCI_4=19
# DLCI_5=20
# Hier angegeben, gelten die Einträge nur für die
# jeweilige Karte und überschreiben im globalen Teil
# gemachte Einstellungen.
# Access=CPE # CPE oder NODE, Default ist CPE
# Flags=TXIgnore,RXIgnore,BufferFrames,DropAborted,Stats,MCI,AutoDLCI
# Clock=Internal # External oder Internal, Default ist Internal
# Baud=128 # Angegebene Baud Rate des angeschlossenen CSU/DSU
# MTU=2048 # Maximale IFrame Laenge, Default ist 4096
# T391=10 # T391 value 5 - 30, Default ist 10
# T392=15 # T392 value 5 - 30, Default ist 15
# N391=6 # N391 value 1 - 255, Default ist 6
# N392=3 # N392 value 1 - 10, Default ist 3
# N393=4 # N393 value 1 - 10, Default ist 4
#
# Die zweite Karte ist irgendeine andere Karte
#
# [sdla1]
# Type=FancyCard # Art des Device
# Board= # Typ der Sangoma Karte
# Key=Value # Einträge spezifisch für dieses
# # Device
# DLCI Default Konfigurationsparameter
# Diese können in den jeweiligen spezifischen
# Abschnitten überschrieben werden.
CIRfwd=64 # CIR forward 1 - 64
# Bc_fwd=16 # Bc forward 1 - 512
# Be_fwd=0 # Be forward 0 - 511
# CIRbak=16 # CIR backward 1 - 64
# Bc_bak=16 # Bc backward 1 - 512
# Be_bak=0 # Be backward 0 - 511
#
# DLCI Konfiguration
# Alle Eintraege sind optional. Namenkonvention ist:
# [DLCI_D<devicenum>_<DLCI_Num>]
#
[DLCI_D1_16]
# IP=
# Net=
# Mask=
# Von Sangoma definierte Flags sind:
# TXIgnore,RXIgnore,BufferFrames
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
# CIRfwd=64
# Bc_fwd=512
# Be_fwd=0
# CIRbak=64
# Bc_bak=512
# Be_bak=0
[DLCI_D2_16]
# IP=
# Net=
# Mask=
# Von Sangoma definierte Flags sind:
# TXIgnore,RXIgnore,BufferFrames
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
# CIRfwd=16
# Bc_fwd=16
# Be_fwd=0
# CIRbak=16
# Bc_bak=16
# Be_bak=0
Ist die Datei /etc/frad/router.conf angelegt, bleibt nur noch
die Konfiguration der eigentlichen Devices. Dies ist nicht viel
schwieriger als die übliche Konfiguration eines Netzwerk Devices. Man
muß nur daran denken, die FRAD Devices vor den DLCI Devices zu
konfigurieren.
# Konfiguriere FRAD Hardware und DLCI Parameter
# /sbin/fradcfg /etc/frad/router.conf || exit 1
# /sbin/dlcicfg file /etc/frad/router.conf
#
# Aktiviere FRAD Device
ifconfig sdla0 up
#
# Konfiguriere das DLCI Encapsulation Interface und
# Routing
ifconfig dlci00 192.168.10.1 pointopoint 192.168.10.2 up
route add 192.168.10.0 netmask 255.255.255.0 dlci00
#
ifconfig dlci01 192.168.11.1 pointopoint 192.168.11.2 up
route add 192.168.11.0 netmask 255.255.255.0 dlci00
#
route add default dev dlci00
#
IP Accounting im Kernel erlaubt es, Daten über die Nutzung des Netzwerkes zu sammeln und zu analysieren. Die Daten umfassen die Anzahl der Pakete bzw. Bytes seit dem letzten Reset der Zähler. Es können eine Vielzahl von Regeln festgelegt werden, um die verschiedenen Zähler den eigenen Bedürfnissen anzupassen.
Optionen beim Kernel kompilieren:
Networking options --->
[*] IP: accounting
Nach Kompilierung und Installation des Kernels benötigen sie das
Programm ipfwadm, um das IP Accounting zu konfigurieren. Es gibt
eine Menge unterschiedlicher Wege, die Accounting Information in
verschiedene Bereiche aufzuspalten. Hier ist ein einfaches Beispiel als
Anregung; für weitergehende Informationen sollten Sie die manual page zu
ipfwadm lesen.
Das Szenario für das Beispiel ist folgendes: Ein lokales Ethernet ist
über eine serielle PPP-Leitung mit dem Internet verbunden. Im Internet
steht ein Rechner, der einige Dienste zur Verfügung stellt. Sie sind
daran interessiert zu erfahren, welchen Anteil der Auslastung durch die
Dienste telnet, rlogin, FTP und WWW verursacht wird.
Eine entsprechende Konfiguration sieht so aus:
#
# Löschen der bestehenden Accounting Regeln
ipfwadm -A -f
#
# Neue Regeln für das lokale Ethernet Segment
ipfwadm -A in -a -P tcp -D 44.136.8.96/29 20
ipfwadm -A out -a -P tcp -S 44.136.8.96/29 20
ipfwadm -A in -a -P tcp -D 44.136.8.96/29 23
ipfwadm -A out -a -P tcp -S 44.136.8.96/29 23
ipfwadm -A in -a -P tcp -D 44.136.8.96/29 80
ipfwadm -A out -a -P tcp -S 44.136.8.96/29 80
ipfwadm -A in -a -P tcp -D 44.136.8.96/29 513
ipfwadm -A out -a -P tcp -S 44.136.8.96/29 513
ipfwadm -A in -a -P tcp -D 44.136.8.96/29
ipfwadm -A out -a -P tcp -D 44.136.8.96/29
ipfwadm -A in -a -P udp -D 44.136.8.96/29
ipfwadm -A out -a -P udp -D 44.136.8.96/29
ipfwadm -A in -a -P icmp -D 44.136.8.96/29
ipfwadm -A out -a -P icmp -D 44.136.8.96/29
#
# Default Regeln
ipfwadm -A in -a -P tcp -D 0/0 20
ipfwadm -A out -a -P tcp -S 0/0 20
ipfwadm -A in -a -P tcp -D 0/0 23
ipfwadm -A out -a -P tcp -S 0/0 23
ipfwadm -A in -a -P tcp -D 0/0 80
ipfwadm -A out -a -P tcp -S 0/0 80
ipfwadm -A in -a -P tcp -D 0/0 513
ipfwadm -A out -a -P tcp -S 0/0 513
ipfwadm -A in -a -P tcp -D 0/0
ipfwadm -A out -a -P tcp -D 0/0
ipfwadm -A in -a -P udp -D 0/0
ipfwadm -A out -a -P udp -D 0/0
ipfwadm -A in -a -P icmp -D 0/0
ipfwadm -A out -a -P icmp -D 0/0
#
# Auflisten der Regeln
ipfwadm -A -l -n
#
Ein wichtiger Punkt bei der Auswertung der Accounting Informationen ist, daß die Zähler für alle zutreffenden Regeln erhöht werden. Für eine genaue, differentielle Analyse muß man also ein wenig rechnen. Um z.B. herauszufinden, welcher Datenanteil nicht von FTP, telnet, rlogin oder WWW herrührt, müssen die Summe der Zahlenwerte der einzelnen Ports subtrahiert werden von der Regel, die alle Ports umfaßt:
# ipfwadm -A -l -n
IP accounting rules
pkts bytes dir prot source destination ports
0 0 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 20
0 0 out tcp 44.136.8.96/29 0.0.0.0/0 20 -> *
0 0 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 23
0 0 out tcp 44.136.8.96/29 0.0.0.0/0 23 -> *
10 1166 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 80
10 572 out tcp 44.136.8.96/29 0.0.0.0/0 80 -> *
242 9777 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 513
220 18198 out tcp 44.136.8.96/29 0.0.0.0/0 513 -> *
252 10943 in tcp 0.0.0.0/0 44.136.8.96/29 * -> *
231 18831 out tcp 0.0.0.0/0 44.136.8.96/29 * -> *
0 0 in udp 0.0.0.0/0 44.136.8.96/29 * -> *
0 0 out udp 0.0.0.0/0 44.136.8.96/29 * -> *
0 0 in icmp 0.0.0.0/0 44.136.8.96/29 *
0 0 out icmp 0.0.0.0/0 44.136.8.96/29 *
0 0 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 20
0 0 out tcp 0.0.0.0/0 0.0.0.0/0 20 -> *
0 0 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 23
0 0 out tcp 0.0.0.0/0 0.0.0.0/0 23 -> *
10 1166 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 80
10 572 out tcp 0.0.0.0/0 0.0.0.0/0 80 -> *
243 9817 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 513
221 18259 out tcp 0.0.0.0/0 0.0.0.0/0 513 -> *
253 10983 in tcp 0.0.0.0/0 0.0.0.0/0 * -> *
231 18831 out tcp 0.0.0.0/0 0.0.0.0/0 * -> *
0 0 in udp 0.0.0.0/0 0.0.0.0/0 * -> *
0 0 out udp 0.0.0.0/0 0.0.0.0/0 * -> *
0 0 in icmp 0.0.0.0/0 0.0.0.0/0 *
0 0 out icmp 0.0.0.0/0 0.0.0.0/0 *
#
Es gibt einige Anwendungen, bei denen es hilfreich ist, wenn man einem einzelnen Netzwerk-Device mehrere IP Adressen zuweisen kann. Provider für Internet Dienste verwenden dies häufig, um ihren Kunden speziell angepaßte WWW- und FTP-Dienste anzubieten.
Optionen beim Kernel kompilieren:
Networking options --->
....
[*] Network aliasing
....
<*> IP: aliasing support
Die Konfiguration für IP Aliasing ist sehr einfach. Die Aliases werden
virtuellen Netzwerk Devices zugewiesen, die an das tatsächliche Device
gekoppelt sind. Eine einfache Namenskonvention für diese Devices ist
<Devicename>:<virtuelle Dev Nummer>, also z.B.
eth0:0, ppp0:10 usw.
Als Beispiel nehmen wir ein Ethernet Netzwerk mit zwei IP Subnetzwerken an. Um beide gleichzeitig über eine Netzwerkkarte anzusprechen, dienen folgende Befehle:
# ifconfig eth0:0 192.168.1.1 netmask 255.255.255.0 up
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0:0
#
# ifconfig eth0:1 192.168.10.1 netmask 255.255.255.0 up
# route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0
Um einen Alias zu löschen, hängen sie einfach ein - an das Ende
seines Namens an:
# ifconfig eth0:0- 0
Alles was mit IP Firewall und Firewalls allgemein zu tun hat, wird ausführlich im Firewall HOWTO erläutert. Ein IP Firewall erlaubt es, den Rechner oder ein ganzes Netzwerk gegen unerlaubte Netzzugriffe abzuschotten, indem Datenpakete von und zu angegebenen IP-Adressen gefiltert werden. Es existieren drei unterschiedliche Klassen für Regeln: Incoming Filter, Outgoing Filter und Forward Filter. Incoming Filter werden auf Datenpakete angewandt, die über eine Netzwerkschnittstelle empfangen werden. Outgoing Filter gelten für Datenpakete, die über eine Netzwerkschnittstelle ausgegeben werden. Forward Filter werden auf Datenpakete angewandt, die zwar angenommen werden, aber nicht für den eigenen Rechner bestimmt sind, also solche, die gerouted werden.
Optionen beim Kernel kompilieren:
Networking options --->
[*] Network firewalls
....
[*] IP: forwarding/gatewaying
....
[*] IP: firewalling
[ ] IP: firewall packet logging
Die Konfiguration eines IP Firewall wird mit dem Befehl ipfwadm
durchgeführt. Wie bereits erwähnt bin ich kein Experte in Sachen
Sicherheit. Obwohl hier ein Beispiel für die Konfiguration angegeben
wird, sollten Sie weitere Nachforschungen auf diesem Gebiet anstellen
und ihre eigenen Regeln zusammensuchen, wenn Sie wirklich auf Sicherheit
bedacht sind.
Am weitesten Verbreitet ist die Benutzung von IP Firewalls, um einen Linux-Rechner als Router und Firewall Gateway für ein lokales Netzwerk einzusetzen und dieses gegen unerlaubten Zugriff von außerhalb zu sichern.
Die folgende Konfiguration basiert auf einem Beitrag von
Arnt Gulbrandsen (agulbra@troll.no).
Das Beispiel beschreibt die Konfiguration der Firewall-Regeln des Linux Firewall/Router Rechners aus folgendem Schaubild:
- -
\ | 172.16.37.0
\ | /255.255.255.0
\ --------- |
| 172.16.174.30 | Linux | |
NET =================| f/w |------| ..37.19
| PPP | router| | --------
/ --------- |--| Mail |
/ | | /DNS |
/ | --------
- -
Die folgenden Befehle gehören eigentlich in eine rc-Datei, so daß
sie automatisch bei jedem Systemstart ausgeführt werden. Um maximale
Sicherheit zu erreichen, sollten sie nach der Konfiguration der
Netzwerk Devices, aber vor deren Aktivierung ausgeführt werden.
Dadurch wird ein Einbruch während des Bootens unterbunden.
#!/bin/sh
# Löschen der Forwarding Regeln
# Default Policy auf "accept"
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p accept
# .. ebenso fuer "Incoming"
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p accept
# Als erstes das PPP Interface schließen.
# Besser wäre hier "-a deny" anstelle von "-a reject -y",
# aber dann wäre es auch nicht mehr möglich, über dieses
# Interface selber eine Verbindung aufzubauen.
# Das -o veranlasst, daß alle geblockten Datagramme
# protokolliert werden. Das verbraucht viel Plattenplatz,
# andernfalls ist man aber über Angriffsversuche oder
# Fehlkonfiguration im Unklaren.
/sbin/ipfwadm -I -a reject -y -o -P tcp -S 0/0 \
-D 172.16.174.30
# Einige offensichtlich falsche Pakete werden sofort
# abgewiesen: Von multicast/anycast/broadcast Adressen
# sollte nichts kommen.
/sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24
# Auch vom Loopback Netzwerk sollten keine Pakete auf der
# Leitung erscheinen.
/sbin/ipfwadm -F -a deny -o -S 127.0/8 -D 172.16.37.0/24
# Eingehende SMTP und DNS Verbindungen werden akzeptiert,
# aber nur an den Mail/Nameserver.
/sbin/ipfwadm -F -a accept -P tcp -S 0/0 \
-D 172.16.37.19 25 53
# DNS verwendet UDP und TCP, deshalb muß das auch
# freigegeben werden.
/sbin/ipfwadm -F -a accept -P udp -S 0/0 \
-D 172.16.37.19 53
# "Antworten" von gefährlichen Ports wie NFS und Larry
# McVoys NFS Erweiterung werden abgelehnt. Wer SQUID
# verwendet, sollte dessen Ports hier ebenfalls angeben.
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 53 \
-D 172.16.37.0/24 2049 2050
# Antworten an andere User Ports sind OK
/sbin/ipfwadm -F -a accept -P udp -S 0/0 53 \
-D 172.16.37.0/24 53 1024:65535
# Eingehende Verbindungen mit identd werden geblockt.
# Hier wird "reject" verwendet, damit dem anderen
# Rechner sofort mitgeteilt wird, das weitere Versuche
# sinnlos sind. Andernfalls würden Verzögerungen durch
# timeouts von ident auftreten.
/sbin/ipfwadm -F -a reject -o -P tcp -S 0/0 \
-D 172.16.37.0/24 113
# Einige Standard-Dienste werden für Verbindungen von
# den Netzwerken 192.168.64 und 192.168.65 akzeptiert;
# das sind Freunde, denen wir trauen.
/sbin/ipfwadm -F -a accept -P tcp -S 192.168.64.0/23 \
-D 172.16.37.0/24 20:23
# Alles von innerhalb des lokalen Netzes wird akzeptiert
# und weitergeleitet.
/sbin/ipfwadm -F -a accept -P tcp -S 172.16.37.0/24 -D 0/0
# Alle anderen eingehenden TCP Verbindungen werden
# verweigert und protokolliert. Falls FTP nicht
# funktioniert, hängen Sie ein 1:1023 an.
/sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 \
-D 172.16.37.0/24
# ... ebenfalls für UDP
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 \
-D 172.16.37.0/24
Gute Firewall Konfigurationen sind etwas trickreich. Dieses Beispiel
sollte einen brauchbaren Anfang liefern. Die Hilfeseite zu ipfwadm
gibt weitere Unterstützung bei der Konfiguration. Wenn Sie vorhaben,
einen Firewall einzurichten, erkundigen Sie sich auch bei
vertrauenswürdigen Bekannten und sammeln sie soviel Hinweise und
Ratschläge wie möglich. Suchen sie auch jemanden, der ein paar
Zuverlässigkeits- und Funktionstests von außerhalb durchführt.
Das IPX Protokoll wird hauptsächlich in lokalen Netzwerken unter Novell Netware(tm) verwendet. Linux unterstützt dieses Protokoll und kann als Endpunkt oder Router für IPX verwendet werden.
Optionen beim Kernel kompilieren:
Networking options --->
[*] The IPX protocol
[ ] Full internal IPX network
IPX Protokoll und NCPFS werden ausführlich im IPX HOWTO behandelt.
Da hat man nun gerade geglaubt, IP Netzwerke ansatzweise zu verstehen, und nun werden die Regeln geändert. IPv6 ist eine abgekürzte Form für die Version 6 des Internet Protokolls. IPv6 wurde vorrangig entwickelt, um den Befürchtungen der Internet Gemeinde entgegenzuwirken, daß es bald einen Engpaß bei den IP Adressen gäbe. IPv6 Adressen sind 16 Byte, also 128 Bit, lang. Außerdem enthält IPv6 einige weitere Änderungen, vorrangig Vereinfachungen, die ein IPv6 Netzwerk einfacher verwaltbar machen als ein IPv4 Netzwerk.
Die Kernels der Version 2.1.x enthalten bereits eine funktionierende, wenn auch noch unvollständige Implementation von IPv6.
Wenn Sie mit dieser neuen Generation der Internet Technologie experimentieren wollen, sollten Sie das IPv6 FAQ lesen. Es ist von
http://www.terra.net/ipv6
Das Integrated Services Digital Network (ISDN) hat in Deutschland vor allem als Ersatz für das alte analoge Telefonnetz eine recht große Verbreitung gefunden. Im Gegensatz zum alten Telefonnetz ist dieses vollständig digital ausgelegt. Auch hat man von Anfang an ISDN nicht nur zur Übermittlung von Sprache ausgelegt sondern auch für andere Dienste wie z.B. BTX, Fax oder Datenübertragung. Wie beim herkömmlichen Telefonnetz wird jeweils eine Punkt zu Punkt Verbindung zwischen zwei Teilnehmern aufgebaut.
Für die Datenübertragung ist ISDN vor allem wegen der Datenübertragungsrate von 64 kBit/s und der geringeren Störanfälligkeit interessant. Inzwischen hat das herkömmliche Telefonnetz allerdings durch die Digitalisierung der Vermittlungsstelle nachgezogenn und erlaubt jetzt auch mit Modems recht »hohe« Geschwindigkeiten.
Ein ISDN-Anschluß unterteilt sich in mehrere B-Kanäle und einen D-Kanal. Die B-Kanäle dienen der eigentlichen Datenübertragung. Pro Kanal werden 64 kBit/s übertragen. Der D-Kanal hat eine Geschwindigkeit von 16 kBit/s bzw. 64 kBit/s. Über ihn werden Kontrollinformationen z.B. für den Verbindungsaufbau übermittelt. Der Kunde kann zwischen verschiedenen ISDN-Anschlüssen wählen. Neben dem für Privatkunden üblichen Anschluß mit zwei B-Kanälen, gibt es noch Multiplexer Anschlüsse, die 30 B-Kanäle anhalten und damit immerhin eine Bandbreite von 2 MBit/s bieten.
Zu jedem Zeitpunkt können beliebig viele dieser Kanäle in jeder Kombination benutzt werden. So können z.B. zwei Verbindungen mit jeweils 64 kBit/s zu zwei anderen Teilnehmern aufgebaut werden. Es können aber auch beide Kanäle zusammengefaßt werden, so daß dann eine Verbindung mit 128 kBit/s zu einem anderen Teilnehmer aufgebaut werden kann. Natürlich können auch Kanäle unbenutzt bleiben, da ja für jeden Kanal jeweils Gebühren erhoben werden, wenn er benutzt wird.
Ein Kanal kann für eingehende oder ausgehende Verbindungen genutzt werden. Das ursprüngliche Ziel hinter ISDN war es, den Telekommunikationsgesellschaften die Möglichkeit zu geben, über eine einzelne Leitung sowohl Telefondienste als auch Datendienste anzubieten, ohne daß Änderungen in der Konfiguration notwendig werden.
Es gibt unterschiedliche Wege, einen Rechner an ISDN anzuschließen. Eine Möglichkeit stellt ein »Terminal Adapter« dar. Diese werden wie analoge Modems an die serielle Schnittstelle des Rechners angeschlossen. Die meisten dieser Geräte werden wie ein Modem per AT-Befehlssatz gesteuert und benötigen deshalb keinen speziellen Treiber. Eine andere Möglichkeit ist die Verwendung einer passiven oder aktiven ISA- oder PCI-Karte. Da hier der Rechner meistens einen Teil des ISDN-Protokolls generieren muß, benötigt Linux spezielle Treiber für jeden Kartentyp.
Optionen beim Kernel kompilieren:
ISDN subsystem --->
<*> ISDN support
[ ] Support synchronous PPP
[ ] Support audio via ISDN
< > ICN 2B and 4B support
< > PCBIT-D support
< > Teles/NICCY1016PC/Creatix support
Linux unterstützt eine Reihe unterschiedlicher ISDN Karten:
Weitere Details zur Konfiguration von ISDN unter Linux befinden sich im
Verzeichnis /usr/src/linux/Documentation/isdn, außerdem
existiert das isdn4linux FAQ, zu beziehen bei
http://www.lrz-muenchen.de/~ui161ab/www/isdn/Es gibt dort eine deutsche und eine englische Version. Außerdem gibt es noch eine deutsche ISDN HOWTO.
Ein Hinweis zu PPP: PPP ist generell für den Betrieb sowohl über
synchrone wie auch über asynchrone serielle Verbindungen ausgelegt. Der
normalerweise in Linux-Distributionen enthaltene Daemon pppd
unterstützt jedoch nur den asynchronen Modus. Wenn sie PPP über ihre
ISDN Verbindung benutzen wollen, benötigen sie eine speziell angepaßte
Version. Nähere Details dazu finden sie in den oben erwähnten Quellen.
Viele Personen setzen eine einfache Einwahlverbindung als Zugang zum Internet ein. Hierbei wird dem einwählenden Rechner praktisch immer genau eine einzige IP Adresse zugewiesen. Das ist normalerweise ausreichend, um einem einzelnen Rechner vollen Zugang zu den Möglichkeiten des Internet zu geben. Allerdings kann der Rechner nicht direkt als Router ins Internet für andere Rechner verwendet werden, da diese dann auch eine weltweit eindeutige IP Adresse benötigen würden. Nun könnte man ja prinzipiell den eigenen Provider bieten, mehr offizielle IP Adresse zur Verfügung zu stellen. Dem stehen jedoch zwei Gründen entgegen. Zum einen sind IP Adressen im Internet ein knappes Gut, zum anderen bieten die meisten Provider solche Leistung nur in Verbindung mit sehr teuren Verträgen für Firmen an.
IP Masquerade erlaubt es nun, dieses Problem zum umgehen, in dem
die anderen Rechner ebenfalls diese eine IP Adresse verwenden und
zum Provider deshalb als ein einziger Rechner erscheinen - deshalb der Name
»Maskerade«. Ein kleiner Nachteil dabei ist allerdings, daß dieses
Masquerading immer nur in eine Richtung funktioniert. D.h. der maskierte
Rechner kann zwar Verbindungen nach außen aufbauen, er kann aber keine
Anfragen/Verbindungen von außenliegenden Rechnern empfangen. Deshalb
funktionieren einige Dienste wie talk nicht, andere wie
z.B. FTP müssen speziell auf passiven Modus (PASV) konfiguriert
werden, damit sie funktionieren. Zum Glück sind aber Standard-Dienste
wie telnet, IRC und WWW davon nicht betroffen.
Optionen beim Kernel kompilieren:
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
Networking options --->
[*] Network firewalls
....
[*] TCP/IP networking
[*] IP: forwarding/gatewaying
....
[*] IP: masquerading (EXPERIMENTAL)
Auf dem Linux Rechner wird SLIP oder PPP ganz normal konfiguriert, wie für einen Einzelrechner. Außerdem besitzt der Rechner aber eine weitere Netzwerkschnittstelle, z.B. eine Ethernetkarte, über die er mit dem lokalen Netzwerk verbunden ist. An diesem Netz hängen auch die Rechner, die maskiert werden sollen. Jeder dieser anderen Rechner muß nun zunächst zu konfiguriert werden, daß er die IP Adresse des Linux Rechners als Gateway bzw. Router verwendet.
Eine typische Konfiguration sieht etwa so aus:
- -
\ | 192.168.1.0
\ | /255.255.255.0
\ --------- |
| | Linux | .1.1 |
NET =================| masq |------|
| PPP/slip | router| | --------
/ --------- |--| host |
/ | | |
/ | --------
- -
Die wichtigsten Konfigurationsbefehle in diesem Fall sind:
# Netzwerk Route für Ethernet
route add 192.168.1.0 netmask 255.255.255.0 eth0
# Default Route für den Rest des Internet
route add default ppp0
# Alle Hosts auf dem Netzwerk 192.168.1/24 werden maskiert
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
Weitere Informationen über IP Masquerade unter Linux enthält die IP Masquerade Resource Page:
http://www.hwy401.com/achau/ipmasq/
IP Transparent Proxy ermöglicht es, Anfragen für Server oder Dienste auf anderen Rechnern auf die lokale Maschine umzulenken. Dies ist z.B. sinnvoll, wenn ein Linux Rechner als Router und Proxy Server eingesetzt wird. In diesem Fall werden alle Anfragen nach nichtlokalen Diensten an den lokalen Proxy weitergeleitet.
Optionen beim Kernel kompilieren:
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
Networking options --->
[*] Network firewalls
....
[*] TCP/IP networking
....
[*] IP: firewalling
....
[*] IP: transparent proxy support (EXPERIMENTAL)
Die Konfiguration von IP Transparent Proxy wird mit Hilfe des Befehles
ipfwadm durchgeführt, zum Beispiel so:
# ipfwadm -I -a accept -D 0/0 80 -r 8080
Der Ausdruck »IP mobility« beschreibt die Fähigkeit eines Rechners, seine Verbindung zum Internet an unterschiedliche Punkte zu verlagern, ohne dabei seine IP Adresse zu ändern oder die Verbindung zu verlieren. Normalerweise ändert sich die IP Adresse eines Rechners, wenn er an einer anderen Stelle z.B. über ein anderen Netzwerk an das Internet angekoppelt wird. Mobile IP umgeht dieses Problem, indem dem Rechner eine feste IP Adresse zugeordnet wird und jeglicher Datenverkehr zu diesem Rechner durch IP Encapsulation (Tunneling) an die momentan tatsächlich genutzte IP Adresse umgeleitet wird.
In einem derzeit in Entwicklung befindlichen Projekt sollen alle notwendigen Programme für IP Mobility unter Linux zusammengetragen werden. Den gegenwärtigen Stand der Dinge erfahren Sie auf der Linux Mobile IP Home Page:
http://anchor.cs.binghamton.edu/~mobileip/
Mit IP Mulicast ist es möglich, Datenpakete gleichzeitig an beliebig viele Rechner in verschiedenen Segmenten von IP Netzwerken zu routen. Dieser Mechanismus wird ausgenutzt, um Internet-weite Verteilung von z.B. Audio- oder Videodaten zu ermöglichen.
Optionen beim Kernel kompilieren:
Networking options --->
[*] TCP/IP networking
....
[*] IP: multicasting
Ein paar spezielle Programme sowie einige kleinere Konfigurationsänderungen des Netzwerkes sind nötig, um diese Möglichkeiten auszunutzen. Weitere Informationen zu Installation und Konfiguration findet man z.B. bei
http://www.teksouth.com/linux/multicast/
Die NetRom Devices sind nr0, nr1 usw.
Optionen beim Kernel kompilieren:
Networking options --->
[*] Amateur Radio AX.25 Level 2
[*] Amateur Radio NET/ROM
Der Großteil der Arbeit bei der Implementation dieser Protokolle wurde
von Jonathon Naylor (jsn@cs.not.ac.uk) geleistet.
Die Namen der PLIP Devices sind plip0, plip1 usw. Das erste
Device erhält die Nummer 0, die weiteren werden fortlaufend
durchnumeriert.
Optionen beim Kernel kompilieren:
Networking options --->
<*> PLIP (parallel port) support
PLIP (Parallel Line IP) wird - wie SLIP - benutzt, um eine Point-to-Point Netzwerkverbindung zwischen zwei Rechnern herzustellen. Im Unterschied zu SLIP werden dazu jedoch die Parallelports der Rechner verwendet Da dabei mehr als ein Bit gleichzeitig übertragen werden kann, lassen sich mit PLIP höhere Datenübertragungsraten erreichen. Außerdem lassen sich selbst die einfachsten parallelen Anschlüsse, die Druckerports, verwenden.
Aber Vorsicht, manche Laptops verwenden Chipsätze, mit denen PLIP nicht verwendet werden kann: Sie lassen bestimmte Kombinationen von Signalen, die PLIP zum Funktionieren benötigt, nicht zu, da sie von Druckern nicht verwendet werden.
Die PLIP Schnittstelle von Linux ist kompatibel zum Crynwyr Packet Driver PLIP, d.h. man kann damit eine vollwertige TCP/IP Verbindung zwischen seinem Linux Rechner und einem DOS-Rechner aufbauen.
Bein Kompilieren des Kernels sollte man einen Blick in die Datei
/usr/src/linux/driver/net/CONFIG werfen. Sie enthält
Definitionen für den PLIP Timer in ms. Die Standardwerte sind zwar
meist einwandfrei, insbesondere bei langsamen Rechnern wird man sie aber unter
Umständen erhöhen müssen und zwar auf dem schnelleren Rechner.
Der Treiber geht von folgenden Einstellungen aus:
device i/o addr IRQ
------ -------- -----
plip0 0x3BC 5
plip1 0x378 7
plip2 0x278 2 (9)
Entspricht ihr Parallelports keiner dieser Möglichkeiten, können die
Werte mit dem Befehl ifconfig und der Option irq geändert
werden. Achten Sie auch darauf, daß die IRQs für den Parallelport im
BIOS aktiviert sind.
Zu Konfiguration des PLIP Interface müssen die folgenden Befehle in der
für das Netzwerk zuständigen rc-Datei hinzugefügt werden:
# Konfiguriere den ersten Parallelport als PLIP Device
/sbin/ifconfig plip0 IPA.IPA.IPA.IPA pointopoint \
IPR.IPR.IPR.IPR up
#
# Ende PLIP
Dabei ist
ihre IP Adresse;
die IP Adresse des anderen Rechners.
Der Parameter pointopoint hat dieselbe Bedeutung wie bei SLIP: Es
wird die Adresse des Rechners am anderen Ende der Verbindung angegeben.
Ansonsten kann man ein PLIP Interface genau wie ein SLIP Interface
behandelt, einzig dip oder slattach brauchen und können nicht
verwendet werden.
Wie ein für PLIP passendes Kabel auszusehen hat, wird in Abschnitt Kabel für die parallele Schnittstelle beschrieben. Obwohl man PLIP Verbindungen teilweise auch über lange Distanzen verwenden kann, sollten Sie das nach Möglichkeit vermeiden. Die Spezifikationen erlauben eine Kabellänge von etwa einem Meter. Wenn Sie dennoch längere Kabel verwenden wollen, achten Sie besonders auf elektromagnetische Störeinstreuungen (Blitz, andere Stromkabel, Radiosender), da auch dadurch eine Beeinträchtigung der Verbindung bis hin zur Beschädigung des Controllers möglich ist. Wenn sie wirklich eine Verbindung über größere Distanzen herstellen wollen oder müssen, kaufen Sie lieber zwei billige Ethernet-Karten und ein Koaxial-Kabel
Die Namen der PPP Devices sind ppp0, ppp1 usw. Die Devices
werden fortlaufend durchnumeriert, beginnend mit 0 für das erste
konfigurierte Device.
Optionen beim Kernel kompilieren:
Networking options --->
<*> PPP (point-to-point) support
Die Konfiguration von PPP wird im PPP HOWTO beschrieben.
Falls Sie sich in der glücklichen Lage befinden, eine mehr oder weniger dauerhafte Netzanbindung zu haben, gibt es eine sehr einfache Möglichkeit, daß der Rechner automatisch eine neue PPP Verbindung aufbaut, wenn diese zusammenbrechen sollte.
Dabei muß PPP derart konfiguriert werden, daß von root
durch einen einfachen Befehl gestartet werden kann:
# pppd
/etc/ppp/options
die Option -detach eingetragen haben. Dann fügen sie die folgende
Zeile bei den getty-Definitionen in die Datei /etc/inittab
ein:
pd:23:respawn:/usr/sbin/pppd
pppd laufend von init überwacht und
im Falle eines Verbindungsabbruches automatisch neu gestartet.
Die Namen der Rose Devices sind rs0, rs1 usw. Rose wird nur in
den Entwickler-Kernels 2.1.x unterstützt.
Optionen beim Kernel kompilieren:
Networking options --->
[*] Amateur Radio AX.25 Level 2
<*> Amateur Radio X.25 PLP (Rose)
Der Großteil der Arbeit bei der Implementation dieser Protokolle wurde
von Jonathon Naylor (jsn@cs.not.ac.uk) geleistet.
SAMBA ist eine Implementation des Session Management Block Protokolles. Mit SAMBA ist es möglich, daß Systeme, die Betriebssysteme von Microsoft wie z.B. Windows verwenden, die Platten des Linux-Rechners mounten und dessen Drucker verwenden können.
SAMBA und seine Konfiguration werden ausführlich im Linux Samba HOWTO beschrieben.
Die Namen der SLIP Devices sind sl0, sl1 usw. Das erste
konfigurierte Device erhält die Nummer 0, weitere werden
fortlaufend durchnumeriert.
Optionen beim Kernel kompilieren:
Network device support --->
[*] Network device support
<*> SLIP (serial line) support
[ ] CSLIP compressed headers
[ ] Keepalive and linefill
[ ] Six bit SLIP encapsulation
SLIP (Serial Line IP) ermöglicht TCP/IP Verbindungen über serielle Leitungen wie Telefonleitungen (mit Modem) oder gemietete Standleitungen. Um es zu benutzen, benötigt man einen SLIP-Server möglichst in der näheren Umgebung. Viele Universitäten und einige Firmen bieten einen solchen Service an.
SLIP verwendet die serielle Schnittstelle des Rechners, um Datenpakete
zu versenden. Dafür muß man diese Schnittstelle kontrollieren können.
Wie sind die SLIP-Namen den seriellen Schnittstellen zugeordnet? Der
Netzwerk Code verwendet einen ioctl() (I/O Control) Aufruf, um die
serielle Schnittstelle in ein SLIP-Device »umzuschalten«.
Es gibt zwei Programme, die diese Aufgabe übernehmen: dip
und slattach.
dip (Dialup IP) ist ein intelligentes Programm, das die
Übertragungsgeschwindigkeit der seriellen Schnittstelle einstellen kann,
das Modem zum Wählen veranlaßt, automatisch die eingehenden
Meldungen der Gegenstelle nach den notwendigen Informationen wie der
IP-Adresse durchsucht und die notwendigen ioctl() Aufrufe ausführt,
um die Schnittstelle in den SLIP Modus zu schalten. dip
unterstützt eine umfangreiche Script-Sprache und kann dadurch den
gesamten Login-Prozeß automatisieren.
Die Bezugsquelle ist
metalab.unc.edu:/pub/Linux/system/Network/serial/dip/Zur Installation gehen Sie wie folgt vor; zuerst wird das Paket entpackt:
# cd /usr/src
# gzip -dc dip337o-uri.tgz | tar xvf -
# cd dip-3.3.7o
# make
# make install
Das Makefile nimmt die Existenz einer Gruppe uucp an, dies kann
aber leicht z.B. in dip oder SLIP umgeändert werden.
Im Gegensatz zu dip ist slattach ein extrem einfaches
Programm. Es ist einfach zu benutzen, bietet aber nicht den Komfort
oder die Script-Fähigkeit von dip. Alles was es macht, ist, die
serielle Schnittstelle als SLIP Device zu konfigurieren. Dabei setzt es
voraus, daß Sie alle notwendigen Informationen besitzen, und daß die
Verbindung bereits aufgebaut ist, wenn es gestartet wird. slattach
ist optimal geeignet, wenn sie eine dauerhafte Verbindung zu ihrem
Server haben.
dip bietet sich an, wenn die Verbindung zum SLIP Server über ein
Modem oder eine andere temporäre Leitung aufgebaut wird. slattach
ist eher für feste Verbindungen, ein fest installiertes Kabel etwa, oder
eine gemietete Leitung geeignet. Für Fälle also, in denen keine
besonderen Aktionen notwendig sind, um die Verbindung aufzubauen. Für
weitere Informationen finden sich in dem Abschnitt
Dauerhafte SLIP Verbindungen.
Die Konfiguration von SLIP ist bis auf ein paar kleine Ausnahmen sehr ähnlich zur Konfiguration eines Ethernet Device.
Zunächst unterscheiden sich SLIP Verbindungen von Ethernet Netzwerken dadurch, daß an einem SLIP-»Netzwerk« immer nur zwei Rechner beteiligt sind. Außerdem sind bei SLIP Verbindungen oft zusätzliche Maßnahmen notwendig, um die Netzverbindung zu aktivieren, wohingegen bei einer Ethernet Netzwerk die Verbindung bereits mit dem Einstecken der Kabel besteht.
Wenn Sie dip verwenden, wird der Verbindungsaufbau normalerweise
nicht bereits beim Booten vorgenommen sondern erst zu einem späteren
Zeitpunkt, wenn eine Netzverbindung benötigt wird. Es ist auch dann
möglich, diesen Vorgang zu automatisieren. Falls Sie slattach
verwenden, werden Sie vermutlich lieber einen speziellen Abschnitt in der
Datei rc.inet1 einfügen wollen. Dies wird etwas später
beschrieben.
Es gibt zwei unterschiedliche Arten von SLIP Servern: Solche, die die
Adressen dynamisch vergeben, und solche, die statische Adressen
verwenden. Praktisch jeder SLIP Server wird sie beim Login auffordern,
ihren Benutzernamen sowie ihr Paßwort einzugeben. dip kann diese
Loginprozedur übernehmen und automatisch durchführen.
Bei einem statischen SLIP Server bekommen Sie eine IP Adresse für ihre
alleinige Verwendung zugewiesen. Bei jedem Verbindungsaufbau zum Server
bekommen Sie also diese feste Adresse. Der statische SLIP Server wird
also ihren Modem-Anruf entgegennehmen, die normale Login-Prozedur
durchführen und dann alle Datagramme an ihre IP Adresse über diese
Leitung routen. Wenn Sie Zugang zu einem solchen statischen Server
haben, sollten Sie einen festen Eintrag mit ihrem Rechnernamen und der
IP Adresse in der Datei /etc/hosts einfügen. Auch in den
folgenden Dateien sollten Sie entsprechende Konfigurationsänderungen
vornehmen:
rc.inet2, host.conf, resolv.conf,
etc/HOSTNAME sowie rc.local. Denken Sie auch daran,
daß bei der Konfiguration von rc.inet1 keine besonderen Befehle
zur Konfiguration der SLIP Verbindung benötigt werden, dies wird zur
gegebenen Zeit von dip erledigt. Dazu müssen ihm lediglich die
notwendigen Informationen mitgeteilt werden, dann wird die Konfiguration
automatisch durchgeführt, nachdem die Einwählprozedur beendet ist.
Falls Ihr SLIP Server statische Adressen verwendet, können Sie den folgenden Abschnitt überspringen und gleich den Abschnitt Benutzung von dip lesen.
Ein dynamischer SLIP Server vergibt die IP Adressen zufällig aus einem Pool von vorhandenen Adressen. Es gibt also keine Garantie, daß man bei jeder Verbindung eine bestimmte IP Adresse zugewiesen bekommt. Die von Ihnen bei einer Sitzung verwendete Adresse kann, nachdem Sie die Verbindung beendet haben, von einem anderen Benutzer verwendet werden. Der Administrator des SLIP Servers hat für diesen Zweck einen Pool von IP Adressen reserviert, und bei einem Verbindungsaufbau bekommen Sie die erste freie Adresse zugewiesen. Diese wird dem Anrufer nach dem Verbindungsaufbau übermittelt und ist für ihn für die Dauer der Verbindung reserviert.
Die Konfiguration verläuft hier recht ähnlich wie im Falle von statischen SLIP Servern, allerdings muß in einem zusätzlichen Schritt die zugewiesene IP Adresse ermittelt werden, um das SLIP Device entsprechend zu konfigurieren.
Auch in diesem Fall übernimmt dip den schwierigen Teil. Die neueren
Versionen sind intelligent genug, um nicht nur den Verbindungsaufbau
durchzuführen, sondern auch automatisch die übermittelte IP Adresse zu
erkennen und damit das SLIP Device zu konfigurieren.
Wie bereits erwähnt, handelt es sich bei dip um ein mächtiges
Programm, welches den aufwendigen Prozeß des Einwählens in einen SLIP
Server, die Loginprozedur sowie die Konfiguration des SLIP Device
vereinfachen und automatisieren kann.
Um dip zu verwenden, benutzt man im Allgemeinen ein dip-Script,
das eigentlich nur aus einer Liste von Kommandos besteht, die dip
versteht, und die ihm mitteilen, wie die notwendigen Aktionen
durchgeführt werden sollen. Die Datei sample.dip, die Bestandteil
des Paketes ist, vermittelt einen ersten Eindruck, wie das vor sich
geht. dip ist ein Programm mit vielen Optionen. Sie alle hier
aufzulisten, wäre müßig. Lesen Sie dazu bitte die Online Hilfe, die
Beispieldatei sowie die Datei README des dip-Paketes.
Sie werden feststellen, daß die Beispieldatei sample.dip von einem
statischen SLIP Server ausgeht, die verwendete IP Adresse also bereits
bekannt sein muß. Für dynamische SLIP Server gibt es in den neueren
Versionen von dip ein spezielles Kommando, mit dem man automatisch
die IP Adresse aus den Antworten des Servers extrahieren kann, um damit
dann das SLIP Device zu konfigurieren. Das folgende Script ist eine
veränderte Version der Datei sample.dip, die mit der Version
dip337j-uri.tgz ausgeliefert wird. Sie stellt vermutlich einen
ausreichenden Startpunkt für alle dar, die einen dynamischen SLIP Server
verwenden. Speichern Sie es unter dem Namen /etc/dipscript und
verändern Sie es entsprechend ihrer eigenen Konfiguration:
#
# sample.dip Programm für Dialup IP Verbindung
#
# Dieses Datei zeigt, wie DIP verwendet wird.
#
# Für dynamische Server vom Typ Annex sollte diese
# Datei funktionieren. Falls Sie einen statischen
# Server mit statischen Adressen verwenden,
# benutzen Sie die Datei sample.dip, die als Teil
# des dip337-uri.tgz Paketes ausgeliefert wird.
#
#
# Version: @(#)sample.dip 1.40 07/20/93
#
# Autor: Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG>
#
main:
# Lege Namen und Adresse des Servers fest.
# Mein Server heißt "xs4all.hacktic.nl" (== 193.78.33.42).
get $remote xs4all.hacktic.nl
# Setze die Netzmaske fuer sl0 auf 255.255.255.0.
netmask 255.255.255.0
# Lege die verwendete serielle Schnittstelle und die
# Geschwindigkeit fest.
port cua02
speed 38400
# Reset für das Modem und die Terminal Verbindung.
# Das verursacht bei manchen Anwendern Probleme!
reset
# Hinweis: Standardmäßig vordefinierte "errlevel"
# Werte sind:
# 0 - OK
# 1 - CONNECT
# 2 - ERROR
#
# Man kann sie ändern. Suchen Sie (mit grep) nach
# "addchat()" in *.c
# Vorbereitung zum Wählen
send ATQ0V1E1X4\r
wait OK 2
if $errlvl != 0 goto modem_trouble
dial 555-1234567
if $errlvl != 1 goto modem_trouble
# Die Verbindung wurde aufgebaut, jetzt der Login
login:
sleep 2
wait ogin: 20
if $errlvl != 0 goto login_trouble
send MYLOGIN\n
wait ord: 20
if $errlvl != 0 goto password_error
send MYPASSWD\n
loggedin:
# Login erfolgreich
wait SOMEPROMPT 30
if $errlvl != 0 goto prompt_error
# Setze den Server in den SLIP Mous
send SLIP\n
wait SLIP 30
if $errlvl != 0 goto prompt_error
# Ermitteln der vom Server zugewiesenen IP Adresse
# Dabei wird vorausgesetzt, daß der Server diese
# Adresse nach dem Umschalten in den SLIP Modus
# ausgibt.
get $locip remote 30
if $errlvl != 0 goto prompt_error
# Setzen der Arbeitsparameter fuer SLIP
get $mtu 296
# Dies stellt sicher, daß ein
# "route add -net default xs4all.hacktic.nl"
# durchgeführt wird.
default
# Wir sind da! Starte SLIP
done:
print CONNECTED $locip ---> $rmtip
mode CSLIP
goto exit
prompt_error:
print TIME-OUT beim Starten von sliplogin...
goto error
login_trouble:
print Probleme beim Warten auf den Login: Prompt...
goto error
password:error:
print Probleme beim Warten auf den Password: Prompt...
goto error
modem_trouble:
print Probleme mit dem Modem
error:
print CONNECT mit $remote gescheitert!
quit
exit:
exit
Dieses Script geht von einer dynamischen SLIP Verbindung aus. Für
statische SLIP Server verwenden Sie bitte die Datei sample.dip aus
dem Paket dip337j-uri.tgz.
Wenn dip den Befehl get $local erhält, durchsucht
es sämtlichen eingehenden Text von der anderen Seite auf eine
Zeichenkette, die wie eine IP Adresse aussieht, also Zahlen, die durch
Punkte getrennt sind. Diese Veränderung wurde eingeführt, damit der
Verbindungsaufbau auch für dynamische SLIP Server automatisiert werden
kann.
Das obige Beispiel konfiguriert automatisch einen Default Route Eintrag
über das SLIP Device. Entspricht das nicht ihren Wünschen, z.B. weil
Sie außerdem noch eine Ethernet Verbindung haben, die ihre Default
Route darstellt, entfernen Sie die Zeile default aus dem Script.
Nachdem das Script beendet ist, können Sie mit dem Befehl ifconfig
verifizieren, daß ein Device sl0 existiert. Dieses Device können
Sie dann mit den üblichen ifconfig und route Befehlen Ihren
Wünschen entsprechend konfigurieren.
Beachten Sie auch, daß sie mit dip mittels des mode Befehles
unterschiedliche Protokolle nutzen können. Das am häufigsten verwendete
ist wohl CSLIP für SLIP mit Komprimierung. Eine solche Einstellung
muß aber auf beiden Seiten identisch sein, verwenden Sie also die
Einstellung ihres Servers.
Das Beispiel ist recht robust und sollte die meisten Fehler abfangen. Bei
weiteren Fragen informieren Sie sich bitte über die Online Hilfe zu
dip. Selbstverständlich kann ein solches Script auch derart
erweitert werden, daß bei einem gescheiterten Einwahlversuch erneut
gewählt wird, oder sogar eine andere Nummer angerufen wird.
Wenn sie zwei Rechner direkt über ein Kabel miteinander verbinden, oder
in der glücklichen Lage sind, über eine gemietete Standleitung mit dem
Internet verbunden zu sein, können Sie sich die aufwendige Prozedur mit
dip ersparen. slattach ist ein extrem einfach zu benutzendes
Programm, das gerade genug Funktionalität bietet, um die Verbindung
richtig zu konfigurieren.
Da es sich um eine dauernde Verbindung handelt, ist der einfachste Weg,
die Befehle zur Konfiguration in der Datei rc.inet1 einzubauen. Im
Prinzip besteht diese Konfiguration lediglich darin, sicherzustellen,
daß die serielle Schnittstelle mit der korrekten Geschwindigkeit
betrieben und in den SLIP Modus umgeschaltet wird. Mit slattach
erreichen sie dies mit einem einzigen Befehl. Fügen Sie einfach
folgende Zeilen in ihr rc.inet1 ein:
#
# Aufbau einer dauerhaften statischen SLIP Verbindung
#
# Konfiguriere /dev/cua0 für 19.2kbps und CSLIP
/sbin/slattach -p cslip -s 19200 /dev/cua0 &
/sbin/ifconfig sl0 IPA.IPA.IPA.IPA pointopoint \
IPR.IPR.IPR.IPR up
# Ende statisches SLIP.
Hierbei ist:
Ihre IP Adresse;
die IP Adresse des anderen Rechners.
slattach weist dem angegebenen seriellen Device das erste freie
SLIP Device zu, beginnend mit sl0. Der erste Aufruf von
slattach konfiguriert also das Device sl0, ein weiterer Aufruf
sl1 usw.
Mit slattach können mittels der Option -p eine Reihe von
Protokollen eingestellt werden. Im Normalfall sind das meist SLIP oder
CSLIP, je nachdem ob Komprimierung verwendet werden soll oder nicht. In
jedem Fall muß aber auf beiden Seiten dieselbe Einstellung verwendet
werden.
Wenn Sie einen Rechner mit Netzwerkzugang besitzen, über den Sie anderen
Nutzern die Einwahl in das Netz ermöglichen wollen, müssen Sie diesen
Rechner als Server konfigurieren. Wenn Sie für die Verbindung als
serielles Protokoll SLIP verwenden wollen, haben Sie drei Möglichkeiten
unterschiedliche Möglichkeiten für diese Konfiguration. Ich würde den
ersten Vorschlag, sliplogin, bevorzugen, da er am einfachsten zu
realisieren und zu verstehen ist. Aber treffen Sie ihre eigene
Entscheidung.
sliplogin können Sie anstelle der normalen Login-Shell für Nutzer
verwenden, die sich in ihren Rechner einwählen. Das Programm schaltet
automatisch die serielle Verbindung in den SLIP Modus und bietet
Unterstützung sowohl für statische als auch für dynamische IP
Adressenvergabe.
Der Benutzer führt einen normalen Login-Prozeß durch, also Eingabe von
Benutzerkennung und Paßwort. Aber statt dann eine Shell vorgesetzt zu
bekommen, wird sliplogin gestartet, das in der Datei
/etc/slip.hosts nach einem Eintrag für den anrufenden Benutzer
sucht. Wird dieser gefunden, wird die Verbindung als 8 Bit clean
konfiguriert und über einen ioctl Aufruf in den SLIP Modus
geschaltet. Danach startet sliplogin als letzten Schritt ein
Script, in dem das SLIP Device mit den entsprechenden Parametern (IP
Adresse, Netmask, Routing) konfiguriert wird. Dieses Script heißt
üblicherweise /etc/slip.login, aber wie auch bei getty
können Sie für Benutzer, die einer besonderen Behandlung bedürfen,
eigene Scripts unter dem Namen /etc/slip.login.loginname
anlegen, die dann anstelle des Standardscriptes gestartet werden.
Es gibt drei bzw. vier Dateien, die konfiguriert werden müssen, damit
sliplogin richtig funktioniert:
Enthält die Accounts der Benutzer.
Hier stehen die für jeden Nutzer spezifischen Informationen für SLIP.
Dieses Script regelt die Routing Konfiguration für die Nutzer.
Diese Datei wird nur bei der Verwendung von dynamischer Adressvergabe benötigt und enthält eine Tabelle mit benutzbaren Adressen.
Hier stehen die Kommandos, um die Verbindung bei einem Logout oder bei Fehlern korrekt zu beenden.
Eventuell ist sliplogin bereits Bestandteil ihrer
Linux-Distribution. Wenn dieses nicht der Fall ist, bekommt man es von
metalab.unc.edu:/pub/linux/system/Network/serial/Um sicherzustellen, daß nur autorisierte Nutzer sliplogin benutzen
können, sollten Sie in der Datei /etc/group einen Eintrag wie
diesen hier vorsehen:
slip::13:radio,fred
Bei der Installation von sliplogin wird das Makefile die
Eigentumsrechte für sliplogin auf die Gruppe slip
setzen. Dadurch können nur Nutzer, die in dieser Gruppe sind, das
Programm ausführen. Im oben angeführten Beispiel wären das die Nutzer
radio und fred.
Um die Programme im Verzeichnis /sbin und die manual pages in der
Sektion 8 zu installieren, gehen Sie folgendermaßen vor. Zuerst wird
das Paket entpackt:
# cd /usr/src
# gzip -dc .../sliplogin-2.1.1.tar.gz | tar xvf -
# cd sliplogin-2.1.1
# make install
Falls Sie die Programme vor der Installation selber neu übersetzen
wollen, fügen Sie vor dem make install noch ein make clean
ein. Sollen die Programme in eine anderes Verzeichnis installiert
werden, müssen Sie im Makefile die Regel install entsprechend
editieren.
Lesen Sie bitte auch die Datei README, die zum Paket gehört.
Normalerweise richtet für jeden Benutzer von SLIP einen
speziellen Account in /etc/passwd ein. Eine Konvention hierbei
ist es, als Benutzernamen ein großes S, gefolgt vom Namen des
einwählenden Rechners, zu verwenden. Ein Rechner mit dem Namen
radio bekommt also folgenden Eintrag:
Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin
Diese Konvention ist allerdings nicht zwingend. Sie können jeden beliebigen Namen verwenden, der ihnen aussagekräftig genug erscheint.
Hinweis: Der Anrufer benötigt kein besonderes Heimatverzeichnis, da er
von diesem Rechner niemals eine Shell zu Gesicht bekommen wird.
/tmp ist deshalb eine gute Wahl für diesen Zweck. Beachten Sie
auch den Eintrag /sbin/sliplogin als Login-Shell.
In der Datei /etc/slip.hosts sucht sliplogin nach
Einträgen, die dem Namen des Anrufers entsprechen. In dieser Datei
werden IP Adresse und Netmask festgelegt, die dem Anrufer zugewiesen
werden. Das folgende Beispiel enthält Einträge für zwei Rechner,
radio und albert, wobei letzterem die IP Adresse dynamisch
zugewiesen wird:
#
Sradio 44.136.8.99 44.136.8.100 255.255.255.0 normal -1
Salbert 44.136.8.99 DYNAMIC 255.255.255.0 compressed 60
#
Die einzelnen Einträge sind:
DYNAMIC, wird die IP Adresse basierend auf den
Informationen in der Datei /etc/slip.tty
bestimmt. Aber Vorsicht, das funktioniert erst ab Version 1.3 von
sliplogin.In den Feldern 2 und 3 können sowohl Rechnernamen als auch IP
Adressen in Dezimalpunktschreibweise stehen. Wenn Sie Rechnernamen
verwenden, müssen diese allerdings auflösbar sein, d.h. der Server muß
in der Lage sein, die zu dem Namen gehörende IP Adresse herauszufinden.
Überprüfen können Sie dies z.B. durch ein telnet auf diesen
Rechnernamen. Bekommen Sie dann die Meldung Trying nnn.nnn.nnn...,
hat ihr Rechner den Namen einwandfrei aufgelöst. Bekommen Sie hingegen
die Meldung Unknown host, ist der Versuch fehlgeschlagen. Dann
verwenden Sie entweder direkt die IP Adresse, oder stellen Sie ihr Name
Resolving so ein, daß der Name gefunden wird. Wie das geht, wird im
Abschnitt
Konfiguration des Name Resolvers erläutert.
Die am häufigsten verwendeten Einstellungen für den SLIP Modus sind
Für normales, unkomprimiertes SLIP.
Um van Jacobsen Header Kompression (cSLIP) zu aktivieren.
Die beiden Optionen schließen sich natürlich wechselseitig aus. Für weitere Informationen lesen Sie bitte die Online-Hilfe.
Hat sliplogin einen passenden Eintrag in /etc/slip.hosts
gefunden, wird es als nächstes versuchen, das Script
/etc/slip.login zu starten, um das SLIP Interface mit den
notwendigen Parametern IP Adresse und Netmask zu konfigurieren.
Die mit dem Paket gelieferte Beispieldatei sieht folgendermaßen aus:
#!/bin/sh -
#
# @(#)slip.login 5.1 (Berkeley) 7/1/90
#
# Generische login Datei für eine SLIP Verbindung.
# sliplogin ruft das Script mit folgenden Parametern auf:
# $1 $2 $3 $4, $5, $6 ...
# SLIPunit ttyspeed pid die Argumente aus
# dem Eintrag in slip.host
#
/sbin/ifconfig $1 $5 pointopoint $6 mtu 1500 -trailers up
/sbin/route add $6
arp -s $6 <hw_addr> pub
exit 0
#
Sie werden feststellen, daß dieses Script ganz einfach nur die Befehle
ifconfig und route verwendet, um das SLIP Device zu
konfigurieren, genau wie das auch bei der Verwendung von slattach
der Fall wäre.
Beachten Sie auch die Verwendung von Proxy ARP. Damit wird sichergestellt, daß andere Rechner, die am selben Ethernet Netzwerk wie der Server angeschlossen sind, den einwählenden Rechner erreichen können. Ist ihr Server nicht an ein Ethernet Netz angeschlossen, können Sie diese letzte Zeile ganz auslassen.
Falls die Verbindung zusammenbricht, sollten Sie sicherstellen, daß die
serielle Schnittstelle in ihren Normalzustand zurückversetzt wird, damit
der nächste Anrufer sich ganz normal einloggen kann. Dieses erreichen Sie
mit dem Script /etc/slip.logout. Es hat ein sehr einfaches
Format und wird mit denselben Parametern wie /etc/slip.login
aufgerufen, auch wenn davon nur ein paar verwendet werden.
#!/bin/sh -
#
# slip.logout
#
/sbin/ifconfig $1 down
arp -d $6
exit 0
#
Alles was es macht, ist das Interface herunterzufahren, wodurch
automatisch auch die vorher angelegte Route gelöscht wird. Den hier
ebenfalls enthaltenen arp Aufruf können Sie auch wieder löschen,
falls Sie nicht an ein Ethernet Netzwerk angeschlossen sind.
Falls Sie dynamische IP Adressen verwenden, also mindestens einen der
Rechner mit dem Eintrag DYNAMIC konfiguriert haben, dann müssen
Sie auch die Datei /etc/slip.tty konfigurieren, indem Sie dort
alle zur Auswahl stehenden Adressen auflisten. Sie benötigen diese
Datei aber nur für die dynamische Vergabe von IP Adressen.
Die Datei ist eine Tabelle, die die tty-Devices auflistet, über die
SLIP Verbindungen eingehen können, und die IP Adresse, die einem Anrufer
auf dem jeweiligen Port zugewiesen wird:
# slip.tty tty -> IP Adressenzuweisung für
# dynamisches SLIP
# Format: /dev/tty?? xxx.xxx.xxx.xxx
#
/dev/ttyS0 192.168.0.100
/dev/ttyS1 192.168.0.101
#
Das vorstehende Beispiel legt also fest, daß all denjenigen Anrufern, die
sich über den Port /dev/ttyS0 einwählen und in dem
entsprechenden Feld in der Datei /etc/slip.hosts den Eintrag
DYNAMIC haben, die IP Adresse 192.168.0.100 zugewiesen
bekommen.
Dadurch benötigt man nur eine Adresse je zur Verfügung stehenden Port und kann so die Anzahl der belegten Adressen klein halten.
Zu Beginn ein Hinweis: Einige der in diesem Abschnitt gegebenen
Informationen entstammen der manual page von dip, in der ebenfalls
eine kurze Anleitung gegeben wird, wie Linux als SLIP Server
konfiguriert werden kann. Alle Angaben hier beziehen sich auf die
Version dip337o-uri.tgz und gelten nicht automatisch für andere
Versionen dieses Paketes.
dip hat einen speziellen Eingabemodus, in dem es für denjenigen,
der es gestartet hat, automatisch alle notwendigen Informationen aus der
Datei /etc/diphosts zusammensucht, um die serielle Verbindung
zu konfigurieren und in den SLIP Modus zu schalten. Dieser besondere
Modus wird aktiviert, wenn das Programm unter dem Namen diplogin
gestartet wird. Um dip auf eine Server zu verwenden, müssen Sie
also lediglich besondere Accounts einrichten, die diplogin als
Login-Shell verwenden.
Dafür muß zunächst ein symbolischer Link angelegt werden:
# ln -sf /usr/sbin/dip /usr/sbin/diplogin
/etc/passwd und
/etc/diphosts vorgenommen werden.
Für jeden Benutzer wird - wie auch bei sliplogin - ein Account
angelegt. Konvention ist auch hier, den Nutzernamen mit einem großen S
zu beginnen. Das sieht dann etwa so aus:
Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin
^^ ^^ ^^ ^^ ^^ ^^ ^^
| | | | | | \__ diplogin als Login Shell
| | | | | \_______ Heimatverzeichnis
| | | | \____________ Voller Nutzername
| | | \_________________ User Group ID
| | \_____________________ User ID
| \_______________________________ Verschlüsseltes Passwort
\__________________________________________ Slip User Login Name
Der Login wird wie gewöhnlich vom Programm login(1)
abgewickelt. Ist alles in Ordnung, wird das Programm diplogin
gestartet. dip, mit dem Namen diplogin aufgerufen, weiß dann
automatisch, daß es als Login-Shell benutzt wird. Als erstes ruft es
dann die Funktion getuid() auf, um die Benutzer ID desjenigen
herauszufinden, der das Programm gestartet hat. Danach sucht es in der
Datei /etc/diphosts nach dem ersten Eintrag, der entweder der
Benutzer-ID oder aber dem Namen des tty entspricht, über den die
Verbindung aufgebaut wurde, und führt dementsprechend die Konfiguration
durch. Durch die Entscheidung, einem Nutzer entweder einen Eintrag für
seine ID zuzuweisen, oder die Standardeinstellung für das tty zu
verwenden, können einfach statische und dynamische Adressen parallel
verwendet werden.
dip fügt in diesem Modus automatisch einen Eintrag für Proxy-ARP
durch, dies muß also nicht von Hand geschehen.
Die Datei /etc/diphosts wird von dip verwendet, um
voreingestellte Konfigurationen für unterschiedliche Rechner zu
speichern. Dabei kann es sich um Rechner handeln, die sich in ihren
Rechner einwählen, aber auch um solche, in die Sie sich mit ihrem
Rechner einwählen.
Das allgemeine Format der Einträge in /etc/diphosts sieht so
aus:
Suwalt::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
ttyS1::145.71.34.3:145.71.34.2:255.255.255.0:Dynamic ttyS1:CSLIP,296
Die einzelnen Einträge bedeuten:
getpwuid(getuid()) zurückgeliefert
wird, oder Name des tty.passwd.Der untere der beiden Beispieleinträge legt also z.B. fest, daß ein
Anrufer auf ttyS1 die (dynamische) Adresse 145.71.34.3
zugewiesen bekommt und die Verbindung mit Komprimierung (CSLIP) und
einer MTU von 296 konfiguriert wird.
Alle Nutzer, die eine statische IP Adresse zugewiesen bekommen
sollen, müssen einen Eintrag unter ihrem Login-Namen in
/etc/diphosts haben. Für andere Anrufer, denen die IP Adresse
dynamisch zugewiesen werden soll, muß ein Eintrag für die in Frage
kommenden tty Ports vorhanden sein. Es sollte auf jeden Fall für
jeden vorhandenen Port ein Eintrag vorhanden sein, um sicherzustellen,
daß ein Anrufer in jedem Fall eine gültige Konfiguration vorfindet.
Wenn sich nun ein Benutzer einlogged, wird er ganz normal nach Name und
Paßwort gefragt. Hier muß er seinen SLIP Login-Namen und das zugehörige
Paßwort eingeben. Verläuft alles normal, wird der Benutzer keinerlei
zusätzliche Meldungen bekommen, er sollte dann einfach die Verbindung in
den SLIP Modus schalten, dann sollte er eine Verbindung mit den
Parametern aus diphosts aufbauen können.
Matt Dillon (dillon@apollo.west.oic.com) hat ein Paket von kleinen
Programmen und Shell-Scripts geschrieben, mit denen SLIP sowohl im
Dial-in wie im Dial-out betrieben werden kann. Allerdings muß die Shell
tcsh installiert sein, da mindestens eines der Scripts auf
deren Syntax angewiesen ist. Jedoch ist dies keine große Einschränkung,
da die tcsh bei den meisten Distributionen mitgeliefert wird.
Außerdem gehört zu Matts Paket auch eine ausführbare Kopie des
Programmes expect, das ebenfalls an einigen Stellen benötigt
wird. Es ist von Vorteil, wenn man sich mit expect bereits
auskennt, da andernfalls bei der Konfiguration leicht Fehler gemacht
werden können. Aus diesem Grunde empfiehlt sich das Paket mehr für die
bereits mit Unix Vertrauten, man sollte sich aber trotzdem nicht davon
abhalten lassen, sich das Programm einmal anzusehen, zumal Matt eine
sehr gute Installationsanleitung im README gibt.
Das dSLIP Paket bekommt man von:
Wichtig ist, die Datei README aufmerksam zu lesen und vor allem die
dort angegebenen Einträge in den Dateien /etc/passwd und
/etc/group einzufügen, bevor ein make
install ausgeführt wird.
Optionen beim Kernel kompilieren:
Network device support --->
[*] Network device support
....
[*] Radio network interfaces
< > STRIP (Metricom starmode radio IP)
Das STRIP Protokoll wurde speziell für eine besondere Art von Funk-Modems entwickelt, die in einem Forschungsprojekt der Universität Stanford mit dem Namen MosquitoNet Project verwendet werden:
http://mosquitonet.Stanford.EDU/mosquitonet.htmlSie finden dort eine Menge interessanter Informationen - selbst wenn Sie nicht an dem Projekt selber interessiert sind.
Die Metricom Sender werden an die serielle Schnittstelle angeschlossen, verwenden verteilte Wellenlängenbereiche und können typischerweise etwa 100kbps übertragen. Informationen über diese Sender finden sie auf dem Metricom Web Server:
http://www.metricom.comDie normalen Netzwerkprogramme unterstützen dieses Protokoll derzeit nicht, sie müssen sich also speziell angepaßte Versionen vom MosquitoNet Webserver beschaffen. Genauere Informationen, welche Software Sie benötigen, finden sie auf der MosquitoNet STRIP Page:
http://mosquitonet.Stanford.EDU/strip.htmlEine kurze Zusammenfassung der Konfiguration: Sie verwenden eine
modifizierte Version des Programmes slattach, um die serielle
Verbindung in den STRIP Modus zu schalten, und konfigurieren die neuen
Devices dann wie ein normales Ethernet Device. Einziger wichtiger
Unterschied: STRIP unterstützt kein ARP, die ARP Einträge für alle
Rechner eines Sub-Netzwerkes müssen also von Hand vorgenommen werden.
Die Namen der Token Ring Devices sind tr0, tr1 usw. Token
Ring ist ein Standard LAN Protokoll von IBM, bei dem Kollisionen von
Datagrammen dadurch vermieden werden, daß jeweils immer nur ein Rechner
des LAN das Recht hat, Daten zu übertragen.
Auf dem LAN wird ein Token vergeben, das zu einem beliebigen Zeitpunkt
immer nur ein Rechner haben kann. Nur dieser Rechner ist befugt, zu
senden. Sind die Daten übertragen, wird das Token an den nächsten
Rechner weitergegeben. Das Token wandert also zwischen allen aktiven
Rechnern herum, daher der Name »Token Ring«.
Optionen beim Kernel kompilieren:
Network device support --->
[*] Network device support
....
[*] Token Ring driver support
< > IBM Tropic chipset based adaptor support
Die Konfiguration eines Token Ring Device ist bis auf die anderen Devicenamen identisch zur Konfiguration eines Ethernet Device.
X.25 ist ein Packet Switching Protokoll, das durch die C.C.I.T.T.
festgelegt wurde, einer Basis von Standards, die von
Telefongesellschaften in den meisten Teilen der Welt anerkannt sind. An
einer Implementation von X.25 und LAPB wird derzeit gearbeitet, die
jeweils aktuelle Version ist Bestandteil der Entwickler-Kernels
2.1.x.
Jonathon Naylor (jsn@cs.nott.ac.uk) leitet die Entwicklung. Es
wurde eine Mailing Liste angelegt, über die Diskussionen zum Thema X.25
unter Linux geführt werden. Um sie zu abonnieren, schicken Sie eine Mail
an
majordomo@vger.rutgers.edu mit dem Text subscribe
linux-x25" als Inhalt der Mail.
Erste Versionen der Konfigurationsprogramme bekommen Sie per FTP von:
ftp.cs.nott.ac.uk:/jsn/
Die Device Namen für WaveLan sind eth0, eth1 usw.
Optionen beim Kernel kompilieren:
Network device support --->
[*] Network device support
....
[*] Radio network interfaces
....
<*> WaveLAN support
WaveLan Karten sind für kabellose Verbindungen und verwenden Multifrequenztechnik. Die Karten verhalten sich praktisch wie Ethernet-Karten und werden genauso konfiguriert.
Informationen über diese Karten bekommen Sie von Wavelan unter:
http://www.wavelan.com