Linux NET-3 HOWTO : Spezifische Informationen zur Netzwerk Technologie

5. Spezifische Informationen zur Netzwerk Technologie

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.

5.1 ARCNet

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

Die Datei /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.

5.2 Appletalk (AF_APPLETALK)

Hierfür gibt es keine speziellen Device-Einträge, da bestehende Netzwerk-Devices genutzt werden.

Optionen beim Kernel kompilieren:


Networking options  --->
    <*> Appletalk DDP

Durch die Unterstützung von Appletalk kann ein Linux Rechner mit einem Apple Netzwerk zusammenarbeiten. Eine wichtige Anwendung dafür ist die gemeinsame Nutzung von Druckern oder Festplatten über ein Netzwerk. Man benötigt dafür zusätzliche Software: 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

Nachdem man das Archiv entpackt hat, sollte man die Datei 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

Die Konfiguration der Appletalk Software

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.

Exportieren eines Linux Dateisystems via Appletalk

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.

Gemeinsame Nutzung eines Druckers mit Appletalk

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.

Starten der Appletalk Software

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.

Testen der Appletalk Software

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.

Nachteile der Appletalk Software

Unter Umständen müssen Sie die Appletalk-Unterstützung vor der Konfiguration des IP-Netzwerkes durchführen. Gibt es beim Start des Appletalk Programmes Probleme, oder haben sie nach dessen Start Probleme mit dem IP Netzwerk, versuchen Sie die Appletalk Software vor der Ausführung von /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.
Das Programm 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.
Die vorhandenen Diagnosetools wie netstat oder ifconfig unterstützen kein Appletalk. Die Information ist - unformatiert - über /proc/net zugänglich.

Weitere Informationsquellen

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/

5.3 ATM

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/

5.4 AX.25 (AF_AX25)

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

Die Protokolle AX.25, NetRom und Rose werden von Amateurfunkern für Experimente mit Packet Radio genutzt. Eine ausführliche Beschreibung enthält das AX25 HOWTO

Der Großteil der Arbeit bei der Implementation dieser Protokolle wurde von Jonathon Naylor (jsn@cs.not.ac.uk) geleistet.

5.5 DECNet

An der Unterstützung von DECNet wird derzeit gearbeitet. Es wird vermutlich in den späten 2.1.x Kernels auftauchen.

5.6 EQL - Lastverteilung auf mehrere Leitungen

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.gz

Die 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

Die angegebene ungefähre Geschwindigkeit hat keinen direkten Hardwarebezug. Der EQL Treiber nimmt diese Werte lediglich als Anhaltspunkt, um die Datagramme möglichst sinnvoll auf die vorhandenen Leitungen zu verteilen. Man kann die Werte also für das Feintuning durchaus frei verändern.

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.

5.7 Ethernet

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.

5.8 FDDI

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.

5.9 Frame Relay

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

Kompilierung und Installation der Tools ist eigentlich kein Problem, allerdings gibt es kein zentrales Makefile. Dadurch ist einige Handarbeit notwendig:


# 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
#

5.10 IP Accounting

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
#

Der letzte Befehl zeigt eine Auflistung aller Accounting Regeln und zeigt die aufsummierten Zahlenwerte an.

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            *
#

5.11 IP Aliasing

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

Alle mit diesem Device verbundenen Routes werden automatisch ebenfalls gelöscht.

5.12 IP Firewall

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.

5.13 IPX (AF_IPX)

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.

5.14 IPv6

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

erhältlich.

5.15 ISDN

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:

ICN 2B und 4B
Octal PCBIT-D
Teles ISDN-Karten und kompatible

Für einige dieser Karten ist zusätzliche Software nötig, um sie zu betreiben. Diese muß mit speziellen Programmen geladen werden.

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.

5.16 IP Masquerade

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/

5.17 IP Transparent Proxy

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

Dadurch wird jede Verbindungsversuch mit dem Port 80 (WWW) eines beliebigen Rechners auf den Port 8080 des lokalen Rechners umgeleitet. Dadurch kann man z.B. sicherstellen, daß jeglicher WWW Verkehr auf dem Netzwerk automatisch über ein lokales Cache Programm geleitet wird.

5.18 Mobile IP

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/

5.19 Multicast

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/

5.20 NetRom (AF_NETROM)

Die NetRom Devices sind nr0, nr1 usw.

Optionen beim Kernel kompilieren:


Networking options  --->
    [*] Amateur Radio AX.25 Level 2
    [*] Amateur Radio NET/ROM

Die Protokolle AX.25, NetRom und Rose werden von Amateurfunkern für Experimente mit Packet Radio genutzt. Eine Ausführliche Beschreibung enthält das AX25 HOWTO.

Der Großteil der Arbeit bei der Implementation dieser Protokolle wurde von Jonathon Naylor (jsn@cs.not.ac.uk) geleistet.

5.21 PLIP

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

IPA.IPA.IPA.IPA

ihre IP Adresse;

IPR.IPR.IPR.IPR

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

5.22 PPP

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.

Permanente Netzverbindungen mit pppd

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

Stellen Sie sicher, daß sie in der Datei /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

Dadurch wird der Daemon pppd laufend von init überwacht und im Falle eines Verbindungsabbruches automatisch neu gestartet.

5.23 Rose protocol (AF_ROSE)

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)

Die Protokolle AX.25, NetRom und Rose werden von Amateurfunkern für Experimente mit Packet Radio genutzt. Eine Ausführliche Beschreibung enthält das AX25 HOWTO.

Der Großteil der Arbeit bei der Implementation dieser Protokolle wurde von Jonathon Naylor (jsn@cs.not.ac.uk) geleistet.

5.24 SAMBA - »NetBEUI«, »NetBios« Unterstützung

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.

5.25 SLIP Client

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

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

Nur muß der Makefile an die eigenen Bedürfnisse angepaßt werden. Schließlich wird das Programm kompiliert und installiert:


# 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.

slattach

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.

Wann benutze ich welches Programm?

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.

Statische SLIP Server und dip

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.

Dynamische SLIP Server und dip

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.

Die Benutzung von dip

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.

Dauerhafte SLIP Verbindungen mit slattach

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:

IPA.IPA.IPA.IPA

Ihre IP Adresse;

IPR.IPR.IPR.IPR

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.

5.26 SLIP Server

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.

SLIP Server mit sliplogin

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:

/etc/passwd

Enthält die Accounts der Benutzer.

/etc/slip.hosts

Hier stehen die für jeden Nutzer spezifischen Informationen für SLIP.

/etc/slip.login

Dieses Script regelt die Routing Konfiguration für die Nutzer.

/etc/slip.tty

Diese Datei wird nur bei der Verwendung von dynamischer Adressvergabe benötigt und enthält eine Tabelle mit benutzbaren Adressen.

/etc/slip.logout

Hier stehen die Kommandos, um die Verbindung bei einem Logout oder bei Fehlern korrekt zu beenden.

Bezugsquellen für sliplogin

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/

Die TAR Datei enthält Quellen, vorkompilierte Binärprogramme und die manual page.

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

Nun wird das Makefile editiert, falls Sie keine Shadow Paßwörter verwenden. Schließlich kann das Paket installiert werden:


# 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.

Anpassung von /etc/passwd für SLIP Hosts

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.

Konfiguration von /etc/slip.hosts

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:

Login-Name des Anrufers
IP Adresse des Servers
IP Adresse, die dem Anrufer zugeteilt wird. Enthält dieses Feld den Eintrag 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.
Netmask für den Anrufer in Dezimalpunktschreibweise, für ein Klasse-C Netz also 255.255.255.0.
Verwendeter SLIP Modus, hier können Kompression sowie einige andere Besonderheiten eingestellt werden.
Timeout. Hier kann man einstellen, wie lange eine Verbindung unbenutzt sein darf (d.h. es werden keine Datagramme gesendet/empfangen), bevor die Verbindung automatisch unterbrochen wird. Ein negativer Wert verhindert das automatische Unterbrechen.
Optionale Argumente

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

normal

Für normales, unkomprimiertes SLIP.

compressed

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.

Konfiguration der Datei /etc/slip.login

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.

Konfiguration von /etc/slip.logout

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.

Konfiguration von /etc/slip.tty

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.

SLIP Server mit dip

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

Dann müssen entsprechende Einträge in /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 Konfiguration von /etc/diphosts

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:

Login Name: Name, wie er von getpwuid(getuid()) zurückgeliefert wird, oder Name des tty.
unbenutzt: Zur Kompatibilität mit passwd.
Remote Adresse: IP Adresse des anrufenden Rechners, entweder als Name oder in Dezimalschreibweise.
Lokale Adresse: IP Adresse des lokalen Rechners, entweder als Name oder in Dezimalschreibweise.
Netmask: in Dezimalschreibweise
Kommentar: beliebiger Eintrag
Protokoll: SLIP, CSLIP usw.
MTU: Zahl

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.

SLIP Server mit dem dSLIP Paket

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.

5.27 Unterstützung für STRIP (Starmode Radio IP)

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.html

Sie 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.com

Die 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.html

Eine 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.

5.28 Token Ring

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.

5.29 X.25

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/

5.30 WaveLan Karten

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

Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 17:56:56