\chapter{Einleitung}

fli4l ist ein Linux-basierender ISDN-, DSL- und Ethernet-Router, der
lediglich 1 Diskette zum Arbeiten benötigt. Ein 486er mit 16MiB RAM ist
dafür vollkommen ausreichend.

Die notwendige Bootdiskette kann unter Unix, Linux oder Windows
erstellt werden. Dabei sind keine Linux-Kenntnisse erforderlich, aber
evtl. nützlich.  Grundkenntnisse von Netzwerken, TCP/IP, DNS und
Routing sollten jedoch vorhanden sein. Für eigene
Erweiterungen/Entwicklungen, welche über die Standardkonfiguration
hinausgehen, sind ein lauffähiges Linux-System und
Unix/Linux-Kenntnisse notwendig.

Mit der Version 2.0 unterstützt fli4l nun auch \glqq offiziell\grqq andere
Bootmedien als nur Disketten. Damit wird es nun endlich möglich, noch
mehr Software-Pakete auf dem fli4l-Router zu installieren, als auf
eine Diskette passen. Bevor man sich aber an eine Installation auf
Festplatte oder Compact-Flash heranwagt, sollte man vorher einmal die
Diskettenversion als Basis-Installation konfigurieren und
ausprobieren. Die meisten optionalen Softwarepakete laufen bereits
auch bei der Installation auf einer Diskette, sodaß ein Massenspeicher
(wie Festplatte) nur dann sinnvoll wird, wenn die komplette für fli4l
verfügbare Software-Palette installiert werden soll.
Es ist auch möglich fli4l von einer CD zu starten.

\begin{description}
\item[Features:]

\begin{itemize}
\item Erstellen der Boot-Diskette unter Unix, Linux,
      \jump{DARWINMACOSX}{Darwin/Apple Mac OS X} und Windows
\item Konfiguration über normale ASCII-Dateien
\item Unterstützung von IP-Masquerading und Port-Forwarding
\item Least-Cost-Routing: automatische Auswahl des Providers, je nach
  Uhrzeit
\item Anzeige/Berechnung/Protokollierung von Verbindungszeiten und
  -kosten
\item Windows/Unix/Linux-Client imonc mit Schnittstelle zu imond und
  telmond
\item Upload von neuen Konfigurationsdateien über Windows-Client imonc
\item Bootdiskette mit vfat-Dateisystem zum dauerhaften Speichern von
  Dateien
\item Unterstützung von 1680KiB-Disketten
\item Paketfilter: Logging bei Zugriff von außen auf gesperrte Ports
\item Einheitliche Abbildung von WAN-Schnittstellen auf sogenannte
  Circuits
\item Betrieb/Routing von ISDN- und DSL-Circuits parallel möglich
\end{itemize}

\item[Router:]

\begin{itemize}
\item Linux-Kernel 2.4.32
\item Paketfilter und IP-Masquerading
\item DNS-Server, damit nicht jede Anfrage von Windows-PCs in's WAN geht
\item Netzwerkfähiger imond-Server mit Monitor-/und LCR-Steuerfunktionen
\item Netzwerkfähiger telmond-Server zur Ausgabe von eingehenden Telefonanrufen
\end{itemize}

\item[Ethernet-Support:]

\begin{itemize}
\item Aktuelle Netzwerkkartentreiber: Unterstützung von über 40 Kartenfamilien
\end{itemize}

\item[DSL-Support:]

\begin{itemize}
\item Roaring Penguin PPPoE-Treiber, mit Dial-on-Demand (abschaltbar)
\item PPTP für DSL-Anbindungen in Österreich und Holland (EXPRIMENTAL)
\end{itemize}

\item[ISDN:]

\begin{itemize}
\item Aktuelle HiSaX-Treiber: Unterstützung von 37 ISDN-Kartentypen
\item Mehrere ISDN-Verbindungsmöglichkeiten: in/out/callback, raw-ip/ppp
\item Kanalbündelung: automatische Bandbreitenanpassung oder manuelle
  Zuschaltung des 2. Kanals über Windows-/Unix-Client
\end{itemize}

\item[Optionale Programmpakete:]

\begin{itemize}
\item DNS-Server
\item DHCP-Server
\item SSH-Login
\item Einfache Online-/Offline-Anzeige über LED
\item LCD-Anzeige-Programm mit konfigurierbarem Ausgabeformat
\item Serielle Konsole
\item Mini-Webserver für ISDN- und DSL-Monitoring
\item Zugangserlaubnis für bestimmte konfigurierte Netzwerke von außen
\item PCMCIA-Support
\item Protokollierung von Systemmeldungen: syslogd und klogd
\item Konfiguration von ISA-PNP-Karten: isapnp tools
\item Zusätzliche Werkzeuge zum Debugging
\item Konfiguration der seriellen Schnittstelle
\item Notfallsystem zur Fernwartung über ISDN
\item LCD-Display als Monitor: Anzeige von Verbindungen und
  Übertragungsraten
\item PPP-Server/Router über serielle Schnittstelle
\item ISDN-Modem-Emulator über serielle Schnittstelle
\item Druckerserver
\item Zugriff auf Time-Server zur Synchronisierung der Uhrzeit im Netz
\item Ausführen von Kommandos/Prozeduren bei Telefonanruf (z.B.
  Internet-Einwahl)
\item Unterstützung von IP-Aliasing (mehrere IPs auf einer
  Netzwerkkarte)
\item VPN-Unterstützung
\end{itemize}

\item[Hardwarevoraussetzungen:]

\begin{itemize}
\item ISDN: 486er CPU ab 25 MHz, besser 486er ab 33 MHz
\item DSL: 486er CPU ab DX2/66, besser 486er DX4/100 oder Pentium ab
  75 MHz
\item 12 MiB Speicher, besser 16 MiB
\item Ethernet-Netzwerkkarte (Unterstützung von über 40 verschiedenen
  Typen-Familien)
\item ISDN: HiSax unterstützte ISDN-Karte (Typ 1-39), capi unterstützte
  ISDN-Karte (12 AVM-Typen) oder ICN 2B aktive ISDN-Karte
\item ein 1440 KiB Diskettenlaufwerk
\item eine Boot-Diskette, alles notwendige drauf
\item optional eine IDE-Festplatte oder ein Compact-Flash-Medium
  (welches genauso wie eine IDE-Festplatte angesprochen wird) oder ein
  zweites Diskettenlaufwerk. Alternativ ist auch der
  Start von CD möglich.
\end{itemize}

\item[Softwarevoraussetzungen]

Unter Unix werden folgende Programme vorrausgesetzt:

\begin{itemize}
\item gcc und make
\item syslinux
\item mtools (mcopy)
\end{itemize}

Unter Windows werden keine zusätzlichen Werkzeuge benötigt, fli4l
bringt alles notwendige mit.

\end{description}

Zusätzlich gibt es zur Steuerung/Statusanzeige des fli4l-Routers noch
den Client imonc. Dieses Programm ist für Windows (windows/imonc.exe)
und auch für Linux (unix/gtk-imonc) vorhanden.

Und nun \ldots \\

Viel Spaß mit fli4l!\\[1.5ex]

Frank Meyer, \email{frank@fli4l.de}

\chapter{Installation}


Unter Linux:

\begin{verse}{\tt tar xvfz fli4l-\version.tar.gz}\end{verse}

Unter Unix:

\begin{verse}{\tt gtar xvfz fli4l-\version.tar.gz}\end{verse}

Ist gtar nicht vorhanden, geht's auch so:

\begin{verse}{\tt gzip -d < fli4l-\version.tar.gz | tar xvf -}\end{verse}

Wer die aktuelle Version in einem bereits existierenden
fli4l-Verzeichnis installiert, sollte anschließend das Script
mkclean.sh -c aufrufen, also:

\begin{verse}{\tt
    cd fli4l-\version\\
    sh mkclean.sh -c
}\end{verse}

Es wird jedoch empfohlen, ein neues Verzeichnis für eine neue Version
zu benutzen - die Konfiguration kann durch ein entsprechendes Tool zum
Dateivergleich sehr einfach übernommen werden.

Unter Windows kann das komprimierte tar-Archiv zum Beispiel mit WinZip
extrahiert werden. Dabei ist jedoch zu beachten, dass die Dateien
{\em mit} Unterverzeichnissen (Einstellung in WinZip überprüfen!)
ausgepackt werden. Außerdem ist in {\em Optionen \pfeil
  Konfiguration} die so genannte ``Smart TAR CR conversion''
abzuschalten. Ist diese eingeschaltet, werden einige (aber wichtige)
Dateien von WinZip falsch extrahiert.

Alternativ ist das OpenSource-Programm 7-Zip (\link{http://www.7-zip.org/})
sehr zu empfehlen, welches ebenso mächtig wie WinZip ist.

Es werden folgende Dateien im Unterverzeichnis
{\tt fli4l-\version/} installiert:

\begin{itemize}
\item Dokumentation:
  \begin{itemize}
  \item doc/deutsch/* Deutsche Dokumentation
  \item doc/english/* Englische Dokumentation
  \end{itemize}

\item Konfiguration:
  \begin{itemize}
  \item config/*.txt Konfigurationsdateien, diese müssen bearbeitet
    werden
  \end{itemize}

\item Scripts/Prozeduren:
  \begin{itemize}
  \item mkfli4l.sh Boot-Diskette oder Dateien erzeugen: Linux/Unix-Version
  \item mkfli4l.bat Boot-Diskette erzeugen: Windows-Version
  \end{itemize}

\item Kernel/Root-Dateisystem:
  \begin{itemize}
  \item img/kernel Linux-Kernel 2.4.32
  \item img/rootfs\_distrib.tar Dieses Archiv enthält die Dateien, die nach dem Booten
  des Kernels als allererstes benötigt werden.
  \end{itemize}

\item Zusatzpakete:
  \begin{itemize}
  \item opt/*.txt Diese Dateien beschreiben, was bei welchen Einstellungen in
  das Archiv opt\_tar.bz2 gelangt.
  \item opt/etc/* Standard-Konfigurationsdateien für viele Programme (müssen
  normalerweise nicht bearbeitet werden).
  \item opt/files/* Optionale Kernel-Module, Dateien und Programme
  \end{itemize}

\item Quellcode:
  \begin{itemize}
  \item src/* Quellcode/Tools für Linux, siehe src/README
  \end{itemize}

\item Programme:
  \begin{itemize}
  \item unix/mkfli4l* Erzeugen der Boot-Disk: Unix/Linux-Version
  \item windows/* Erzeugen der Boot-Disk: Windows-Version
  \item unix/imonc* imond-Client für Unix/Linux
  \item windows/imonc/* imond-Client für Windows
  \end{itemize}
\end{itemize}

Zur Konfiguration von fli4l müssen lediglich die Dateien config/*.txt
angepasst werden. Anschließend kann man dann mit einem Befehl die
Bootdiskette erstellen.

\achtung {Man sollte keineswegs alte Konfigurationsdateien aus einer
  vorherigen fli4l-Version als Vorlage verwenden. Diese sind
  inkompatibel!}

\marklabel{VARIANTEN}{\section{Varianten}}

In den vorhergehenden Versionen von fli4l wurde lediglich das Booten
von einer Diskette unterstützt. Im Normalfall, wenn man fli4l
tatsächlich nur als Router verwendet, reicht dies auch vollkommen aus.

Aufgrund der stark angewachsenen Anzahl von möglichen (aber nicht
unbedingt notwendigen!) Softwarepaketen für fli4l ist ab Version 2.0
nun auch die Installation von fli4l auf Festplatten oder
Compact-Flashs möglich.
Als Alternative ist es auch möglich sich ein
ISO-Image für eine CD zu erstellen und den Router von dieser zu Booten.

Man sollte jedoch zunächst erst einmal fli4l in der
1-Disketten-Version installieren und damit Erfahrungen sammeln.
Natürlich ist die Kapazität einer Diskette beschränkt. Möchte man
fli4l zusätzlich als Anrufbeantworter und als HTTP-Proxy einsetzen,
stößt man schnell an die Kapazitätsgrenzen einer einzigen Diskette.
Für diesen Fall nun ist die Installation von fli4l auf einer
Festplatte oder eines Compact-Flash-Moduls vorgesehen. Jedoch ist die
Installation auf Fesplatte etwas komplizierter, so dass man sich erst
als fortgeschrittener fli4l-User daran wagen sollte. Wie gesagt: zum
Betrieb als Router reicht auch weiterhin eine Diskette, Festplatten
sind nicht erforderlich!

Für die Installation unterscheiden wir insgesamt 3 Varianten:

\begin{description}
\item[Diskettenrouter] Router auf nur einer Diskette -- Die bisherige Installation
\item[HD-Installation Typ A] Router auf Festplatte -- nur eine FAT-Partition
\item[HD-Installation Typ B] Router auf Festplatte -- je eine FAT- und ext3-Partition
\end{description}

\marklabel{INSTALLTYP0}{\subsection{Router auf nur einer Diskette -- Die
    bisherige Installation}}

Alle benötigten Dateien liegen auf einer DOS-formatierten Diskette.
Das RootFS wird in eine dynamische RAM-Disk entpackt, die Dateien des
Archivs opt\_tar.bz2 kommen ebenfalls in diese Ramdisk mit variabler Größe.
In einer Minimalkonfiguration ist damit ein Betrieb des Routers mit
nur 8 MiB RAM möglich. Die maximale Konfiguration wird nur durch die Kapazität
der Diskette und des Hauptspeichers limitiert.


\marklabel{INSTALLTYPA}{\subsection{Typ A: Router auf Festplatte --
    nur eine FAT-Partition}}

Dies entspricht der Diskettenversion, nur dass die Dateien hierbei auf
einer Festplatte liegen, wobei der Begriff \glqq Festplatte\grqq hier auch
Compact-Flash-Medien ab 2 MiB und andere Geräte, welche Linux als
Festplatte ansprechen kann, mit einschließt. Seit fli4l 2.1.4 können
auch DiskOnChip Flash-Speicher von M-Sys oder SCSI-Festplatten benutzt
werden.

Die Beschränkung des Archivs opt\_tar.bz2 durch die
Diskettenkapazität wird aufgehoben, aber alle diese Dateien müssen in
einer RAM-Disk mit der entsprechenden Größe beim Boot installiert werden.
Dies erhöht den RAM-Bedarf beim Einsatz vieler Pakete.

Für ein Update der Softwarepakete (d.h. des Archivs opt\_tar.bz2 und der
rc.cfg über das Netzwerk) muss die FAT-Partition genügend Platz für den
Kernel, das RootFS und die DOPPELTE Größe des opt\_tar.bz2 haben!
Falls auch die Notfall-Option genutzt werden soll, erhöht sich der
Platzbedarf noch einmal um die Größe des opt\_tar.bz2.


\marklabel{INSTALLTYPB}{\subsection{Typ B: Router auf Festplatte -- je
    eine FAT- und ext3-Partition}}

Im Gegensatz zum Typ A wird hier auf eine Ramdisk verzichtet.
Die Dateien aus dem Archiv opt\_tar.bz2 werden beim Start des Routers
direkt auf eine ext3-Partition kopiert und im späteren Betrieb von
dort geladen. Bei dieser Version ist der Speicherbedarf für die
RAM-Disk am geringsten und damit meist auch ein Betrieb mit sehr wenig
RAM möglich.

Weitere Informationen zur Installation auf Festplatten finden Sie in
der Dokumentation des separat herunterzuladenden Packages HD -
beginnend bei der Beschreibung der Variablen \var{OPT\_\-HDINSTALL}.


\chapter{Basiskonfiguration}

Ab Version 2.0 ist die fli4l-Distribution modular aufgebaut und in
mehrere Pakete aufgeteilt, die extra heruntergeladen werden müssen. Im
Paket {\tt fli4l-\version.tar.gz} ist lediglich die
Basis-Software für einen Ethernet-Router enthalten. Für DSL, ISDN und
weitere Software müssen die Pakete separat heruntergeladen werden und
ausgehend vom Verzeichnis {\tt fli4l-\version/} (!) installiert
werden. In Tabelle \ref{tab:zusatzpakete} finden Sie einen
Überblick über die Zusatzpakete.

\begin{table}[htbp]
  \begin{center}
    \begin{tabular}{ll}

      Download-Archiv & Paket \\
      \hline
      {\tt fli4l-\version}            &    BASIS, erforderlich!\\
      \verb*zdslz                     &    DSL-Router (PPPoE, PPTP)\\
      \verb*zisdnz                    &    ISDN-Router\\
      \verb*zchronyz                  &    Time-Server/Client\\
      \verb*zdhcpz                    &    DHCP-Server\\
      \verb*zhdz                      &    Installation auf Festplatte\\
      \verb*zhttpdz                   &    Mini-Webserver für Status-Ausgaben\\
      \verb*zsshdz                    &    SSH-Server\\
      \verb*zlcdz                     &    LCD-Treiber-Software + Statusanzeige\\
      \verb*zlpdsrvz                  &    Druckerserver (ohne Spooling)\\
      \verb*zpcmciaz                  &    Unterstützung von PCMCIA-Karten\\
      \verb*zpppz                     &    PPP-Anbindung über serielle Schnittstelle\\
      \verb*zproxyz                   &    Proxy-Server\\
      \verb*zserialz                  &    Tools für serielle Schnittstelle\\
      \verb*ztoolsz                   &    Diverse Linux-Programme als Tools\\
      \verb*zvpnz                     &    VPN-Unterstützung\\
      \verb*zdyndnsz                  &    Unterstützung von DYNDNS-Diensten\\
      \verb*zwlanz                    &    Unterstützung von WLAN-Karten\\
      \verb*zeasycronz                &    Zeitplandienst\\
      \verb*zusbz                     &    Unterstützung der USB-Schnittstelle


    \end{tabular}

    \caption{Übersicht über die Zusatzpakete}
    \marklabel{tab:zusatzpakete}{}
  \end{center}
\end{table}

Die zur Konfiguration des fli4l-Routers verwendeten Dateien
befinden sich im Verzeichnis {\tt config/} und werden hier im folgenden
beschrieben.

Diese Dateien können mit einem {\em einfachen}Text-Editor oder auch
mit einem speziell an fli4l angepaßten Editor verändert werden. Diverse
Editoren sind unter\\
\link{http://www.fli4l.de/german/addons.htm} zu finden.
%Windows-Kon\-fi\-gu\-ra\-tions\-pro\-gramm angepasst werden. Mit Hilfe des
%\glqq fli4l-Wizard\grqq  kann man sich dann die Konfiguration mit der Maus
%quasi \glqq zusammenklicken\grqq.  Das Programm wurde von Carsten Cerny und
%Jürgen Bauer erstellt. Ziel ist, mit Hilfe von fliwiz auch mit wenig
%Netzwerk-Kenntnissen eine Standard-Router-Konfiguration zu generieren.
%Weil fliwiz auch selbst ASCII-Dateien als Konfigurationsdatei erzeugt,
%die den mitgelieferten Dateien entsprechen, kann jeder selbst
%entscheiden, ob er fliwiz und/oder einen Text-Editor verwenden möchte.

%Sollte jemand Anregungen zur Verbesserung des Programms haben, freuen
%sich Carsten (\email{carsten.cerny@cc13.com}) bzw.  Jürgen
%(\email{jb@idowa.de}) bestimmt auf eine Mail dazu. Die aktuelle
%Version von fliwiz findet man -- wie auch fli4l -- unter
%\link{http://www.fli4l.de/}.

Sind spezielle Anpassungen/Erweiterungen erforderlich, die über die
unten aufgeführten Einstellungsmöglichkeiten hinausgehen, benötigt man
ein lauffähiges Linux-System, um Anpassungen im RootFS vorzunehmen. In
diesem Fall hilft src/README weiter.


\index{base.txt}
\index{Beispiel-Datei (base.txt)}
\marklabel{beispielbase}{\section{Beispiel-Datei}}

Die Beispiel-Datei ,,base.txt'' im Verzeichnis ,,config'' hat
folgenden Inhalt:

\begin{scriptsize}
\begin{example}
\begin{verbatim}
#------------------------------------------------------------------------------
# General settings:
#------------------------------------------------------------------------------
HOSTNAME='fli4l'               # name of fli4l router
PASSWORD='fli4l'               # password for root login (console, sshd, imond)
BOOT_TYPE='fd'                 # boot device: fd, fdx2, dualfd, hd, cd, ls120,
                               # integrated, attached, netboot, pxeboot
                               # (cd, cdemul, hd and ls120 need an
                               # installed opt hd)
MOUNT_BOOT='rw'                # mount boot device (floppy): ro, rw, no
TIME_INFO='MEZ-1MESZ,M3.5.0,M10.5.0'
                               # description of local time zone,
                               # don't touch without reading documentation
KERNEL_VERSION='2.4.32'        # kernel version
KERNEL_BOOT_OPTION=''          # append option to kernel command line
COMP_TYPE_KERNEL='gzip'        # compression-type for kernel: gzip, bzip2
COMP_TYPE_ROOTFS='gzip'        # compression-type for rootfs: gzip, bzip2
IP_CONNTRACK_MAX=''            # override maximum limit of connection
                               # tracking entries
POWEROFF_ON_HALT='no'          # power off after shutting down the machine
REAL_MODE_POWEROFF='no'        # switch to real mode before invoking
                               # apm power off

#------------------------------------------------------------------------------
# Localisation
#------------------------------------------------------------------------------
LOCALE='de'                    # this variable is used to define the language
                               # used in several opt's and set other
                               # country specific settings (e.g. keybord layout)

#------------------------------------------------------------------------------
# Mount of extra floppy drive to /floppy:
#------------------------------------------------------------------------------
OPT_MOUNTFLOPPY='no'           # mount extra floppy drive: first, second, no

#------------------------------------------------------------------------------
# Console settings (serial console, blank time):
#------------------------------------------------------------------------------
CONSOLE_BLANK_TIME=''          # time in minutes (1-60) to blank
                               # console; '0' = never, '' = system default
SER_CONSOLE='no'               # use serial interface instead of or as
                               # additional output device and main input device
    SER_CONSOLE_IF='0'         # serial interface to use, 0 for ttyS0 (COM1)
    SER_CONSOLE_RATE='9600'    # baudrate for serial console
    SER_BEEP='no'              # enable beep after boot and shutdown

#------------------------------------------------------------------------------
# Debug Settings:
#------------------------------------------------------------------------------
DEBUG_STARTUP='no'             # write an execution trace of the boot
DEBUG_LOG=''                   # sequence to file DEBUG_LOG or console if
                               # DEBUG_LOG is empty

#------------------------------------------------------------------------------
# Show service menu after login:
#------------------------------------------------------------------------------
OPT_MENU='yes'                 # service menu for users

#------------------------------------------------------------------------------
# keyboard layout
#------------------------------------------------------------------------------
KEYBOARD_LOCALE='auto'         # use keyboard layout of country given in 'LOCALE'

#------------------------------------------------------------------------------
# Ethernet card drivers:
#
#  Driver       Bus     Description
#
#  3c503        ISA     3COM EtherLinkII (3c503)
#  3c505        ISA     3COM Etherlink Plus (3c505)
#  3c507        ISA     3COM Etherlink 16 (3c507)
#  3c509        ISA     3COM EtherLinkIII (3c509)
#  3c515        ISA     3COM EtherLink XL ISA (3c515)
#  3c59x        PCI     3COM Vortex/Boomerang 3c59x,3c900,3c905
#  8139cp       PCI     RealTek 8139C+
#  8139too      PCI     RealTek 8129/8139 10/100 MB (NEW)
#  rtl8139-db   PCI     RealTek 8129/8139, Donald Beckers Version, see
#                       <http://www.scyld.com/network/rtl8139.html>
#  82596                Apricot Xen-II on board Ethernet
#  acenic       PCI     Alteon AceNIC Gigabit Ethernet
#  at1700       ISA     AT1700 (Fujitsu 86965) ISA
#  b44          PCI     Broadcom 4400
#  cs89x0       ISA     IBM Etherjet, cs89x0 based Cards
#                       (Option io=0xnnn necessary!)
#  de4x5        PCI/EISA Digital DE425, DE434, DE435, DE450, DE500
#  depca        ISA     DEPCA, DE10x, DE200, DE201, DE202, DE422
#  dgrs         PCI     Digi International RightSwitch PCI/EISA
#  dl2k         PCI     D-Link DL2000-based Gigabit Ethernet Adapter
#  dmfe         PCI     DM9102 compatible PCI cards from Davicom
#  e1000        PCI     Intel EtherExpress PRO/1000 Gigabit Ethernet
#  e100         PCI     Intel's original driver for EEPRO100
#  e2100        ISA     Cabletron E21xx ISA
#  eepro100     PCI     Intel EtherExpressPro PCI 10+/100B/100+
#  eepro        ISA     Intel EtherExpress Pro/10
#  eexpress     ISA     EtherExpress16 ISA
#  epic100      PCI     SMC EPIC/100 (EtherPower II) PCI
#  eth16i       ISA/EISA    ICL EtherTeam 16i/32
#  ewrk3        ISA     EtherWORKS 3 ISA (DE203, DE204, DE205)
#  fealnx       PCI     ASOUND LAN 8139 card - not RTL8139 (NEW)
#  hamachi      PCI     GNIC-II Gigabit Ethernet
#  hp100        ISA/EISA/PCI    HP 10/100VG PCLAN (ISA, EISA, PCI)
#  hp           ISA     HP PCLAN (27245, 27xxx) ISA
#  hp-plus      ISA     HP PCLAN+ (27247B and 27252A) ISA
#  lance        ISA     AMD LANCE and PCnet (AT1500, NE2100) ISA
#  lp486e               Intel Professional Workstation/panther ethernet driver
#  natsemi      PCI     National Semiconductor
#  ne2k-pci     PCI     NE2000 PCI clone (eg. Realtek 8029, Winbond 89c940)
#  ne           ISA     NE2000 ISA clone (eg. Realtek 8019,
#                       Accton 16xx, NatSemi 8390, UMC 9003/9008)
#  ni5010               MiCom-Interlan NI5010
#  ni52                 NI5210 card (i82586 Ethernet chip)
#  ni65                 ni6510 (am7990 'lance' chip)
#  ns83820      PCI     cards with National Semiconductor 83820 chip
#  pcnet32      PCI     AMD PCI PCnet32
#  r8169        PCI     Realtek 8169 Gigabit Ethernet
#  sis900       PCI     SiS 900/7016
#  sk98lin      PCI     SysKonnect Gigabit Ethernet Server Adapters
#  smc9194              SMC's 9000 series of Ethernet cards
#  smc-ultra    ISA     SMC ULTRA
#  starfire     PCI     Starfire
#  sundance     PCI     DFE-550FX or DFE-530TXS (NEW)
#  tg3          PCI     Broadcom Tigon3
#  tlan         PCI     TI ThunderLAN (Compaq Netelligent ...)
#  tulip        PCI     DECchip Tulip (dc21x4x) PCI
#  via-rhine    PCI     VIA Rhine PCI (3043, VT86c100A, dfe-530tx)
#  wd           ISA     SMC WD80*3
#  winbond-840  PCI     Winbond 840
#  sunhme       PCI/Sbus    Sun Happy Meal 10/100baseT support
#                           (only QFE is tested)
#  yellowfin    PCI     Packet Engines G-NIC PCI Gigabit Eth Adapter
#
# Donald Becker drivers, see <http://www.scyld.com/>
#
#  epic100-db
#  3c59x-db             This driver is for the 3Com "Vortex" and
#                       "Boomerang" series ethercards. Members of the
#                       series include Fast EtherLink
#                       3c590/3c592/3c595/3c597 and the EtherLink XL
#                       3c900 and 3c905 cards.
#
#
# Drivers below need the Package pcmcia installed:
#
#  3c574_cs     PCMCIA  3Com 574
#  3c589_cs     PCMCIA  3Com 589
#  axnet_cs     PCMCIA  Asix AX88190 Fast Ethernet
#  fmvj18x_cs   PCMCIA  Fujitsu FMV-J181/182 Ethernet
#  nmclan_cs    PCMCIA  New Media Ethernet LAN
#  pcnet_cs     PCMCIA  NS8390-based cards (NE2000, DLINK etc)
#  smc91c92_cs  PCMCIA  SMC91c92-based cards
#  xirc2ps_cs   PCMCIA  Xircom: CE2, CEM28, CEM33, or CE3
#
# If you don't find your Cardbus Card here then try the equivalent PCI-Driver:
# 3c59x instead of 3c575_cb or 8139too instead of realtek_cb
#
# These drivers need PCMCIA _and_ WLAN:
#
#  orinoco_cs   PCMCIA  Lucent/Orinoco WLAN-Cards
#  hostap_cs    PCMCIA  PrismII/2.5/3 based Cards - supports AP-Mode
#  wavelan_cs   PCMCIA  WaveLAN
#  wl24_cs      PCMCIA  ELSA Airlancer MC-2 - Should have Firmware 2.10
#  airo_cs      PCMCIA  Cisco Aironet 4500 & 4800 series PCMCIA cards
#  ray_cs       PCMCIA  Raylink wireless cards
#  netwave_cs   PCMCIA  Netwave AirSurfer Wireless LAN
#
# These drivers need Package WLAN
#
# WLAN-Card Drivers IEEE802.11b:
#
#  hostap_pci   PCI     Prism 2.5 based PCI Wlan Cards
#  hostap_plx   PCI     Prism 2,2.5 and 3 based PCMCIA-WLan Cards
#                       in PLX-Adapter
#  airo         PCI/ISA Cisco Aironet 4500 & 4800 series PCI/ISA cards
#
# These 3 drivers acutally only work with Prism-II Cards - alternative driver
# to hostap_*
#  orinoco_pci  PCI     Lucent/Orinoco based WLAN-Cards
#  orinoco_plx  PCI     Lucent/Orinoco based PCMCIA WLAN-Cards in PLX Adapter
#  orinoco_tmd  PCI     Lucent/Orinoco based WLAN-Cards with TMD PCI-Bridge

# WLAN-Card Drivers IEEE802.11g:
#
#  prism54      PCI/PCMCIA  Prism GT / Prism Duette / Prism Indigo Chipsets
#                           Achten Sie auf die Hinweise zum Prism54 Treiber
#                           in der WLAN Dokumentation!
#  rt2500	PCI/CARDBUS Ralink RT2500 Cards - experimental
#
# USB-Card Drivers:
#
#  pegasus      teledat Fast Ethernet USB
#
#  kaweth       3Com 3C19250
#               ADS USB-10BT
#               ATEN USB Ethernet
#               ASANTE USB To Ethernet Adapter
#               AOX Endpoints USB Ethernet
#               Correga K.K.
#               D-Link DSB-650C and DU-E10
#               Entrega / Portgear E45
#               I-O DATA USB-ET/T
#               Jaton USB Ethernet Device Adapter
#               Kingston Technology USB Ethernet Adapter
#               Linksys USB10T
#               Mobility USB-Ethernet Adapter
#               NetGear EA-101
#               Peracom Enet and Enet2
#               Portsmith Express Ethernet Adapter
#               Shark Pocket Adapter
#               SMC 2202USB
#               Sony Vaio port extender
#  rtl8150      RTL8150-based USB-Ethernet-Cards
#  catc         Belkin F5U111
#               CATC NetMate
#               CATC NetMate II
#               smartBridges smartNIC
#
# DSL-Modems shown as Ethernetcards:
#
#  cdcether     Ericsson PipeRider (all variants)
#               Motorola (DM100 and SB4100)
#               Broadcom Cable Modem (reference design)
#               Toshiba PCX1100U and possibly other cable modems
#               Sharp Zaurus SL-5000D
#  eagle-usb    Allied Telesyn AT-AR 215
#               Sagem 250
#               Acer ADSL Surf USB
#               D-Link DSL 260i
#               Sagem 840
#               US Robotics USR9000
#               Sagem F@st 800
##
# USB-to-USB-network-cable:
#
#  usbnet       Driver for usb-to-usb networklinks
#
# Token ring drivers (see token ring mini howto on
#     <http://www.tldp.org/docs.html#howto> and feel
#     free to submit documention changes:
#
#  3c359
#  abyss
#  ibmtr
#  lanstreamer
#  olympic
#  smctr
#  tmsisa
#  tmspci
#
#  If you need a dummy device use 'dummy' as you NET_DRV
#  and IP_NET_%_DEV='dummy<number>' as your device
#
#------------------------------------------------------------------------------
NET_DRV_N='1'                  # number of ethernet drivers to load, usually 1
NET_DRV_1='ne2k-pci'           # 1st driver: name (e.g. NE2000 PCI clone)
NET_DRV_1_OPTION=''            # 1st driver: additional option
NET_DRV_2='ne'                 # 2nd driver: name (e.g. NE2000 ISA clone)
NET_DRV_2_OPTION='io=0x320'    # 2nd driver: additional option

#------------------------------------------------------------------------------
# Ether networks used with IP protocol:
#------------------------------------------------------------------------------
IP_NET_N='1'                   # number of IP ethernet networks, usually 1
IP_NET_1='192.168.6.1/24'      # IP address of your n'th ethernet card and
                               # netmask in CIDR (no. of set bits)
IP_NET_1_DEV='eth0'            # required: device name like ethX

#------------------------------------------------------------------------------
# Additional routes, optional
#------------------------------------------------------------------------------
IP_ROUTE_N='0'                            # number of additional routes
IP_ROUTE_1='192.168.7.0/24 192.168.6.99'  # network/netmaskbits gateway
IP_ROUTE_2='0.0.0.0/0 192.168.6.99'       # example for default-route

#------------------------------------------------------------------------------
# Packetfilter configuration; there are two styles, old and new -
# you have to choose one of them.
#
# Please choose the new packet filter configuration, the old one is
# deprecated and only provided for compatibility reasons. During boot
# up the configuration will be translated to the new configuration,
# printed to the screen and written bootmsg.txt to allow for an
# easy migration to the new config style.
#
# Old style packet filter config - set ORIG_FW_CONFIG='yes' to use
# this version
#------------------------------------------------------------------------------
ORIG_FW_CONFIG='no'

    #--------------------------------------------------------------------------
    # Known networks - Networks which are allowed to pass the packet
    # filter (additional restrictions may be applied via black/white
    # lists, port based filters, port forwarding opens additional holes, ...)
    #--------------------------------------------------------------------------
    MASQ_NETWORK='IP_NET_1'    # networks to masquerade (e.g. our LAN)
    ROUTE_NETWORK=''           # same as masq_networks, but packets
                               # going into these networks are not
                               # masqued, see documentation
    TRUSTED_NETS=''            # allow free and unmasqued
                               # communication between these networks

    #--------------------------------------------------------------------------
    # Host based restrictions: internal hosts to allow/deny forwarding
    #
    # FORWARD_HOST_WHITE='no'  describes a black list (forbidden)
    # FORWARD_HOST_WHITE='yes' describes a white list (allowed)
    #
    # Example:
    #   FORWARD_HOST_WHITE='no' and FORWARD_HOST_N='0':
    #    -> forwarding of 0 hosts is denied
    #    -> forwarding of all hosts is allowed
    #--------------------------------------------------------------------------
    FORWARD_HOST_WHITE='no'              # 'no': black list, 'yes': white list
    FORWARD_HOST_N='0'                   # number of allowed/denied hosts
    FORWARD_HOST_1='192.168.6.5'         # optional: 1st allowed/denied host
    FORWARD_HOST_2='@client2'            # optional: 2nd allowed/denied host

    #--------------------------------------------------------------------------
    # Port based restrictions: ports to reject/deny forwarding
    #--------------------------------------------------------------------------
    FORWARD_DENY_PORT_N='3'              # no. of ports to reject/deny
                                         # forwarding
    FORWARD_DENY_PORT_1='139 REJECT-TCP' # reject forwarding of netbios
    FORWARD_DENY_PORT_2='445 REJECT-TCP'
    FORWARD_DENY_PORT_3='137-138 REJECT-UDP'

    #--------------------------------------------------------------------------
    # Accept connections from outside to several ports (served ports)
    #--------------------------------------------------------------------------
    # INPUT_POLICY='REJECT'             # be nice and use reject as policy
                                        # already defined in new style
                                        # filter section
    INPUT_ACCEPT_PORT_N='0'             # no. of ports to accept from outside
    INPUT_ACCEPT_PORT_1='22 TCP'        # e.g. allow connection to ssh service

    #--------------------------------------------------------------------------
    # Logging
    #--------------------------------------------------------------------------
    PACKETFILTER_LOG='no'               # log access to rejected/denied ports

#------------------------------------------------------------------------------
# New style packet filter config - set NEW_FW_CONFIG='yes' to use this
# version
#------------------------------------------------------------------------------
NEW_FW_CONFIG='yes'                  # new style packet filter config: yes/no

    INPUT_POLICY='REJECT'            # be nice and use reject as policy
    INPUT_ACCEPT_DEF='yes'           # use default rule set
    INPUT_LOG='no'                   # don't log anything
    INPUT_LOG_LIMIT='3/minute:5'     # log 3 events per minute; allow a
                                     # burst of 5 events
    INPUT_REJ_LIMIT='1/second:5'     # reject 1 connection per second; allow a
                                     # burst of 5 events; otherwise
                                     # drop packet
    INPUT_UDP_REJ_LIMIT='1/second:5' # reject 1 udp packet per second; allow a
                                     # burst of 5 events; otherwise drop packet
    INPUT_LIST_N='1'
    INPUT_LIST_1='IP_NET_1 ACCEPT'   # allow all hosts in the local
                                     # network access to the router
    INPUT_LIST_2='tmpl:samba DROP NOLOG' # drop (or reject) samba access
                                         # without logging, otherwise the log
                                         # file will be filled with useless
                                         # entries

    FORWARD_POLICY='REJECT'          # be nice and use reject as policy
    FORWARD_ACCEPT_DEF='yes'         # use default rule set
    FORWARD_LOG='no'                 # don't log anything
    FORWARD_LOG_LIMIT='3/minute:5'   # log 3 events per minute; allow a
                                     # burst of 5 events
    FORWARD_REJ_LIMIT='1/second:5'   # reject 1 connection per second; allow a
                                     # burst of 5 events; otherwise
                                     # drop packet
    FORWARD_UDP_REJ_LIMIT='1/second:5'  # reject 1 udp packet per second; allow
                                        # a burst of 5 events; otherwise
                                        # drop packet
    FORWARD_LIST_N='2'
    FORWARD_LIST_1='tmpl:samba DROP' # drop samba traffic if it tries
                                     # to leave the subnet
    FORWARD_LIST_2='IP_NET_1 ACCEPT' # accept everything else

    POSTROUTING_LIST_N='1'
    POSTROUTING_LIST_1='IP_NET_1 MASQUERADE'  # masquerade traffic leaving
                                              # the subnet

    PREROUTING_LIST_N='0'
    PREROUTING_LIST_1='1.2.3.4 dynamic:22 DNAT:@client2'
                                              # forward ssh connections
                                              # coming from 1.2.3.4 to client2

#------------------------------------------------------------------------------
# Simple DMZ setup for dial-up based routers -- see documentation
#------------------------------------------------------------------------------
OPT_DMZ='no'

#------------------------------------------------------------------------------
# Optional package: PORTFW
#------------------------------------------------------------------------------
PORTFW_N='0'                          # how many portforwardings to set up
PORTFW_1_TARGET='8080'                # sample 1: forward ext. port 8080
PORTFW_1_NEW_TARGET='192.168.6.15:80' # ...to int. host 192.168.6.15 port 80
PORTFW_1_PROTOCOL='tcp'               # ...using tcp
PORTFW_2_TARGET='3000-3010'           # sample 2: forward portrange 3000-3010
PORTFW_2_NEW_TARGET='192.168.6.15'    # ...to int. host 192.168.6.15
PORTFW_2_PROTOCOL='tcp'               # ...using tcp

#------------------------------------------------------------------------------
# Masq modules
#------------------------------------------------------------------------------
MASQ_MODULE_N='1'                     # load n masq modules (default: only ftp)
MASQ_MODULE_1='ftp'                   # ftp
MASQ_MODULE_1_OPTION=''               # options, see documentation
MASQ_MODULE_2='irc'                   # irc
MASQ_MODULE_2_OPTION=''               # options, see documentation

#------------------------------------------------------------------------------
# Domain configuration:
#------------------------------------------------------------------------------
DOMAIN_NAME='lan.fli4l'               # your domain name
DNS_FORWARDERS='194.8.57.8'           # DNS servers of your provider,
                                      # e.g. ns.n-ix.net

OPT_DNS='yes'                         # start dns server: yes or no
    DNS_TRIGGER_DIAL_IN='yes'	      # trigger a dial-in before
                                      # forwarding requests
    DNS_LISTENIP_N='0'                # if 0 then listen on all interfaces
    DNS_LISTENIP_1='IP_NET_1_IPADDR'  # first IP to listen on
    DNS_VERBOSE='no'                  # log queries into syslog
    DNS_MX_SERVER=''                  # fqdn of the mx for your DOMAIN
    DNS_FORBIDDEN_N='0'               # number of forbidden domains
    DNS_FORBIDDEN_1='foo.bar'         # 1st forbidden domain
    DNS_FORBIDDEN_2='bar.foo'         # 2nd forbidden domain
    DNS_REDIRECT_N='0'                # number of redirected domains
    DNS_REDIRECT_1='foo.bar.foo'      # 1st redirected domain
    DNS_REDIRECT_1_IP='192.168.6.100' # IP of redirected domain
    DNS_BOGUS_PRIV='yes'              # fake reverse lookups for RFC1918
                                      # private address ranges
    DNS_FILTERWIN2K='yes'             # filters useless windows-originated DNS
                                      # requests and blocks all SRV requests

    # Special DNS configuration
    #--------------------------
    DNS_SPECIAL_N='0'                           # number of special
                                                # dns servers, normally 0
    #DNS_SPECIAL_1='firma.de 192.168.1.12'      # 1st special dns server
                                                # for firma.de
    #DNS_SPECIAL_2='lan.firma.de 192.168.2.12'  # 2nd special dns server
                                                # for lan.firma.de

HOSTS_N='4'                           # number of hosts in your domain
                                      # 1st host:
HOST_1_NAME='HOSTNAME'                # name or aliasname e.g. "HOSTNAME"
HOST_1_IP='IP_NET_1_IPADDR'           # IP or aliasname e.g. "IP_NET_1_IPADDR"
#HOST_1_ALIAS_N='0'                   # number of optional alias names
#HOST_1_ALIAS_1='router.lan.fli4l'    # 1st optional alias name
#HOST_1_ALIAS_2='gateway.lan.fli4l'
                                      # 2nd host:
HOST_2_NAME='client2'                 # name
HOST_2_IP='192.168.6.2'               # IP
#HOST_2_MAC='de:ad:af:fe:07:19'       # optional mac address used by dhcpd
                                      # 3rd host:
HOST_3_NAME='client3'                 # name
HOST_3_IP='192.168.6.3'               # IP
#HOST_3_MAC='de:ad:be:ef:07:19'
                                      # 4th host:
HOST_4_NAME='client4'                 # name
HOST_4_IP='192.168.6.4'               # IP
#HOST_4_MAC='de:ad:be:ef:08:15'

#------------------------------------------------------------------------------
# DNSMASQ-DHCP server
#------------------------------------------------------------------------------
OPT_DNSDHCP='no'                      # activate DHCP server: yes or no

    DNSDHCP_LS_TIME_DYN='3600'        # default time for dynamic leases: 1 hour
    DNSDHCP_MAX_LS_TIME_DYN='7200'    # max time  for dynamic leases: 2 hours
    DNSDHCP_LS_TIME_FIX='86400'       # default time for fix leases: 1 day
    DNSDHCP_MAX_LS_TIME_FIX='604800'  # max time for fix leases: 1 week
    DNSDHCP_LEASES_DIR='/boot'        # don't touch this until you
                                      # have read the manual!

    DNSDHCP_WINSSERVER_1=''           # IP-address of 1st external wins-server
                                      # (don't use if OPT_NMBD='yes'!)
    DNSDHCP_WINSSERVER_2=''           # IP-address of 2nd external wins-server
                                      # (don't use if OPT_NMBD='yes'!)

    # Parameters for local Networks
    # -----------------------------
    DNSDHCP_RANGE_1_START='192.168.6.100'     # start-IP of n'th ethernet,
                                              # see IP_NET_N
    DNSDHCP_RANGE_1_END='192.168.6.150'       # end-IP of n'th ethernet,
                                              # see IP_NET_N
    DNSDHCP_RANGE_1_DNS_SERVER=''             # if empty the IP of interface
                                              # IP_NET_N is used;
                                              # if set to 'none' no
                                              # dns-server is transmitted
    DNSDHCP_RANGE_1_NTP_SERVER=''             # if empty and OPT_CHRONY='yes'
                                              # the IP of interface IP_NET_N
                                              # is used; if set to 'none' no
                                              # ntp-server is transmitted
    DNSDHCP_RANGE_1_GATEWAY=''                # if empty the IP of interface
                                              # IP_NET_N is used;
                                              # if set to 'none' no
                                              # gateway is transmitted

    # Parameters for extra Networks (via relay)
    # -----------------------------------------
    DNSDHCP_EXTRA_RANGE_N='0'                    # number of extra ranges
    DNSDHCP_EXTRA_RANGE_1_START='192.168.8.2'    # start-IP of n'th extra range
    DNSDHCP_EXTRA_RANGE_1_END='192.168.8.50'     # end-IP of n'th extra range
    DNSDHCP_EXTRA_RANGE_1_NETMASK='255.255.255.0'  # netmask for extra range
    DNSDHCP_EXTRA_RANGE_1_DNS_SERVER='192.168.8.1' # DNS Server for extra range
    DNSDHCP_EXTRA_RANGE_1_NTP_SERVER=''          # NTP Server for extra range
    DNSDHCP_EXTRA_RANGE_1_GATEWAY='192.168.8.1'  # default gateway for
                                                 # extra range

    DNSDHCP_EXTRA_RANGE_1_DEVICE='eth0'    # device used to reach extra network


    # Deny host for dhcp-Access
    # -------------------------
    DNSDHCP_DENY_MAC_N='0'                    # number of denied MAC addresses
    DNSDHCP_DENY_MAC_1='00:01:02:03:04:05'    # MAC addess ist denied from DHCP


#------------------------------------------------------------------------------
# imond configuration:
#------------------------------------------------------------------------------
START_IMOND='no'                    # start imond: yes or no
    IMOND_USE_ORIG='yes'            # use the original version of imond instead
                                    # of the development version: yes or no
    IMOND_PORT='5000'               # port (tcp), don't open it to the outside
    IMOND_PASS=''                   # imond-password, may be empty
    IMOND_ADMIN_PASS=''             # imond-admin-password, may be empty
    IMOND_LED=''                    # tty for led: com1 - com4 or empty
    IMOND_BEEP='no'                 # beep if connection going up/down
    IMOND_LOG='no'                  # log /var/log/imond.log: yes or no
    IMOND_LOGDIR='/var/log'         # log-directory, e.g. /var/log
    IMOND_ENABLE='yes'              # accept "enable/disable" commands
    IMOND_DIAL='yes'                # accept "dial/hangup" commands
    IMOND_ROUTE='yes'               # accept "route" command
    IMOND_REBOOT='yes'              # accept "reboot" command

#------------------------------------------------------------------------------
# Generic circuit configuration:
#------------------------------------------------------------------------------
IP_DYN_ADDR='yes'                   # use dyn. IP addresses (most providers do)
DIALMODE='auto'                     # standard dialmode: auto, manual, or off

#------------------------------------------------------------------------------
# optional package: syslogd
#------------------------------------------------------------------------------
OPT_SYSLOGD='no'                       # start syslogd: yes or no
    SYSLOGD_DEST_N='1'                 # number of destinations
    SYSLOGD_DEST_1='*.* /dev/console'  # n'th prio & destination of syslog msgs
    SYSLOGD_DEST_2='*.* @192.168.6.2'  # example: loghost 192.168.6.2
    SYSLOGD_DEST_3='kern.info /var/log/dial.log'  # example: log infos to file

#------------------------------------------------------------------------------
# Optional package: klogd
#------------------------------------------------------------------------------
OPT_KLOGD='no'                      # start klogd: yes or no

#------------------------------------------------------------------------------
# Optional package: y2k correction
#------------------------------------------------------------------------------
OPT_Y2K='no'                        # y2k correction: yes or no
    Y2K_DAYS=''                     # correct hardware y2k-bug: add x days

#------------------------------------------------------------------------------
# Optional package: PNP
#------------------------------------------------------------------------------
OPT_PNP='no'                        # install isapnp tools: yes or no
\end{verbatim}
\end{example}
\end{scriptsize}

Zu beachten ist, dass diese Datei im DOS-Format gespeichert ist. Das
heißt, sie enthält jeweils am Zeilenende ein zusätzliches
Carriage-Return (CR). Da die meisten UNIX-Editoren damit keine
Probleme bekommen, habe ich mich für dieses Format entschlossen, denn
umgekehrt hat der Windows-Editor bei fehlendem CR am Zeilenende keine
Chance!

Sollte es wider Erwarten unter Unix/Linux doch Probleme mit dem
Lieblingseditor geben, kann die Datei vor dem Editieren mit einem
Befehl in das Unix-Format konvertiert werden:

\begin{example}
\begin{verbatim}
        sh unix/dtou config/base.txt
\end{verbatim}
\end{example}

Für die Erstellung der Boot-Diskette ist es völlig unerheblich, ob die
Datei CRs am Zeilenende enthält oder nicht. Sie werden beim Schreiben
auf die Bootdiskette einschließlich der Kommentare komplett ignoriert.


Jetzt aber zum Inhalt...


\section{Allgemeine Einstellungen}



\begin{description}

  \config{HOSTNAME}{HOSTNAME}{HOSTNAME}

  {Als erstes sollte man seinem fli4l-Router einen Namen geben. Im
    Beispiel ist dies {\tt fli4l}}.


  \config{PASSWORD}{PASSWORD}{PASSWORD}

  {Das hier angegebene Passwort wird für das Einloggen in den fli4l-Rechner
     benötigt - sei es per Tastatur direkt am Router oder per SSH von einem
     anderen Rechner aus (hierzu wird das sshd-Package benötigt).

    Das Passwort ist ab Version 1.5 zwingend.

    Standard-Einstellung: \var{PASSWORD}='fli4l'}


  \config{BOOT\_TYPE}{BOOT\_TYPE}{BOOTTYPE}

  Standardwert: \var{BOOT\_TYPE='fd'}

  {\var{BOOT\_TYPE} legt im weitesten Sinne das Bootmedium fest. Diese Variable
  steuert, welche zusätzlichen Treiber (Kernel-Module) und Start-Scripts mit in
  das {\tt rootfs} aufgenommen werden. Zum Verständnis eine kurze Skizze des
  Bootvorgangs:

  \begin{itemize}
  \item Das BIOS des Rechners lädt/startet den Bootloader auf dem Bootmedium.
  \item Der Bootloader (i.d.R syslinux) entpackt, lädt und startet den
        Kernel.
  \item Der Kernel entpackt das rootfs (= das grundlegende Dateisystem mit
        darin enthalten Programmen und Scripts), mountet das rootfs und
        beginnt die Start-Scripts abzuarbeiten.
  \item Je nach \var{BOOT\_TYPE} werden nun die Kernel-Module für das jeweilige
        Bootmedium geladen, die Boot-Partition gemountet und das Opt-Archiv
        ({\tt opt\_tar.bz2}) mit den zusätzlichen Programmen entpackt.
  \item Im Anschluß beginnt die Konfiguration der einzelnen Dienste des fli4l.
  \end{itemize}

  Zur Zeit sind folgende Werte für \var{BOOT\_TYPE} gültig:

  \begin{description}
  \item[fd,fd1440] Der {\it normale} Disketten-Boot von Laufwerk a:;
    wird {\em fd} angegeben, wird die Größe des Bootmediums
    automatisch ermittelt.
  \item[fd1680] Boot von Diskette mit höherer Kapazität, wiederum
    Laufwerk a:.  Die Disketten sind hierzu gesondert zu formatieren,
    näheres ist bitte dem Kapitel \jump{chap:bootmedien}{Erstellen der
      Bootdiskette} zu entnehmen. Die Angabe fd1680 ist obsolet und
      verschwindet in einer der nächsten Releases.
  \item[fdx2] Mit einem Laufwerk und zwei Disketten booten. Die Disketten
    müssen beim Booten gewechselt werden.
  \item[dualfd] Ein Disketten-Boot von den Laufwerken a:
    und b:, wobei beide Disketten gleich groß sein müssen.
    Die zweite Diskette muß bereits formatiert und leer sein.
  \item[ls120] Boot von LS120/240 Disketten. Hierzu wird das Package HD und
     der Treiber ide-floppy benötigt.
  \item[hd] Boot von Festplatte. Hierzu wird das Package HD benötigt. Näheres
            ist der \jump{sec:hdinstall}{Dokumentation} zum Package HD zu
            entnehmen.
  \item[cd,cdemul] Boot von CD-ROM. Auch hierzu wird das Package HD benötigt, weil
            dort die Treiber für CD-Laufwerke drin stecken. Es wird
            lediglich das ISO-Image fli4l.iso der CD erzeugt, welches
            anschliessend mit dem jeweiligen Lieblingsbrennprogramm selbst auf
            CD gebrannt werden muß.
            Bitte darauf achten, daß hier auch der richtige CD-Treiber ausgewählt
            wurde, ide-cd ist nur für IDE-Laufwerke, scsi-cd alleine funktioniert
            nicht, hier ist unbedingt auch noch der passende SCSI-Hostadapter-Treiber
            auszuwählen.
            cdemul ist eine Alternative für älteren Boards wo cd nicht funktioniert.
  \item[integrated] Bei diesem Typ wird kein Bootmedium zu grunde gelegt,
                    sondern das Opt-Archiv vollständig ins {\tt rootfs}
                    integriert. Somit entfällt das Mounten des Bootmediums
                    und der Kernel kann gleich alles entpacken. Dieser
                    \var{BOOT\_Type} wird z.B. fürs Booten vom Netzwerk
                    benötigt.\\
                    {\bf Hinweis: } Ein remote Update ist natürlich in diesem
                    Fall nicht möglich.
  \item[attached] Ähnlich wie {\bf integrated}, jedoch wird das
                  Opt-Archiv als Datei {\tt opt\_tar.bz2} ans {\tt rootfs}
                  angehängt, mit der Folge, daß es wieder im Verzeichnis
                  {\tt /boot} zu finden ist und gesondert beim Bootvorgang
                  entpackt wird.\\
                  Ansonsten gilt das unter {\tt integrated} gesagte.
  \item[netboot] Entspricht {\bf integrated}. Es wird jedoch zusätzlich das
                 Script {\tt mknetboot.sh} gestarted, welches ein Image zum
                 Booten via LAN erzeugt. Weiteres ist bitte dem {\it Mini-How
                 fuer fli4l und Netzboot} zu entnehmen.\\
                 {\bf Hinweis:} fli4l bringt weder eine Ether- oder
                 Netbootumgebung mit. Diese ist gesondert zu installieren!
  \end{description}
  }


  \config{MOUNT\_BOOT}{MOUNT\_BOOT}{MOUNTBOOT}

  {Hier wird eingestellt, wie die Boot-Diskette gemountet werden
    soll. Es gibt 3 Möglichkeiten:

    \begin{description}
    \item[rw] -- Read/Write -- Schreiben und Lesen ist möglich
    \item[ro] -- Read-Only -- Nur Lesen ist möglich
    \item[no] -- None -- Diskette wird nach dem Boot wieder
      abgemeldet und kann dann bei Bedarf entnommen werden.
    \end{description}

    Bei bestimmten Konfigurationen ist es unbedingt erforderlich, die
    Diskette Read/\-Write anzumelden, z.B. wenn man den DHCP-Server
    einsetzen oder die imond-Log-Datei auf der Diskette anlegen
    möchte.

    Standard-Einstellung: \var{MOUNT\_\-BOOT}='rw'}

  \config{TIME\_INFO}{TIME\_INFO}{TIMEINFO}

  Uhren ticken in der Unix-Welt und damit auch unter fli4l
  normalerweise nach der UTC (Coordinated Universal Time), einer
  weltweit einheitlichen Uhrzeit, die vor der Verwendung in die lokale
  Zeit umgerechnet wird. \var{TIME\_\-INFO} liefert fli4l die dafür
  notwendigen Informationen über die Namen der Zeitzonen, die
  Differenz zu UTC und Regeln, wann auf Sommerzeit und wieder zurück
  gewechselt wird. Damit das korrekt funktioniert, muß die Hardware
  Uhr auf UTC gestellt werden (entspricht der Londoner Winterzeit)
  oder über das Paket chrony mit einem Timeserver synchronisiert werden
  (diese liefern UTC aus).

  Die Einträge in \var{TIME\_\-INFO} bedeuten dabei folgendes:
\begin{example}
\begin{verbatim}
        TIME_INFO='MEZ-1MESZ,M3.5.0,M10.5.0'
\end{verbatim}
\end{example}
  \begin{itemize}
  \item {\em MEZ-1:} Wir befinden uns in der mitteleuropäischen
    Zeitzone ({\em MEZ}, die der UTC eine Stunde voraus ist {\em MEZ-1=UTC}.


  \item {\em MESZ:} In dieser Zeitzone gibt es Sommerzeit
    (Mitteleuropäische Sommerzeit). Da nichts weiter angegeben wird,
    kommt man zur Sommerzeit, indem man die Zeit eine Stunde
    vorstellt.
  \item {\em M3.5.0,M10.5.0':} Am letzten Sonntag im März wird zur Sommerzeit
    gewechselt, am letzten Sonntag im Oktober wieder zurück.
  \end{itemize}

  Normalerweise braucht man diesen Wert nie anzufassen, es sei denn
  man sitzt in einer anderen Zeitzone. Will man die Werte anpassen,
  sollte man einen Blick auf die Spezifikation der Umgebungsvariable
  TZ werfen, die unter folgender URL zu finden ist (englisch):
  \link{http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd\_chap08.html}


  \config{KERNEL\_VERSION}{KERNEL\_VERSION}{KERNELVERSION}

  Legt die Version des zu verwendenden Kerns fest. Entsprechend dieser
Variable werden  der Kern aus {\em img/kernel-$<$kernel
version$>$.$<$compression extension$>$} und die Kernel-Module aus {\em
opt/files/lib/modules/$<$kernel version$>$} selektiert.

  \config{KERNEL\_BOOT\_OPTION}{KERNEL\_BOOT\_OPTION}{KERNELBOOTOPTION}

  Der Inhalt dieser Variable wird an die Kommandozeile des Kerns in
  der syslinux.cfg angehängt.
  Für Systeme ohne Tastatur-Controller bietet sich hier 'nokbd' an.
  Manche Systeme benötigen für korrekten Reboot 'reboot=bios'.
  Bei WRAP-Systemen also 'nokbd reboot=bios'.

  \config{COMP\_TYPE\_KERNEL}{COMP\_TYPE\_KERNEL}{COMPTYPEKERNEL}

  Der Inhalt dieser Variable legt den Type der Kompression für den Kernel fest.
  Mögliche Werte sind 'gzip' und 'bzip2'

  \config{COMP\_TYPE\_ROOTFS}{COMP\_TYPE\_ROOTFS}{COMPTYPEROOTFS}

  Der Inhalt dieser Variable legt den Type der Kompression für das rootfs fest.
  Mögliche Werte sind 'gzip' und 'bzip2'

  \config{IP\_CONNTRACK\_MAX}{IP\_CONNTRACK\_MAX}{IPCONNTRACKMAX}

  Mit Hilfe dieser Variable kann man die maximale mögliche Anzahl gleichzeitiger
  Verbindungen manuell einstellen. Normalerweise wird anhand des eingebauten
  Arbeitsspeichers automatisch ein sinnvoller Wert ermittelt, wobei folgende
  Voreinstellungen verwendet werden:

    \smalljump{tab:connectiontracking}{Automatische Einstellung der maximalen Verbindungsanzahl}.
    \begin{center}
      \begin{small}
        \begin{longtable}[thbp]{p{6cm}p{6cm}}
          Arbeitsspeicher in MiB   &    gleichzeitige Verbindungen \\
          \hline
          16                      &    1024 \\
          24                      &    1280 \\
          32                      &    2048 \\
          64                      &    4096 \\
          128                     &    8192 \\

          \caption{Automatische Einstellung der maximalen Verbindungsanzahl}
          \marklabel{tab:connectiontracking}{}
        \end{longtable}
      \end{small}
    \end{center}

   Bei Einsatz von FileSharing-Programmen hinter oder auf dem Router und wenig
   Arbeitsspeicher ist die maximale Anzahl gleichzeitiger Verbindungen aber
   sehr schnell erreicht und zusätzliche Verbindungen können nicht mehr
   aufgebaut werden.\\
   Das äußert sich in Fehlermeldungen wie


\begin{example}
\begin{verbatim}
        ip_conntrack: table full, dropping packet
\end{verbatim}
\end{example}

oder

\begin{example}
\begin{verbatim}
        ip_conntrack: Maximum limit of XXX entries exceeded
\end{verbatim}
\end{example}

    Mittels \var{IP\_\-CONNTRACK\_\-MAX} lässt sich nun die maximale
    Anzahl gleichzeitiger Verbindungen fest auf einen bestimmten Wert
    einstellen.
    Aber seid gewarnt. Jede einzelne mögliche Verbindung kostet 350 Bytes
    an Arbeitsspeicher, der nicht mehr für andere Dinge genutzt werden kann.
    Setzt man also 10000, so sind gerundet 3,34 MB Arbeitsspeicher für den
    normalen Gebrauch verloren (Kernel, Ramdisks, Programme).

    Bei 32 MiB RAM sollte es kein Problem sein, mal eben 2 oder 3 MiB für die
    ip\_conntrack-Tabelle zu reservieren, bei 16 MiB wird es knapp und bei 12
    oder sogar 8 MiB ist absolute Sparwut angesagt.

    Die momentan benutze Einstellung lässt sich auf der Konsole mit

\begin{example}
\begin{verbatim}
        cat /proc/sys/net/ipv4/ip_conntrack_max
\end{verbatim}
\end{example}

    anzeigen und mit

\begin{example}
\begin{verbatim}
        echo "XXX" > /proc/sys/net/ipv4/ip_conntrack_max
\end{verbatim}
\end{example}

    zur Laufzeit setzen, wobei XXX für die Anzahl der Einträge steht.
    Die Einträge in der IP\_CONNTRACK-Tabelle selbst können auf der Konsole
    mit

\begin{example}
\begin{verbatim}
        cat /proc/net/ip_conntrack
\end{verbatim}
\end{example}

    angesehen und mit

\begin{example}
\begin{verbatim}
        cat /proc/net/ip_conntrack | grep -c use
\end{verbatim}
\end{example}

    gezählt werden.

    Standard-Einstellung: \var{IP\_\-CONNTRACK\_\-MAX}=''

  \config{POWEROFF\_ON\_HALT}{POWEROFF\_ON\_HALT}{POWEROFFONHALT}

  Wird diese Option auf yes gesetzt, versucht fli4l bei einem {\em
    halt} den Router via APM auszuschalten. Voraussetzung dafür ist
  ein Rechner mit einem ATX-Netzteil und einem APM-fähigen BIOS.

  \config{REAL\_MODE\_POWEROFF}{REAL\_MODE\_POWEROFF}{REALMODEPOWEROFF}

  Bei manchen BIOS-Versionen muß Linux vor dem Aufruf einer
  APM-Funktion erst in einen speziellen Prozessormodus
  wechseln. Aktivieren sollte man diese Option, wenn das Auschalten
  ohne nicht funktioniert.

  \config{IGNORE\_KSOFTIRQ}{IGNORE\_KSOFTIRQ}{IGNOREKSOFTIRQ}

  Standard-Einstellung: \var{IGNORE\_KSOFTIRQ}='no'

  Wenn der fli4l-Router als reiner eth-Router eingesetzt werden soll
  ist das IRQ Handling des Linux Kernels nicht optimal. Bedingt durch
  die hohe Interruptlast sinkt die mögliche Datenübertragungsrate
  unnötig. Wenn \var{IGNORE\_KSOFTIRQ}='yes' gesetzt wird schaltet der
  Linuxkernel auf eine andere Art der Interruptbehandlung um. Mit der
  Einstellung 'yes' steigt die Datenübertragungsrate bei reinem
  eth-Routern deutlich. Die Einstellung kann auch zur Laufzeit durch
  Schreiben von '0' (für 'no') und '1' (für 'yes') in
  /proc/sys/kernel/ignore\_ksoftirq geändert werden.

  Details zu dem geänderten Verhalten finden Sie auf der Website\\
  \link{http://www.ussg.iu.edu/hypermail/linux/kernel/0112.2/1414.html}.

  \config{LOCALE}{LOCALE}{LOCALE}
  
  Standardeinstellung: \var{LOCALE}='de'
  
  Einige Komponenten sind mittlerweile mehrsprachfähig. Dazu zählen
  beispielsweise das Consolen-Menü und die Weboberfläche. Mit dieser Variablen
  können Sie die bevorzugte Sprache auswählen. Verschiedene Komponenten haben
  noch eine eigene Einstellung womit diese Grundeinstellung, wenn nötig,
  überlistet werden kann. Wenn die hier angegebene Sprache bei einem Komponenten
  (noch) nicht verfügbar ist, wird auf Englisch zurückgefallen.
  
  Wenn \var{KEYBOARD\_LOCALE}='auto' wird versucht ein zu der
  \var{LOCALE}-Einstellung passendes Tastatur-Layout ein zu stellen.
  
  Bisher sind folgende Einstellungen möglich: de, en, fr, nl.

\end{description}

\section{Einbinden von zusätzlicher Diskette}

\begin{description}
  \config{OPT\_FLOPPYMOUNT}{OPT\_FLOPPYMOUNT}{OPTFLOPPYMOUNT}
  In einigen Konfiguration (z.b. bei Boot von CD oder Netzwerk)
  ist das Einbinden einer Diskette bzw. einer zusätzlichen Diskette
  um z.b. die LOG-Dateien oder die DHCP-Lease-Datei zu speichern sinnvoll.
  Mit \var{OPT\_FLOPPYMOUNT}='first' wird das erste Diskettenlaufwerk (a:)
  unter dem Verzeichnis /floppy in das Dateiensystem eingebunden, mit
  \var{OPT\_FLOPPYMOUNT}='second' das zweite Laufwerk.
  Mit \var{OPT\_FLOPPYMOUNT}='no' wird das Einbinden deaktiviert.
\end{description}


\section{Konsolen-Einstellungen}

\begin{description}
  \config{CONSOLE\_BLANK\_TIME}{CONSOLE\_BLANK\_TIME}{CONSOLEBLANKTIME}
  Normalerweise aktiviert der Linux-Kern nach einer gewissen Zeit ohne
  Eingaben auf dem aktuellen Eingabegerät den Bildschirmschoner. Mit
  \var{CONSOLE\_BLANK\_TIME} kann man diese Zeit konfiguriereren
  bzw. den Bildschirmschonermodus ganz deaktivieren
  (\var{CONSOLE\_BLANK\_TIME}='0').

  \config{SER\_CONSOLE}{SER\_CONSOLE}{SERCONSOLE}

    Fli4l kann gänzlich ohne Tastatur und Grafikkarte eingesetzt
    werden. Damit man den Router auch ohne Telnet oder SSH bedienen
    sowie alle Boot-Meldungen sehen kann, ist es möglich, die Ein- und
    Ausgaben auf die serielle Schnittstelle umzuleiten. Dazu muß
    \var{SER\_CONSOLE}, \var{SER\_CONSOLE\_IF} sowie
    \var{SER\_CONSOLE\_RATE} angepasst werden.

      Die serielle Konsole kann in drei Modi betrieben werden:

      \begin{tabular}[h!]{|l|p{9cm}|}
        \hline
        \var{SER\_CONSOLE} & Konsolen-Ein-/Ausgabe \\
        \hline
        no & Ein- und Ausgabe über tty0 \\
        yes & Ein- und Ausgabe über serielle Konsole \\
        primary & Ein- und Ausgabe über serielle Konsole, Ausgabe
        zusätzlich über tty0 \\
        secondary & Ein- und Ausgabe über tty0, Ausgabe zusätzlich
        über serielle Konsole,  \\
        \hline
      \end{tabular}

      Standard-Einstellung: \var{SER\_CONSOLE}='no'

%    mkfli4l generiert die vom Bootloader verwendete Konfigurationsdatei aus
%    einer Vorlage namens {\em syslinux.tmpl
%    (img/syslinux.tmpl)}\marklabel{SYSLINUXTEMPL}{}, in die abhängig von der
%    Konfiguration zusätzliche Dinge eingetragen werden. Will man die
%    Boot-Parameter des Kerns um weitere Parameter ergänzen, kann man
%    sie an die
%    {\em APPEND}-Zeile dieser Datei nach dem Text {\em  root=/dev/tmpfs} anhängen,
%    die Paramter werden dann automatisch in die Konfigurationsdatei des
%    Bootloaders übernommen.

    Wenn der Wert von \var{SER\_CONSOLE} verändert wird, wird diese
    Änderung nur bei der Erstellung einer neue Diskette oder beim
    remote-Update der syslinux.cfg wirksam.

    Achten Sie beim Ausschalten der Seriellen Console darauf, sich einen
    alternativen Zugang zum Router (ssh oder direkt an der Tastatur) zu
    erhalten.

    Weitere Informationen sind im Anhang unter
    \jump{SERIALCONSOLE}{Serielle Console} zu finden.


  \config{SER\_CONSOLE\_IF}{SER\_CONSOLE\_IF}{SERCONSOLEIF}
  {Nummer der seriellen Schnittstelle für die Consolenausgabe.

    Hier ist die Nummer der Schnittstelle einzutragen, an die die serielle
    Console angeschlossen wird.
    0 entspricht ttyS0 bzw. COM1 in der DOS-Welt.}


  \config{SER\_CONSOLE\_RATE}{SER\_CONSOLE\_RATE}{SERCONSOLERATE}
  {Übertragungsrate der seriellen Schnittstelle für die Consolenausgabe.

    Hier trägt man die Baud-Rate ein, mit der die Daten auf der
    seriellen Schnittstelle übertragen werden.  Sinnvolle Werte: 4800,
    9600, 19200, 38400, 57600, 115200}

  \config{SER\_BEEP}{SER\_BEEP}{SERBEEP}
  {Signalton am Ende des Boot- und Shutdownprozesses ausgeben.

    Trägt man hier 'yes' ein, ertönt auch mit aktiver serieller Console
    ein Signalton am Ende des Boot- und Shutdownprozesses. Dazu wird
    ein kleines Binary (knapp 1,9KiB) auf den Router übertragen. Wer extremen
    Platzmangel auf der Diskette hat, sollte hier also 'no' eingetragen lassen.}

\end{description}


\section{Loggen der Bootsequenz}

Manchmal ist es sinnvoll, bei Problemen einen Trace der Start-Sequenz
zu generieren um den Bootvorgang hinterher auf Probleme untersuchen zu
können. Dazu dienen \var{DEBUG\_STARTUP} und \var{DEBUG\_LOG}.

\begin{description}

  \config{DEBUG\_STARTUP}{DEBUG\_STARTUP}{DEBUGSTARTUP}

  { Steht dieser Wert auf 'yes', wird beim Booten jedes ausgefuehrte
    Kommando vor seiner Ausführung auf den Schirm geschrieben. Da für
    das korrekte Funktionieren Änderungen an der syslinux.cfg
    vorgenommen werden müssen, gilt das fuer \var{SER\_CONSOLE}
    gesagte auch hier. Will man die syslinux.cfg von Hand ergänzen,
    muss man ein fli4ldebug=yes einfügen. \var{DEBUG\_STARTUP} muß
    dann aber trotzdem auf 'yes' stehen.  }

  \config{DEBUG\_LOG}{DEBUG\_LOG}{DEBUGLOG}

  { Möchte man den Trace nicht nur über den Schirm rollen sehen,
    sondern in einer Datei haben, kann man hier den Namen einer Datei
    angeben, in der der Trace am Ende des Bootvorganges landen soll.
    Er wird während des Bootens nach /tmp/boot.log geschrieben und am
    Ende umkopiert. Auf dem Schirm sieht man dann beim Booten
    nichts. Die syslinux.cfg-Variable dazu heißt:
    fli4ldeblog=filename.
  }
\end{description}

\section{Verwendung einer eigenen /etc/inittab}
  Man kann von Init zusätzliche Programme auf
  zusätzlichen Konsolen starten lassen oder die Standardkommandos der
  Init-Konfigurationsdatei verändern. Ein Eintrag sieht wie folgt
  aus:

  \begin{example}
  \begin{verbatim}
    device:runlevel:action:command
  \end{verbatim}
  \end{example}

  Das {\em device} ist das Gerät, über das das Programm seine
  Ein-/Ausgaben machen soll. Möglich sind hier die normalen Terminals
  tty1-tty4 oder serielle Terminals ttyS0-ttySn mit $n < Anzahl$ der
  vorhandenen seriellen Schnittstellen.

  Als {\em action} kommen in der Regel {\em askfirst} oder {\em
    respawn} in Frage. Bei askfirst wird auf einen tastendruck
  gewartet, bevor das Kommando ausgeführt wird, bei respawn wird es
  automatisch neu gestartet, wenn sich das Programm beendet.

  {\em command} ist das Programm, das ausgeführt werden soll. Es
  ist mit vollständiger Pfadangabe zu spezifizieren.

  Die Busybox-Dokumentation unter \link{www.busybox.net} enthält eine
  genaue Beschreibung des inittab Formats.

  Die normale inittab sieht wie folgt aus:

  \begin{example}
  \begin{verbatim}
::sysinit:/etc/rc
::respawn:/usr/local/bin/mini-login
::ctrlaltdel:/sbin/reboot
::shutdown:/etc/rc0
::restart:/sbin/init
  \end{verbatim}
  \end{example}

  Diese könnte man z.B. um den Eintrag

  \begin{example}
  \begin{verbatim}
tty2::askfirst:/usr/local/bin/mini-login
  \end{verbatim}
  \end{example}

  erweitern, um ein zweites Login auf Terminal zwei zu bekommen. Dazu
  einfach die Datei opt/etc/inittab nehmen, nach $<$config
  verzeichnis$>$/etc/inittab kopieren und mit einem Editor bearbeiten.

\section{Menusystem für die Bedienung des Routers}

Wenn man am Router das Passwort eingibt (was für den Betrieb als Router nicht
notwendig ist!) um Fehlersuche zu betreiben landet man auf einer Unix-Shell.
Damit kann allerdings nicht jeder umgehen. Für diese User gibt es jetzt ein
Menü, mit welchem diverse Diagnoseschritte durchgeführt werden können. Das Menü
erscheint nach dem Login am Router an Stelle der Unix-Shell.

\begin{description}

  \config{OPT\_MENU}{OPT\_MENU}{OPTMENU}

  { Steht dieser Wert auf \var{'yes'}, wird das Menu nach dem Login angezeigt.
  Die Auswahl eines Punktes erfolgt über die Zahlen vor den Menüpunkten.
  Falls man trotzdem mal direkten Zugriff auf die Shell benötigt kann das
  Menü mit CTRL-C beenden und mit {\tt menu.sh} wieder starten. Die
  Default-Sprache wird mit der Variablen \var{LOCALE} festgelegt. Derzeit
  sind Deutsch (de), Englisch (en), Französich (fr) und Niederländisch (nl)
  möglich. Per Menüpunkt am Router kann jederzeit auf eine andere Sprache
  umgeschaltet werden. }

  \config{MENU\_LANGUAGE}{MENU\_LANGUAGE}{MENULANGUAGE}

  { Hiermit kann die Sprache des Menüs eingestellt werden. Wenn leer wird
  die bei \var{LOCALE} angegebene Sprache verwendet. }
  
\end{description}

\section{Länderspezifische Tastaturlayouts}

\begin{description}

  \config{KEYBOARD\_LOCALE}{KEYBOARD\_LOCALE}{KEYBOARDLOCALE}

  Wenn man öfter direkt auf dem fli4l Router arbeitet ist ein lokales
  Tastaturlayout eine willkommene Hilfe. Mit
  \var{KEYBOARD\_LOCALE='auto'} wird versucht ein Tastaturlayout passend zu
  der Einstellung von \var{LOCALE} zu benutzen. Mit der
  Einstellung \var{''} wird kein lokales Tastaturlayout auf dem
  fli4l--Router installiert; es wird dann das im Kernel anwesende
  Standardlayout verwendet. Alternativ kann man auch den Namen einer
  lokalen Tastaturlayoutmap direkt angeben. Wenn z.B. \var{'de-latin1'}
  eingestellt wird, prüft der Buildprozess ob in opt/etc eine Datei mit
  Namen de-latin1.map vorliegt. Wenn ja, wird die entsprechende .map-Datei
  als Tastaturlayout eingebunden.

\end{description}

\begin{description}

  \config{OPT\_MAKEKBL}{OPT\_MAKEKBL}{OPTMAKEKBL}

  Wenn man für seine Tastatur eine map Datei erstellen will muss man
  wie folgt vorgehen:

\begin{itemize}

  \item \var{OPT\_MAKEKBL} auf 'yes' setzen. 

  \item Auf dem Router 'makekbl.sh' anrufen, entweder auf dem Prompt oder
  über das Menüpunkt. Vorzugsweise macht man dies über eine ssh-Verbindung
  weil das Tastaturlayout sich ändert und das lästig sein kann.
  
  \item Die Anweisungen befolgen.

  \item Ihre neue $<$locale$>$.map Datei liegt in der /tmp.

  Die Arbeiten direkt auf dem Router sind jetzt abgeschlossen.

\item Kopieren Sie die eben erzeugte Tastaturtabelle in Ihr fli4l
Verzeichnis unter opt/etc/$<$locale$>$.map. Wenn Sie jetzt
\var{KEYBOARD\_LOCALE}='$<$locale$>$' setzen wird beim nächsten
Buildprozess Ihre neu erzeugtes Tastaturlayout benutzt.

\item Vergessen Sie nicht \var{OPT\_MAKEKBL} wieder auf 'no' zu setzen.

\end{itemize}

\end{description}

\section{Ethernet/Tokenring-Netzwerkkarten-Treiber}

\begin{description}
  \config{NET\_DRV\_N}{NET\_DRV\_N}{NETDRVN}

  {Anzahl der benötigten Netzwerkkarten-Treiber.

    Wird der Router nur fuer ISDN verwendet, so gibt es in der Regel
    nur eine Netzwerkkarte, der Standard-Wert ist also 1. Bei DSL
    werden jedoch meistens zwei Netzwerkkarten verwendet.

    Hierbei muss man zwei Fälle unterscheiden:
    \begin{enumerate}
    \item Beide Karten sind vom gleichen Typ. Dann muss nur ein
      Treiber geladen werden, der dann beide Karten anspricht, also
      \var{NET\_\-DRV\_\-N}='1'.

    \item Es werden zwei verschiedene Karten verwendet, dann muss man
      hier `2' angeben und den Treiber fuer die zweite Karte
      angeben.
    \end{enumerate}
    }


  \configlabel{NET\_DRV\_x\_OPTION}{NETDRVxOPTION}
  \config{NET\_DRV\_x NET\_DRV\_x\_OPTION}{NET\_DRV\_x}{NETDRVx}

  {Hier wird der Treiber für die Netzwerkkarte angegeben\footnote{ Für
    Tokenring ist die Dokumentation etwas dünn, hier wäre ein wenig
    Dokumentation eines Tokenring-Nutzers erforderlich. Im Anhang ist
    ein Auszug der Configure.help-Datei des Linux-Kerns zu finden, das
    als Starthilfe dienen kann ...}.

    Über die Variable \var{NET\_\-DRV\_\-1} wird standardmäßig der
    Treiber für eine NE2000-kompatible Netzwerkkarte geladen. Weitere
    verfügbare Treiber für eine große Anzahl von
    Netzwerkkartenfamilien sind bereits in der Beispiel-Datei
    eingetragen.

    Die 3COM EtherLinkIII (3c509) muß über das Dostool 3c509cfg.exe
    (beziehbar von
    \link{ftp://ftp.ihg.uni-duisburg.de/Hardware/3com/3c5x9n/3C5X9CFG.EXE})

    konfiguriert werden. Dabei sollten irq und io-Port und
    gegebenenfalls auch der Anschluß (BNC/TP) eingestellt werden. Der
    Eintrag \var{NET\_\-DRV\_\-x\_\-OPTION}='' kann in der Regel leer bleiben.

    Bei manchen ISA-Karten braucht der Treiber zusätzliche
    Informationen, um die Karte zu finden, z.B. die I/O-Adresse. Bei
    NE2000-kompatiblen ISA-Karten und bei der EtherExpress16 ist dies
    zum Beispiel der Fall.

    Hier ist z.B.
\begin{example}
\begin{verbatim}
        NET_DRV_x_OPTION='io=0x340'
\end{verbatim}
\end{example}

    zu setzen (oder der entsprechende numerische Wert).

    Ist keine Option nötig, kann die Variable leer gelassen werden.

    Sind mehrere Optionen nötig, sind diese durch Leerzeichen zu trennen, z.B.
\begin{example}
\begin{verbatim}
        NET_DRV_x_OPTION='irq=9 io=0x340'
\end{verbatim}
\end{example}

    Werden zwei identische Netzwerkkarten verwendet, z.B.
    NE2000-ISA-Karten, müssen die verschiedenen I/O-Werte durch Komma
    getrennt werden, also

\begin{example}
\begin{verbatim}
        NET_DRV_x_OPTION='io=0x240,0x300'
\end{verbatim}
\end{example}

    Die beiden IO-Werte müssen durch Komma ohne Blank getrennt werden!

    Dieses funktioniert nicht bei allen Netzwerkkarten-Treibern.
    Einige muss man auch doppelt laden, also dann \var{NET\_\-DRV\_\-N}='2'. In
    diesem Fall müssen aber mit der Option ``-o'' verschiedene Namen
    vergeben werden, z.B.

\begin{example}
\begin{verbatim}
          NET_DRV_N='2'
          NET_DRV_1='3c503'
          NET_DRV_1_OPTION='-o 3c503-0 io=0x280'
          NET_DRV_2='3c503'
          NET_DRV_2_OPTION='-o 3c503-1 io=0x300'
\end{verbatim}
\end{example}

    Da ich in meinem fli4l-Router keine 2 Netzkwerkkarten habe, kann
    ich leider nicht mehr dazu sagen. Mein Tip: erst die Komma-Methode
    ausprobieren, danach das mehrfache Laden mit Option ``-o''
    versuchen.

    \wichtig{Wer zwei NE-Clones verwendet, und zwar jeweils eine ISA-
      und eine PCI-Karte, musste in der 2.0.x für die ISA-Karte
      zusätzlich `probe\_pci=0' als Option angeben. Diese option wird
      jetzt nicht mehr benötigt.}

    Wer mit 2 Netzwerkkarten Erfahrungen gesammelt hat, kann mir diese
    gerne mitteilen. Ich werde sie dann in die Dokumentation
    einfließen lassen.

    Nachfolgend noch einige Beispiele von Netzwerkkarten:

    \begin{itemize}
    \item 1 x NE2000 ISA
\begin{example}
\begin{verbatim}
          NET_DRV_1='ne'
          NET_DRV_1_OPTION='io=0x340'
\end{verbatim}
\end{example}

    \item  1 x 3COM EtherLinkIII (3c509)
\begin{example}
\begin{verbatim}
          NET_DRV_1='3c509'
          NET_DRV_1_OPTION=''
\end{verbatim}
\end{example}
      Siehe zu dieser Karte auch

      \link{http://extern.fli4l.de/fli4l\_faqengine/faq.php?display=faq\&faqnr=132\&catnr=7\&prog=1\&lang=de\&onlynewfaq=16\&layout=def}\\
      \link{http://extern.fli4l.de/fli4l\_faqengine/faq.php?display=faq\&faqnr=133\&catnr=7\&prog=1\&lang=de\&onlynewfaq=16\&layout=def}\\
      \link{http://extern.fli4l.de/fli4l\_faqengine/faq.php?display=faq\&faqnr=135\&catnr=7\&prog=1\&lang=de\&onlynewfaq=16\&layout=def}\\

    \item 2 x NE2000 ISA
\begin{example}
\begin{verbatim}
          NET_DRV_1='ne'
          NET_DRV_1_OPTION='io=0x320,0x340'
\end{verbatim}
\end{example}
      Oft muss man hier noch die IRQ-Werte mit angeben, also

\begin{example}
\begin{verbatim}
          NET_DRV_1_OPTION='io=0x320,0x340 irq=3,5'
\end{verbatim}
\end{example}

      Man sollte es hier zunächst ohne Angabe der Interrupts probieren
      und lediglich dann die Interrupts eintragen, wenn ohne Angabe
      der Interrupts die Netzwerkkarten nicht gefunden werden.

    \item 2 x NE2000 PCI
\begin{example}
\begin{verbatim}
          NET_DRV_1='ne2k-pci'
          NET_DRV_1_OPTION=''
\end{verbatim}
\end{example}
    \item  1 x NE2000 ISA, 1 x NE2000 PCI
\begin{example}
\begin{verbatim}
          NET_DRV_1='ne'
          NET_DRV_1_OPTION='io=0x340'
          NET_DRV_2='ne2k-pci'
          NET_DRV_2_OPTION=''
\end{verbatim}
\end{example}
    \item 1 x SMC WD8013, 1 x NE2000 ISA
\begin{example}
\begin{verbatim}
          NET_DRV_1='wd'
          NET_DRV_1_OPTION='io=0x270'
          NET_DRV_2='ne2k'
          NET_DRV_2_OPTION='io=0x240'
\end{verbatim}
\end{example}
    \end{itemize}


    Eine Liste der möglichen Treiber (s.a. die vollständige Liste
    in config/base.txt) finden Sie in der
    \smalljump{tab:kartentreiber}{Tabelle der Kartentreiber}.
    \begin{center}
      \begin{small}
        \begin{longtable}[thbp]{p{3cm}p{9cm}}
          \var{NET\_\-DRV\_\-x}   &         Kartenfamilie \\
          \hline
          `3c503'       &    3COM EtherLinkII (3c503)\\
          `3c505'       &    3COM Etherlink Plus (3c505)\\
          `3c507'       &    3COM Etherlink 16 (3c507)\\
          `3c509'       &    3COM EtherLinkIII (3c509)\\
          `3c515'       &    3COM EtherLink XL ISA (3c515)\\
          `3c59x'       &    3COM Vortex/Boomerang 3c59x,3c900,3c905\\
          `8139cp'      &    RealTek 8139C+\\
          `8139too'     &    RealTek 8129/8139 10/100 MB (NEW)\\
          `82596'       &    Apricot Xen-II on board Ethernet\\
          `ac3200'      &    Ansel Communications AC3200 EISA\\
          `acenic'      &    Alteon AceNIC Gigabit Ethernet\\
          `at1700'      &    AT1700 (Fujitsu 86965) ISA\\
          `cs89x0'      &    IBM Etherjet, cs89x0 based Cards (Option io=0xnnn necessary!)\\
          `de4x5'       &    Digital DE425, DE434, DE435, DE450, DE500\\
          `depca'       &    DEPCA, DE10x, DE200, DE201, DE202, DE422\\
          `dgrs'        &    Digi International RightSwitch PCI/EISA\\
          `dl2k'        &    D-Link DL2000-based Gigabit Ethernet Adapter\\
          `dmfe'        &    DM9102 compatible PCI cards from Davicom\\
          `e1000'       &    Intel EtherExpress PRO/1000 Gigabit Ethernet\\
          `e100'        &    Intel's original driver for EEPRO100\\
          `e2100'       &    Cabletron E21xx ISA\\
          `eepro100'    &    Intel EtherExpressPro PCI 10+/100B/100+\\
          `eepro'       &    Intel EtherExpress Pro/10\\
          `eexpress'    &    EtherExpress16 ISA\\
          `epic100'     &    SMC EPIC/100 (EtherPower II) PCI\\
          `eth16i'      &    ICL EtherTeam 16i/32\\
          `ewrk3'       &    EtherWORKS 3 ISA (DE203, DE204, DE205)\\
          `fealnx'      &    ASOUND LAN 8139 card - not RTL8139 (NEW)\\
          `hamachi'     &    GNIC-II Gigabit Ethernet\\
          `hp100'       &    HP 10/100VG PCLAN (ISA, EISA, PCI)\\
          `hp'          &    HP PCLAN (27245, 27xxx) ISA\\
          `hp-plus'     &    HP PCLAN+ (27247B and 27252A) ISA\\
          `lance'       &    AMD LANCE and PCnet (AT1500, NE2100) ISA\\
          `lp486e'      &    Intel Professional Workstation/panther ethernet driver\\
          `natsemi'     &    National Semiconductor\\
          `ne2k-pci'    &    NE2000 PCI clone (eg. Realtek 8029, Winbond 89c940)\\
          `ne'          &    NE2000 ISA clone (eg. Realtek 8019, Accton 16xx, NatSemi 8390, UMC 9003/9008)\\
          `ni5010'      &    MiCom-Interlan NI5010\\
          `ni52'        &    NI5210 card (i82586 Ethernet chip)\\
          `ni65'        &    ni6510 (am7990 'lance' chip)\\
          `ns83820'     &    cards with National Semiconductor 83820 chip\\
          `pcnet32'     &    AMD PCI PCnet32\\
          `sis900'      &    SiS 900/7016\\
          `sk98lin'     &    SysKonnect Gigabit Ethernet Server Adapters\\
          `smc9194'     &    SMC's 9000 series of Ethernet cards\\
          `smc-ultra'   &    SMC ULTRA\\
          `starfire'    &    Starfire\\
          `sundance'    &    DFE-550FX or DFE-530TXS (NEW)\\
          `tg3'         &    Broadcom Tigon3\\
          `tlan'        &    TI ThunderLAN (Compaq Netelligent ...)\\
          `tulip'       &    DECchip Tulip (dc21x4x) PCI\\
          `via-rhine'   &    VIA Rhine PCI (3043, VT86c100A, dfe-530tx)\\
          `wd'          &    SMC WD80*3\\
          `winbond-840' &    Winbond 840\\
          `sunhme'      &    Sun Happy Meal 10/100baseT support (only QFE is tested)\\
          `yellowfin'   &    Packet Engines G-NIC PCI Gigabit Eth Adapter\\
          `hostap\_pci' &    Prism 2.5 based PCI Wlan Cards\\
          `hostap\_plx' &    Prism 2 and 3 based PCMCIA-WLan Cards in PLX-Adapter\\
          `3c574\_cs'   &    PCMCIA: 3Com 574\\
          `3c575\_cb'   &    3Com 575\\
          `3c589\_cs'   &    PCMCIA: 3Com 589\\
          `airo\_cs'    &    Airo 4500 \& 4800 series cards\\
          `axnet\_cs'   &    Asix AX88190 Fast Ethernet (NEW)\\
          `epic\_cb'    &    SMC 83c170 EPIC/100\\
          `fmvj18x\_cs' &    Fujitsu FMV-J181/182 Ethernet (NEW)\\
          `netwave\_cs' &    Netwave AirSurfer Wireless LAN\\
          `nmclan\_cs'  &    New Media Ethernet LAN\\
          `pcnet\_cs'   &    NS8390-based cards (NE2000, DLINK etc)\\
          `ray\_cs'     &    Raylink wireless cards\\
          `smc91c92\_cs' &   PCMCIA: SMC91c92-based cards\\
          `xirc2ps\_cs' &    PCMCIA: Xircom: CE2, CEM28, CEM33, or CE3\\
          `orinoco\_cs' &    Generic Driver for most WLAN-Cards\\
          `hostap\_cs'  &    PrismII/2.5/3 based Cards - supports AP-Mode (NEW)\\
          `wavelan\_cs' &    WaveLAN\\
          `wavelan2\_cs' &   WaveLAN2\\
          `wl24\_cs'    &    ELSA Airlancer MC-2 (NEW - Supports WEP with FW 2.0.10)\\
          `wvlan\_cs'   &    Lucent WaveLAN/IEEE 802.11\\
          `prism54'     &    Prism GT / Prism Duette / Prism Indigo Chipsets (WG511,SMC2835W,SMC2802W,ALL0271) \link{http://prism54.org}\\
          `pegasus'     &    teledat Fast Ethernet USB\\
          `kaweth'      &    3Com 3C19250, ADS USB-10BT, ATEN USB
          Ethernet,
ASANTE USB To Ethernet Adapter, AOX Endpoints USB Ethernet, Correga K.K., D-Link DSB-650C and DU-E10
Entrega / Portgear E45, I-O DATA USB-ET/T, Jaton USB Ethernet Device Adapter, Kingston Technology USB Ethernet Adapter, Linksys USB10T, Mobility USB-Ethernet Adapter, NetGear EA-101, Peracom Enet and Enet2, Portsmith Express Ethernet Adapter, Shark Pocket Adapter, SMC 2202USB, Sony Vaio port extender\\
          `rtl8150'     &    RTL8150-based USB-Ethernet-Cards\\
          `catc'        &    Belkin F5U111,CATC NetMate, CATC NetMate II, smartBridges smartNIC\\
          `CDCEther'    &    Ericsson PipeRider (all variants), Motorola (DM100 and SB4100), Broadcom Cable Modem (reference design), Toshiba PCX1100U and possibly other cable modems, Sharp Zaurus SL-5000D\\
          `eagle-usb'   &    Allied Telesyn AT-AR 215, Sagem 250, Acer ADSL Surf USB, D-link DSL 260i, Sagem 840, US Robotics USR9000, Sagem F@ast 800\\
          `usbnet'      &    Driver for usb-to-usb networklinks\\
          `ibmtr' & IBM Tokenringkarten, die kein DMA verwenden \\
          `olympic' & Non-Lanstreamer PCI Tokenringkarten, genauer
          gesagt IBM PCI, PCI Wake On Lan, PCI II, PCI II
  Wake On Lan, and PCI 100/16/4 adapters \\
          `lanstreamer' & IBM Lanstreamer PCI Tokenringkarten \\
          `tmspci' &  TMS380-based PCI cards -- Compaq 4/16 TR PCI,
          SysKonnect TR4/16 PCI (SK-4590/SK-4591), Thomas-Conrad
          TC4048 PCI 4/16, 3Com Token Link Velocity \\
          `tmsisa' & TMS380-based ISA cards -- SysKonnect TR4/16 ISA
          (SK-4190) \\
          `3c359' & 3Com PCI Velocity XL cards, speziell  3Com 3C359\\
          `abyss' & Madge Smart 16/4 PCI Mk2  cards (51-02)\\
          `smctr' & SMC TokenCard Elite (8115T) und SMC TokenCard Elite/A  (8115T/A) \\

          \caption{Tabelle der möglichen Netzwerkkartentreiber}
          \marklabel{tab:kartentreiber}{}
        \end{longtable}
      \end{small}
    \end{center}
    }
\end{description}

\section{Netzwerke}

\begin{description}
  \config{IP\_NET\_N}{IP\_NET\_N}{IPNETN}

  {Anzahl der Netzwerke, die an das IP-Pro\-to\-koll gebunden werden sollen.
  Im Normalfall also `1'.}

  \config{IP\_NET\_x}{IP\_NET\_x}{IPNETx}

  Standardwert: \var{IP\_NET\_1='192.168.6.1/24'}

  {Die IP-Adresse und die Netzmaske in CIDR (Classles Inter-Domain Routing)
   Schreibweise des x'ten Devices im fli4l-Router.  Nachfolgende Tabelle zeigt
   CIDR und Punkt-Schreibweise (DOT Notation).

   \marklabel{tab:cidr}{
     \begin{tabular}[h!]{rcc}
       CIDR &     Netzmaske   & Anzahl IPs \\
       \hline
       \hline
       /8   & 255.0.0.0       & 16777216   \\
       /16  & 255.255.0.0     & 65536      \\
       /23  & 255.255.254.0   & 512        \\
       /24  & 255.255.255.0   & 256        \\
       /25  & 255.255.255.128 & 128        \\
       /26  & 255.255.255.192 & 64         \\
       /27  & 255.255.255.224 & 32         \\
       /28  & 255.255.255.240 & 16         \\
       /29  & 255.255.255.248 & 8          \\
       /30  & 255.255.255.252 & 4          \\
       /31  & 255.255.255.254 & 2          \\
       /32  & 255.255.255.255 & 1
     \end{tabular}
   }

   {\bf Anmerkung: } Da jeweils eine IP für die Netzwerk- und Broadcast-Adresse
   reserviert sind, errechnet sich die maximale Anzahl der Hosts im Netzwerk
   zu: {\tt Anzahl\_Hosts = Anzahl\_IPs - 2}. Die kleinste mögliche Netzmaske
   wäre also {\tt /30}, entspricht 4 IPs und somit 2 möglichen Hosts.
   }

  \config{IP\_NET\_x\_DEV}{IP\_NET\_x\_DEV}{IPNETxDEV}

  {Erforderlich: Device-Name der Netzwerkkarte.

    Ab Version 2.1.8 ist die Angabe des verwendeten Device zwingend
    erforderlich! Die Namen der Devices beginnen in den meisten Fällen mit {\tt
    'eth'} gefolgt von einer Zahl. Die erste vom System erkannte Netzwerkkarte
    bekommt den Namen {\tt 'eth0'}, die zweite {\tt 'eth1'} usw..\\
    Bei Token-Ring Netzwerkken lautet die Bezeichung {\tt 'tr0'}, {\tt 'tr1'}
    usw..

    Beispiel:

\begin{example}
\begin{verbatim}
        IP_NET_1_DEV='eth0'
        IP_NET_1_DEV='tr0'
\end{verbatim}
\end{example}

    fli4l beherrscht auch IP-Aliasing, also die Zuweisung von mehreren IPs auf
    eine Netzwerkkarte. Die Device-Namen werden dann mit {\tt :0}, {\tt :1}
    usw. ergänzt.

    Beispiel:

\begin{example}
\begin{verbatim}
        IP_NET_1_DEV='eth0'
        IP_NET_2_DEV='eth0:0'
\end{verbatim}
\end{example}


    Standard-Einstellung: \var{IP\_\-NET\_\-1\_\-DEV}='eth0'}

  \config{IP\_NET\_x\_MAC}{IP\_NET\_x\_MAC}{IPNETxMAC}

  {Optional: MAC-Adresse der Netzwerkkarte.

    Hier kann die Hardwareadresse (MAC) der Netzwerkkarte angepasst werden.
    Dies ist zum Beispiel nützlich, wenn Sie einen DHCP-Provider nutzen wollen,
    der eine bestimmte MAC-Adresse erwartet. Soll nur die MAC-Adresse, z.B. für
    einen späteren Aufruf eines dhcp-Clients, verändert werden, kann in diesem
    speziellen Fall \var{IP\_NET\_x} leer gelassen werden.
    Wird \var{IP\_NET\_x\_MAC} leer gelassen oder garnicht angegeben, so wird
    die voreingestellte MAC-Adresse der Netzwerkkarte verwendet.
    Die allermeisten Nutzer werden diese Variable nicht benötigen.

    Beispiel:

\begin{example}
\begin{verbatim}
        IP_NET_1_MAC='01:81:42:C2:C3:10'
\end{verbatim}
\end{example}

    Standard-Einstellung: \var{IP\_\-NET\_\-1\_\-MAC}=''}
\end{description}

\section{Zusätzliche Routen (optional)}

\begin{description}

  \config{IP\_ROUTE\_N}{IP\_ROUTE\_N}{IPROUTEN}

  {Anzahl von zusätzlichen Netzwerkrouten. Zusätzliche Netzwerkrouten
    sind zum Beispiel dann erforderlich, wenn sich im LAN weitere
    Router befinden, über die andere Netzwerke erreichbar sein sollen.

    Im Normalfall ist die Angabe von weiteren Netzwerkrouten nicht
    erforderlich, daher ist die

    Standard-Einstellung: \var{IP\_\-ROUTE\_\-N}='0'}

  \config{IP\_ROUTE\_x}{IP\_ROUTE\_x}{IPROUTEx}

  {Die zusätzlichen Routen \var{IP\_\-ROUTE\_\-1}, \var{IP\_\-ROUTE\_\-2}, \ldots haben folgenden
    Aufbau:

\begin{example}
\begin{verbatim}
        network/netmaskbits gateway
\end{verbatim}
\end{example}

    Dabei ist {\tt network} die Netzwerkadresse, {\tt /netmaskbits} die Netzmaske
    in \jump{tab:cidr}{CIDR} Schreibweise und Gateway die Adresse des Rechners,
    der die Verbindung zu dem Netzwerk herstellt. Der Gateway-Rechner muß
    natürlich im gleichen Netzwerk, wie der fli4l-Router liegen!
    Ist z.B. das Netzwerk 192.168.7.0 mit der Netzwerkmaske
    255.255.255.0 über das Gateway 192.168.6.99 erreichbar, dann lautet der
    Eintrag:

\begin{example}
\begin{verbatim}
        IP_ROUTE_N='1'
        IP_ROUTE_1='192.168.7.0/24 192.168.6.99'
\end{verbatim}
\end{example}}

    Wenn der fli4l-Router nicht als Internet-Router eingesetzt wird
    sondern nur als reiner Ethernetrouter kann man in einem IP\_ROUTE\_x
    Eintrag eine Default-Route angeben. Dazu wird analog zu der
    network/netmaskbits Schreibweise 0.0.0.0/0 eingetragen, so
    wie im Beispiel zu sehen ist.

\begin{example}
\begin{verbatim}
        IP_ROUTE_N='3'
        IP_ROUTE_1='192.168.1.0/24 192.168.6.1'
        IP_ROUTE_2='10.73.0.0/16 192.168.6.1'
        IP_ROUTE_3='0.0.0.0/0 192.168.6.99'
\end{verbatim}
\end{example}

  \end{description}



  \section{Konfiguration des Paketfilters}
  \configlabel{ORIG\_FW\_CONFIG}{ORIGFWCONFIG}
  \configlabel{NEW\_FW\_CONFIG}{NEWFWCONFIG}

  Der von Fli4l verwendete Linux-Kern stellt einen Paketfilter zur
  Verfügung. Mit Hilfe dieses Paketfilters wird gesteuert, wer mit dem
  Router bzw.  über ihn hinweg kommunizieren darf. Weiterhin können
  Dinge wie Port-Forwarding (ein an den Router gerichtetes Paket wird
  an einen anderen internen Rechner weitergereicht) und Masquerading
  (Pakete, die von einem Rechner hinter dem Router kommen, werden so
  verändert, daß sie so aussehen, als kämen sie vom Router selbst)
  realisiert werden. Für die Konfiguration gibt es zwei Varianten, die
  alte auch in 2.0.x vorhandene Variante und eine neue, die eine
  flexiblere Konfiguration des Paketfilters gestattet. Welche Variante
  genutzt wird, wird durch die Variablen \var{ORIG\_FW\_CONFIG} und \var{NEW\_FW\_CONFIG}
bestimmt.  Standardmäßig steht \var{NEW\_FW\_CONFIG} auf {\tt 'yes'}
und wählt damit die neue Konfiguration aus. Hier beschreiben wir
allerdings zuerst die originale Konfiguration, die einfacher zu
verstehen ist und im Anschluss daran die neue Konfiguration, die
wesentlich flexibler ist, aber auch mehr Einarbeitung erfordert. Wählt
man die originale Konfiguration aus, zeigt der Router beim Booten an,
wie diese Konfiguration im neuen Format aussehen würde. Man kann sich
das in aller Ruhe ansehen und evtl, bei Bedarf auf die neue,
flexiblere Konfiguration wechseln.

  Die Struktur des Paketfilters ist in Abbildung \ref{fig:netfilter}
  angedeutet. Pakete kommen auf einem Netzwerkinterface rein und
  durchlaufen die Pre-Routing-Chain. Hier werden evtl. an den Router
  gerichtete Pakete an einen anderen Rechner weitergereicht, indem die
  Ziel-Ip-Adresse und der Zielport manipuliert werden. Ist das Paket
  an den Router gerichtet, wird es an die Input-Chain, andernfalls an
  die Forward-Chain weitergereicht. Beide Chains prüfen, ob das Paket
  zulässig ist. Wird das Paket akzeptiert, wird es an den lokalen
  Zielprozeß zugestellt oder über die Post-Routing-Chain (in der das
  Masquerading stattfindet) an das Netzwerkinterface weitergereicht,
  über das das Paket sein Ziel erreichen kann.

  \begin{figure}[htbp]
    \centering
    \includegraphics[width=\columnwidth]{netfilter}
    \caption{Struktur des Paketfilters}
    \label{fig:netfilter}
  \end{figure}

\marklabel{sec:altekonfiguration}{
 \section{Die alte Konfiguration des Paketfilters}
}

Bei der Konfiguration des Paketfilters werden zwei Dinge
unterschieden: Die kommunikation mit dem Router und die Kommunikation
mit anderen Netzen über den Router hinweg. An allen Stellen, an denen
Netzwerke, IP-Adressen oder Hosts angegeben werden müssen, kann man
sich auch auf \var{IP\_NET\_x}, \var{IP\_NET\_x\_IPADDR} oder via {\tt
'@hostname'} auf einen Host aus \var{HOST\_x} beziehen.

\subsection{Kommunikation über den Router hinweg}

  Der Paketfilter wird so konfiguriert, daß er generell nur Pakete von
  IP-Adressen akzeptiert, die ihm bekannt sind. Bekannt sind ihm
  IP-Adressen aus Subnetzen, die in folgenden Variablen angegeben
  wurden:
  \begin{itemize}
  \item \var{TRUSTED\_NETS} -- Subnetze, zwischen denen geforwarded wird und
    zwischen denen eine ungehinderte und unmaskierte Kommunikation
    möglich ist.
  \item \var{ROUTE\_NETWORK} -- Subnetze, die geforwardet werden;
    Pakete, die in diese Netze hineingehen, werden nicht maskiert.
  \item \var{MASQ\_NETWORK} -- Subnetze, die geforwarded und maskiert werden.
  \end{itemize}

  Weiterhin kennt der Router auch alle Rechner, zu denen Verbindungen
  aufgebaut wurden.

  Zusätzlich wendet Fli4l auf die ihm bekannten IP-Adressen noch eine
  Black-/Whitelist (\var{FORWARD\_HOST\_x}) an und filtert bestimmte
  Ports heraus (\var{FORWARD\_DENY\_PORT\_x}. Die Anwendung der Filter
  ist in Abbildung \ref{fig:forward} dargestellt. Eine zutreffende
  Regel verzweigt im Bild nach oben bzw. nach unten, trifft die Regel
  nicht zu, wird die nächste genommen. Das wird durch den Pfeil nach
  rechts symbolisiert.

  Die Konfigurationsvariablen werden im folgenden genauer beschrieben.

  \begin{figure}[htbp]
    \centering
    \includegraphics[width=\columnwidth]{forward}
    \begin{description}
    \item [PRE/Post] Regeln die vom Nutzer selbst geschrieben wurden und
      unter opt/etc/rc.d/fwrules.{pre,post}.* abgelegt wurden. Diese können
      die Pakete sowohl akzeptieren als auch verwerfen.
    \item[TN] Kommunikation zwischen \var{TRUSTED\_NETS} wird ohne weitere
      Filterung akzeptiert
    \item[FDP] Pakete, die an in \var{FORWARD\_DENY\_PORT\_x}
      spezifizierte Ports gerichtet werden, werden verworfen.
    \item[BL] Kommt das Paket von einem in der Blacklist angegebenen
      Rechner, wird es verworfen.
    \item[WL] Kommt das Paket von einem in der Whitelist angegeben
      Rechner, wird es erst einmal weiterbetrachtet (es muß zusätzlich
      noch aus einem der bekannten Netze stammen).
    \item[RN] Kommt das Paket von einem Rechner aus einem in
      \var{ROUTE\_NETWORK} angegebenen Subnetz, wird es akzeptiert.
    \item[MN] Kommt das Paket von einem Rechner aus einem in
      \var{MASQ\_NETWORK} angegebenen Subnetz, wird es akzeptiert.
    \item[Rel] Gehört das Paket zu einer bereits aufgebauten
      Verbindung, wird es akzeptiert (egal, woher es kommt).
    \item[All] Eine Regel, die auf alle Pakete zutrifft und dafür
      sorgt, daß das Paket verworfen wird.
    \item[Log] Es wird für das Paket ein Eintrag im Syslog bzw. auf
      der Konsole erzeugt.
    \item[Drop] Das Paket wird verworfen.
    \item[Accept] Das Paket wird akzeptiert und damit weitergeleitet.
    \end{description}
    \caption{Konfigurationsvariablen und ihre Anwendung}
    \label{fig:forward}
  \end{figure}

  \begin{description}
    \config{MASQ\_NETWORK}{MASQ\_NETWORK}{MASQNETWORK}

    { Hier sind die Netzwerke anzugeben, die nach aussen hin maskiert
      werden sollen. Verwendet man nicht-offizielle IP-Adressen, wie
      z.B.  192.168.x.x, und soll der Router als Zugang in's Internet
      verwendet werden, müssen diese hier unbedingt angegeben werden.

      Die Form ist:

\begin{example}
\begin{verbatim}
        NETZWERKNUMMER/ANZAHL-DER-GESETZTEN-BITS-IN-NETMASK
\end{verbatim}
\end{example}

      also z.B. für Netze der Form 192.168.x.0:

\begin{example}
\begin{verbatim}
        MASQ_NETWORK='192.168.6.0/24'
\end{verbatim}
\end{example}

      Hier sind also die ersten 24 Bits in der Netzwerkmaske gesetzt.

      Sollen mehrere Netze maskiert werden, sind diese durch
      Leerzeichen zu trennen. Soll kein Netz maskiert werden, muss der
      Variablen-Inhalt leer sein.

      Wie ein Paket aus einem in \var{MASQ\_NETWORK} angegebenen
      Subnetz durch die Firewall läuft, ist in Abbildung \ref{fig:mn}
      dargestellt.

  \begin{figure}[htbp]
    \centering
    \includegraphics[width=\columnwidth]{mn}
    \caption{Der Weg von Paketen aus einem MASQ\_NETWORK durch
      den Paketfilter}
    \label{fig:mn}
  \end{figure}
}


    \config{ROUTE\_NETWORK}{ROUTE\_NETWORK}{ROUTENETWORK}

    { Pakete, die zu von Hosts in diesen Subnetzen aufgebauten
      Verbindungen gehören, werden vom Router geforwarded. Zusätzlich
      werden Pakete, die in diese Netze hineingehen, nicht maskiert.

      Dieses kann z.B. für eine Verbindung zur Firma sinnvoll sein, wo
      Mitarbeiter dieser Firma von dort Zugang in das eigene Netz
      haben sollen. Das Format ist dasselbe wie bei
      \var{MASQ\_\-NETWORK}, also z.B.

\begin{example}
\begin{verbatim}
        ROUTE_NETWORK='192.168.1.0/24'
\end{verbatim}
\end{example}

Auch können hier wieder mehrere Netze angegeben werden.

      \var{ROUTE\_\-NETWORK} kann in der Regel einfach leer bleiben.}

Der Weg, den Pakete eines \var{ROUTE\_\-NETWORK} nehmen, ist in
Abbildung \ref{fig:tn} dargestellt (es ist der gleiche wie ein Paket
aus einem der \var{TRUSTED\_\-NETS}).

  \begin{figure}[htbp]
    \centering
    \includegraphics[width=\columnwidth]{tn}
    \begin{description}
    \item[SRN] Das Paket stammt aus einem in \var{ROUTE\_\-NETWORK}
      angegebenen Subnetz.
    \item[DRN] Das Paket soll in ein in \var{ROUTE\_\-NETWORK}
      angegebenes Subnetz geleitet werden.
    \end{description}
    \caption{Der Weg von Paketen aus einem der TRUSTED\_NETS
      bzw. ROUTE\_NETWORK durch den Paketfilter}
    \label{fig:tn}
  \end{figure}

    \config{FORWARD\_HOST\_WHITE}{FORWARD\_HOST\_WHITE}{FORWARDHOSTWHITE}

    { Es gibt Situationen, da möchte man entweder einigen Rechnern
      gezielt den Zugriff auf andere Netze erlauben (Whitelist) oder
      genau andersherum einigen Rechnern den Zugriff auf andere Netze
      verbieten (Blacklist). Der Paketfilter läßt dann lediglich Pakete
      der angegebenen Rechner durch bzw. blockiert genau diese. Setzt
      man \var{FORWARD\_\-HOST\_\-WHITE} auf yes, stellt die nachfolgende
      Aufzählung eine Whitelist dar, andernfalls eine Blacklist.

      Will man also keinem Rechner die Kommunikation über den Router
      verbieten, definiert man eine leere Blacklist
      (FORWARD\_HOST\_WHITE='no' und \var{FORWARD\_\-HOST\_\-N}='0'). Dies ist auch
      die Standardkonfiguration.

    \configlabel{FORWARD\_HOST\_x}{FORWARDHOSTx}
    \config{FORWARD\_HOST\_N FORWARD\_HOST\_x}{FORWARD\_HOST\_N}{FORWARDHOSTN}

    Hier werden die Rechner der White- bzw. Blacklist aufgeführt. Z.B.
\begin{example}
\begin{verbatim}
        FORWARD_HOST_N='2'
        FORWARD_HOST_1='192.168.6.5'
        FORWARD_HOST_2='192.168.6.6'
\end{verbatim}
\end{example}
    }

    Pakete dieser beiden Rechnern werden im Falle einer Whitelist als
    einzige vom Router weitergeleitet, im anderen Falle als einzige
    blockiert.

    \configlabel{FORWARD\_DENY\_PORT\_x} {FORWARDDENYPORTx}
    \config{FORWARD\_DENY\_PORT\_N FORWARD\_DENY\_PORT\_x}{FORWARD\_DENY\_PORT\_N}{FORWARDDENYPORTN}

    {
      Hiermit kann das Routing über bestimmte IP-Ports verhindert
      werden.  Sinnvoll ist z.B. das Verbieten des Routings der
      Netbios-Ports 137-139.  Damit wird nicht nur das Routing von
      IP-Paketen mit den angegebenen Ports nach ``außen'' unterbunden,
      sondern auch das Routing dieser Ports zwischen zwei LANs.

      Betreibt man mehrere Netzwerkkarten für mehrere Subnetze und
      möchte, daß einige Clients aus einem Subnetz auf die unter
      Windows freigegebenen Verzeichnisse eines Clients aus einem
      anderen Subnetz zugreifen können, sollte das Forwarding der
      Netbios-Ports aber hier nicht unterbunden werden.  In diesem
      Fall kann man mit \var{TRUSTED\_\-NETS} (s.o.) Netze angeben,
      zwischen denen das Routing dieser Ports dennoch explizit erlaubt
      ist.

      Ein Beispiel: Abschalten Zugriff auf Napster-Dienste:
\begin{example}
\begin{verbatim}
        FORWARD_DENY_PORT_N='7'                # Anzahl
        FORWARD_DENY_PORT_1='135-139 REJECT'   # NetBios-Ports 135 bis 139
        FORWARD_DENY_PORT_2='445     REJECT'   # MS-DS
        FORWARD_DENY_PORT_3='8888    REJECT'   # Napster Port 8888
        FORWARD_DENY_PORT_4='7777    REJECT'   # Napster Port 7777
        FORWARD_DENY_PORT_5='7000    REJECT'   # Napster Port 7000
        FORWARD_DENY_PORT_6='4444    REJECT'   # Napster Port 4444
        FORWARD_DENY_PORT_7='4200    REJECT'   # Napster Port 4200
\end{verbatim}
\end{example}
    }
    \config{TRUSTED\_NETS}{TRUSTED\_NETS}{TRUSTEDNETS}

    { Das Sperren des Routings der mittels
      \var{FORWARD\_\-DENY\_\-PORT\_\-x} angegebenen Ports und die
      Black/Whitelist (\var{FORWARD\_DENY\_HOST}) kann mit
      \var{TRUSTED\_\-NETS} für bestimmte Netze außer Kraft gesetzt
      werden. Hier können Netze angegeben werden, die {\em
        vertrauenswürdig} sind. Ein typisches Beispiel ist das Routing
      von NetBios-Ports zwischen zwei LANs, die über zwei
      Netzwerkkarten des fli4l-Routers versorgt werden.  In diesem
      Fall sind alle vertrauenswürdigen Netze anzugeben, z.B.

\begin{example}
\begin{verbatim}
        TRUSTED_NETS='192.168.1.0/24 192.168.6.0/24'
\end{verbatim}
\end{example}

      Dabei ist es im Gegensatz zur Variable \var{MASQ\_\-NETWORK} notwendig,
      alle Netze anzugeben, zwischen denen geforwardet werden soll. Es
      sind also mindestens 2 Netze einzutragen, damit korrekte
      IP-Tables-Regeln generiert werden!

      Der Weg, den Pakete eines \var{ROUTE\_\-NETWORK} nehmen, ist in
      Abbildung \ref{fig:tn} dargestellt (es ist der gleiche wie ein
      Paket aus einem \var{TRUSTED\_\-NET}).

      Standard-Einstellung: \var{TRUSTED\_\-NETS}=''


    }
    \item[Andere Netze]

    Wie in den einführenden Bemerkungen bereits angemerkt, leitet der
    Router nur Pakete weiter, die aus Netzen kommen, die er kennt. Da
    man aber nicht alle Netze, mit denen man kommunizieren will, von
    vornherein kennt, führt der Router Buch über aufgebaute
    Verbindungen und läßt auch Pakete durch, die zu solchen
    Verbindungen gehören. Der Weg eines solchen Paketes durch den
    Paketfilter ist in Abbildung \ref{fig:other} dargestellt.

  \begin{figure}[htbp]
    \centering
    \includegraphics[width=\columnwidth]{other}
    \caption{Der Weg von Paketen aus einem unbekannten Netz durch den Paketfilter}
    \label{fig:other}
  \end{figure}


  \end{description}

\subsection{Kommunikation mit dem Router}

Während die bisherige Konfiguration die Kommunikation von Hosts über
den Router hinweg beschrieb, beschreibt der folgende Teil die
Kommunikation mit dem Router. Da fli4l Dienste auf bestimmte Ports zur
Verfügung stellt, ist es sinnvoll, diese vor Zugriffen von aussen zu
schützen.

\wichtig{Das vom Router maskierte LAN (s.o) ist generell
  vor dem Zugang von aussen geschützt.  Die angegebenen Portnummern
  regeln deshalb nur den Zugriff von aussen auf den fli4l-Router
  selbst.}

Interessant sind dabei die in Tabelle \ref{tab:deny-ports}
beschriebenen Dienste und die dazugehörigen Ports.
Rechner aus Netzen, die in \var{MASQ\_NETWORK}, \var{ROUTE\_NETWORK}
bzw. \var{TRUSTED\_NETS} angegeben sind, haben freien Zugang zum
Router, für alle anderen sind alle Ports des Routers zu. Will man
einen Dienst auch anderen anbieten, muß der entsprechende Port über
die Variablen \var{INPUT\_\-ACCEPT\_\-PORT\_\-x} geöffnet werden.

      \begin{table}[htbp]
        \begin{center}

          \begin{tabular}{lll}
            Port       &     Name          &      Prozess \\
            \hline
            22         &     ssh           &      sshd\\
            37         &     time          &      $<$kernel$>$\\
            53         &     domain        &      dnsmasq\\
            80         &     www           &      mini\_httpd\\
            137:139    &     netbios       &      smbd (samba)\\
            515        &     printer       &      lpd\\
            5000       &     $<$imond$>$   &      imond\\
            5001       &     $<$telmond$>$ &      telmond\\
            8000       &     $<$proxy$>$   &      privoxy\\

          \end{tabular}
          \caption{Ports, auf denen fli4l ggfs. Dienste anbietet}
          \label{tab:deny-ports}
        \end{center}
      \end{table}


      Es wird {\bf dringend} empfohlen, die Standardkonfiguration der
      Firewall-Ports nicht zu verändern.
  \begin{description}

    \configlabel{INPUT\_ACCEPT\_PORT\_x} {INPUTACCEPTPORTx}

    \config{INPUT\_ACCEPT\_PORT\_N INPUT\_ACCEPT\_PORT\_x}{INPUT\_ACCEPT\_PORT\_N}{INPUTACCEPTPORTN}

    Standardmäßig sind alle Ports nach außen zu, eine Verbindung zum
    Router ist nicht möglich. Ports, auf denen ein Dienst nach außen
    angeboten wird, müssen hier angegeben werden.

    Ein Eintrag besteht dabei aus einem einzelnem Port bzw. einem
    ganzen Port-Bereich (zwei Ports durch Doppelpunkt getrennt) und
    einer optionalen Pro\-to\-koll\-an\-ga\-be (TCP oder UDP). Wird kein
    Protokoll angegeben, werden auf dem Port beide Protokolle
    akzeptiert. Am Beispiel der ssh, die ihren Dienst auf Port 22 über
    das TCP-Protokoll anbietet, würde das wie folgt aussehen:

\begin{example}
\begin{verbatim}
INPUT_ACCEPT_PORT_N='1'             # no. of ports to accept from outside
INPUT_ACCEPT_PORT_1='22 TCP'        # e.g. allow connection to ssh service
\end{verbatim}
\end{example}

    \config{INPUT\_POLICY}{INPUT\_POLICY}{INPUTPOLICY}

    Kommt ein Paket beim Router an, das aufgrund der Konfiguration
    nicht durchgelassen werden darf, hat der Router zwei
    Möglichkeiten. Er kann das Paket einfach wegwerfen ({\em DROP})
    oder es ablehnen ({\em REJECT}) und eine entsprechende Information
    an den Absender zurückschicken. Wie der Router reagiert, wird hier
    festgelegt, wobei die Standardreaktion {\em REJECT} ist.

    Bei Anwendung der {\em DROP}-Policy verhält sich der Router still
    -- das kann auch Probleme machen. Zum Beispiel schicken einige
    Rechner, die Internet-Dienste wie ftp anbieten, als Antwort auf
    einen Verbindungsaufbau eine Anfrage auf Port 113 (auth) zurück.
    Wenn fli4l darauf nicht reagiert, kann es zum ungewollten Abbruch
    der Verbindung zum gewünschen Dienst kommen.

      Ich persönlich ziehe die {\em REJECT}-Policy vor, da sie
      erwartungsgemäß weniger Probleme bei diversen
      Internet-Protokollen bereitet und genauso sicher ist wie {\em DROP}.

      Weiterführende Informationen zu {\em REJECT} vs {\em DROP}:

      \link{http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html\#Deny}\\
      \link{http://www.chiark.greenend.org.uk/\%7Epeterb/network/drop-vs-reject}

    \config{DENY\_ICMP}{DENY\_ICMP}{DENYICMP}

    { Sollen Zugriffe von außen über das ICMP-Protokoll (echo
      requests) verboten werden, kann
      \var{DENY\_\-ICMP}='yes' gesetzt werden. In diesem
      Fall kann man den Router von außen nicht mehr mit ping
      ansprechen. Bevor hier ein yes eingetragen wird, sollte man
      unbedingt folgende Seiten besuchen:

      \link{http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html\#Verstecken}\\
      \link{http://extern.fli4l.de/fli4l\_faqengine/faq.php?display=faq\&faqnr=26\&catnr=10\&prog=1\&lang=de\&layout=def}\\

      Standard-Einstellung: \var{DENY\_\-ICMP}='no'}


    \config{PACKETFILTER\_LOG}{PACKETFILTER\_LOG}{PACKETFILTERLOG}

    { Hier kann eingestellt werden, ob abgelehnte Zugriffe von außen
      über die Syslog-Schnittstelle protokolliert werden sollen.

      Hier eine kurze Erklärung der wichtigsten Elemente einer Protokollzeile:
\begin{example}
\begin{verbatim}
IN=ppp0 OUT= MAC= SRC=217.238.54.176 DST=217.235.38.43 LEN=48
    TOS=0x00 PREC=0x00 TTL=124 ID=30343 DF PROTO=TCP SPT=3087
    DPT=4662 WINDOW=16384 RES=0x00 SYN URGP=0
\end{verbatim}
\end{example}

      \begin{tabular}{ll}
        IN          &  Device, auf dem das Paket hereinkam \\
        SRC, DST    &  Quell- und Zieladresse des Paketes\\
        LEN         &  Länge des Pakets in Bytes\\
        TOS         &  Type Of Service\\
        TTL         &  Time To Live, Anzahl der Hops, bis das Paket gelöscht wird\\
        PROTO=TCP   &  TCP Paket\\
        SPT, DPT    &  Quell- und Zielport \\
        ID          &  IP-ID, wird mit jedem Paket vom Sender um eins erhöht\\
      \end{tabular}

      Standard-Einstellung: \var{PACKETFILTER\_\-LOG}='no'
      }

  \end{description}

\section{Neue Konfiguration des Paketfilters}

Seit geraumer Zeit steht eine neue Möglichkeit zur Verfügung, den
Paketfilter zu konfigurieren. Diese ist seit 2.1.8 die
Standardkonfiguration. Die
\jump{sec:altekonfiguration}{originale Konfiguration} existiert immer
noch, muß aber separat aktiviert werden.

  Mit der neuen Paketfilterkonfiguration lassen sich die einzelnen
  Tabellen des Paketfilters direkt konfigurieren. Dazu gibt es für
  jede relevante Tabelle eine eigene Liste, d.h. eine für die
  Input-Tabelle (\var{INPUT\_LIST\_x}), eine für die
  Forwarding-Tabelle (\var{FORWARD\_LIST\_x}) und eine für die
  Postrouting-Tabelle, in der das Masqerading gemacht wird
  (\var{POSTROUTING\_LIST\_x}). Für die Prerouting-Tabelle gibt es
  momentan zwei Konfigurationsmöglichkeiten, die gleichzeitig genutzt
  werden können. Die bereits bekannte Portforwarding-Konfiguration
  über \jump{sec:portfw}{\var{PORTFW\_x}} und die \var{PREROUTING\_LIST\_x}.

Ein Eintrag in einer dieser Listen, ausgenommen Pre-Routing, besteht im
wesentlichen aus einer
Aktion ({\em ACCEPT, DROP, REJECT, SNAT oder MASQUERADE}), die durch
zusätzliche Bedingungen eingeschränkt werden kann. Diese Bedingungen
beziehen sich auf Eigenschaften des betrachteten Paketes. Ein Paket
enthält Informationen über seine Herkunft (Quelle, welcher Rechner hat
das Paket losgeschickt), sein Ziel (an welchen Rechner und welche
Anwendung soll das Paket gehen) u.a.m.. Bedingungen können sich auf
folgende Eigenschaften eines Paketes beziehen:

\begin{itemize}
\item die Quelle (Quell-IP, Quell-Port oder beides)
\item das Ziel (Ziel-IP, Ziel-Port oder beides)
\item das Protokoll
\item das Interface, über welches das Paket reinkommt bzw. rausgeht
\item die Mac-Adresse des Rechners, von dem das Paket kommt
\item den Zustand des Paketes bzw. der Verbindung, zu der das Paket gehört
\end{itemize}

Kommt ein Paket rein, werden die Einträge bzw. die daraus generierten
Regeln von oben nach unten abgearbeitet und die erste Aktion
ausgeführt, bei der alle Bedingungen gelten.  Trifft keine der Regeln
zu, wird die Standardreaktion ausgeführt, die man für (fast) jede
Tabelle angeben kann.

Ein Eintrag hat dabei folgendes Format, wobei zu beachten ist, daß
alle Einschränkungen optional sind:

\begin{example}
\begin{verbatim}
restriction{0,} [[source] [destination]] action [BIDIRECTIONAL|LOG|NOLOG]
\end{verbatim}
\end{example}


\subsection{Aktionen des Paketfilters}
\label{sec:fwrules_actions}

Aktionen können die folgenden sein:
\begin{description}
\item[ACCEPT] Akzeptiere das Paket
\item[DROP] Verwerfe das Paket (der Absender erkennt das nur daran,
  daß keine Antwort, aber auch keine Fehlermeldung zurückkommt)
\item[REJECT] Weise das Paket zurück (der Absender enthält eine
  entsprechende Fehlermeldung)
\item[LOG] Logge das Paket und gehe zur nächsten Regel. Um
  verschiedene Log-Statements auseinanderhalten zu können, können
  Log-Prefixes verwendet werden. Diese werden via LOG:log-prefix
  angegeben.
\item[MASQUERADE] Maskiere das Paket (ersetze die Absender-IP des
  Paketes durch die eigene, bei der Einwahl dem Interface zugewiesene
  Adresse und sorge dafür, daß Antworten für diese Verbindung an den
  richtigen Rechner weitergeleitet werden; diese Aktion ist nur in der
  \var{POSTROUTING\_LIST} möglich)
\item[SNAT] Ersetze die Absender-IP des Paketes durch die als
  Parameter für SNAT angegebene statische IP (für alle Pakete die zu
  der gerade betrachteten Verbindung gehören; diese Aktion ist nur in
  der \var{POSTROUTING\_LIST} möglich)
\item[NETMAP] Mappe die Ziel- bzw. Absender-IP des Paketes in den als
  Parameter für NETMAP angegebenen Bereich, die Ports bleiben
  unverändert (für alle Pakete die zu der gerade betrachteten
  Verbindung gehören; diese Aktion ist nur in
  der \var{PREROUTING\_LIST} oder \var{POSTROUTING\_LIST} möglich; in
  der Preroutinglist wird die Zieladresse verändert, in der
  Postroutinglist die Quell-Adresse)
\item[DNAT] Ersetze die Ziel-IP und den Zielport des Paketes durch die als
  Parameter für DNAT angegebene IP (für alle Pakete, die zu
  der gerade betrachteten Verbindung gehören; diese Aktion ist nur in
  der \var{PREROUTING\_LIST} möglich)
\item[REDIRECT] Ersetze den Zielport des Paketes durch die als
  Parameter für REDIRECT angegebenen Port und stelle das Paket lokal
zu (für alle Pakete, die zu
  der gerade betrachteten Verbindung gehören; diese Aktion ist nur in
  der \var{PREROUTING\_LIST} möglich)

\end{description}

Einige dieser Aktionen können durch die Optionen {\em BIDIRECTIONAL},
{\em LOG} oder {\em NOLOG} in ihrem Verhalten modifiziert werden. {\em
  BIDIRECTIONAL} generiert die gleiche Regel noch einmal nur mit
Quell- und Zieladresse vertauscht. {\em LOG/NOLOG} (de)aktivieren das
Logging für diese eine Regel.


\subsection{Einschränkungen in den Regeln}
\label{sec:fwrules_limits}

Einschränkungen können durch die in den folgenden Abschnitten
aufgeführten Bedingungen vorgenommen werden. Bei den Bedingungen kann
man immer 'any' angeben, wenn man an irgendeiner Stelle keine
Einschränkung vornehmen will, aber trotzdem etwas angeben
will/muß. Einschränkungen können in beliebiger Reihenfolge angegeben
werden, wenn sie einen vorangestellten Präfix haben. Das gilt für alle
außer die Angabe einer Quell- bzw. Zieladresse. Diese müssen immer
direkt vor der Aktion stehen, die anderen Einschränkungen müssen
vorher erfolgen. Einschränkungen können auch negiert werden, dazu wird
einfach ein '!' vorangestellt.

\subsubsection{Einschränkungen der Quelle und des Ziels}

Jedes Paket enthält eine Quell- und eine Zielangabe; jeweils in Form
eines Tupels einer IP-Adresse und eines Ports. Diese Quelle bzw.
dieses Ziel kann für eine Einschränkung herangezogen werden. Die
Angabe für die Quelle bzw. das Ziel kann folgendermaßen vorgenommen
werden:

\begin{tabular}[h!]{lp{8cm}}
{\bf ip}          & eine einfache IP-Adresse\\
{\bf network}     & eine Netzwerkangabe der Form ip/netmask \\
{\bf port[-port]} & ein Port bzw. ein Port-Bereich\\
{\bf IP\_NET\_x\_IPADDR}   & die IP-Adresse des Interfaces x des Routers\\
{\bf IP\_NET\_x}  & das Subnetz x des Routers\\
{\bf IP\_ROUTE\_x}& das in einer Route angegebene Subnetz (default
Routen können nicht verwendet werden, sie würden any entsprechen und
werden vorsichtshalber ausgeklammert)\\
{\bf \@name}        & einer der via HOST\_x\_* vergebenen Namen oder
Aliases; es wird die zugehörige IP-Adresse an dieser Stelle eingesetzt\\
{\bf $<$ip oder netzwerk$>$:port[-port]} & IP/Netzwerk-Adresse in einer
der obigen Varianten spezifiziert kombiniert
  mit einem Port/Port-Bereich\\
\end{tabular}

Das könnte z.B. wie folgt aussehen: {\em '192.168.6.2 any DROP'}.

Tauchen zwei dieser Angaben auf, wird die erste als Quelle, die zweite
als Ziel betrachtet. In diesem Beispiel verwerfen wir also Pakete, die
vom Rechner mit der IP-Adresse 192.168.6.2 gesendet wurden, unabhängig
davon, an welches Ziel sie gerichtet sind.

Taucht nur eine Angabe auf, wird anhand des Wertes entschieden, ob die
Quelle oder das Ziel gemeint ist, wobei die Entscheidung relativ
einfach ist:
\begin{itemize}
\item Ist eine Port-Angabe enthalten, ist das Ziel gemeint.
\item Sonst ist die Quelle gemeint.
\end{itemize}

Wenn wir also z.B. das obige Beispiel etwas kürzer schreiben wollen,
können wir einfach {\em '192.168.6.2 DROP'} schreiben. Es ist kein
Port angegeben, die Bedingung gilt also für die Quelle, den Rechner,
von dem das Paket gesendet wurde.

Wollen die Kommunikation mit dem sshd erlauben, können wir {\em 'any
  any:22 ACCEPT'} (Pakete von einem beliebigen Rechner an
einen beliebigen Rechner auf den sshd-Port 22 werden akzeptiert) oder
kürzer {\em '22 ACCEPT'} schreiben. Es ist nur ein Port angegeben,
also meinen wir das Ziel und damit Pakete, die an den Port 22
gerichtet sind.

Zur Vereinfachung der Regelmenge kann man an die Aktion ein {\em
  BIDIRECTIONAL} dranhängen, um auszudrücken, daß die Regel für beide
  Kommunikationsrichtungen gilt. Es werden dann Regeln generiert, in
  denen einfach die Quell- und die Ziel-IP und eventuelle Interfaces
  vertauscht sind und der Rest gleichbleibt.

{\bf Beispiele:}\\
  \begin{tabular}{p{5cm}p{10cm}}
    {\small '127.0.0.1 ACCEPT'} & Lokale Kommunikation (Quelle 127.0.0.1) ist
    erlaubt \\
    {\small 'any 192.168.12.1 DROP'} & Pakete an die IP-Adresse 192.168.12.1
    werden weggeworfen \\
    {\small 'any 192.168.12.1 DROP LOG'} & Pakete an die IP-Adresse 192.168.12.1
    werden weggeworfen und zusätzlich gelogged \\
    {\small 'any 192.168.12.1 DROP NOLOG'} & Pakete an die IP-Adresse 192.168.12.1
    werden weggeworfen, werden aber nicht gelogged \\
    {\small '22 ACCEPT'} & Pakete an den Port 22 (sshd) werden akzeptiert \\
    {\small 'IP\_NET\_1\_NET ACCEPT'} & Pakete aus dem am 1. Interface hängenden
    Subnetz werden akzeptiert\\
    {\small 'IP\_NET\_1\_NET IP\_\-NET\_2\-\_NET ACCEPT BIDIRECTIONAL'} &
    Kommunikation zwischen dem am ersten und zweiten Interface
    hängenden Subnetzen ist gestattet
  \end{tabular}

\subsubsection{Einschränkung des Interfaces}

Einschränkung des Interfaces, über das das Paket reinkam bzw.
rausgeht. Das Format sieht wie folgt aus: \begin{bf}if:\end{bf}\begin{em}in\end{em}\begin{bf}:\end{bf}\begin{em}out\end{em}

In der Input-Liste kann man das rausgehende Interface nicht einschränken
(das Paket geht ja nicht mehr raus), in der Masquerade-Liste
(Postrouting) kann man das reinkommende Interface nicht einschränken,
da die Information darüber nicht mehr vorhanden ist. Lediglich in der
Forward-Liste kann man für beides Bedingungen angeben.

Möglich sind folgendes Werte für {\em in} bzw. {\em out}:

    \begin{itemize}
    \item lo (loopback Interface, lokale Kommunikation auf dem Router)
    \item eth0 - eth9
    \item br0 - br9
    \item circuit\_1 - circuit\_99
    \item IP\_NET\_1\_DEV - IP\_NET\_99\_DEV
    \item pppoe (das pppoe device)
    \item any
    \end{itemize}


\subsubsection{Einschränkungen des Protokolls}

Einschränkung des Protokolls, zu dem dieses Paket gehört. Das Format
sieht wie folgt aus: \begin{bf}prot:\end{bf}\begin{em}protcol\end{em}
bzw. \begin{bf}prot:\end{bf}\begin{em}icmp\end{em}\begin{bf}:\end{bf}\begin{em}icmp-type\end{em}.

\begin{em}protcol\end{em} kann dabei eines der folgenden Werte
annehmen:

\begin{itemize}
\item tcp
\item udp
\item icmp

  Bei icmp kann man zusätzlich noch einen Namen für den icmp-Typ
  angeben, z.B. prot:icmp:echo-request.

\item numerischer Wert der Protokoll-ID
\item any
\end{itemize}


\subsubsection{Einschränkung der MAC-Adresse}

Mittels \begin{bf}mac:\end{bf}\begin{em}mac addr\end{em} kann eine
Einschränkung der MAC-Adresse vorgenommen werden.


\subsubsection{Einschränkungen basierend auf dem Zustand eines
  Paketes}

Der von fli4l verwendete Paketfilter sammelt Informationen über den
Zustand von Verbindungen. Diese Informationen kann man dann nutzen, um
Pakete zu Filtern, also z.B. nur Pakete durchzulassen, die zu bereits
bestehenden Verbindungen gehören. Die Zustände einer Verbindung können
ein:

\begin{description}
\item[INVALID] Das Paket gehört zu keiner bekannten Verbindung.
\item[ESTABLISHED] Das Paket gehört zu einer Verbindung, über die
  bereits in beide Richtungen Pakete geflossen sind.
\item[NEW] Das Paket hat eine neue Verbindung aufgebaut oder gehört zu
  einer Verbindung, bei der noch nicht Pakete in beide Richtungen
  geflossen sind.
\item[RELATED] Das Paket baut eine neue Verbindung auf, hat aber eine
  Beziehung zu einer bestehenden Verbindung (z.B. ftp baut eine
  separate Verbindung für den eigentlich Datentransfer auf).
\end{description}

Für eine genauere Beschreibung der Zustände siehe\\
\link{http://www.sns.ias.edu/\%7Ejns/index.php?pagename=ConnectionTracking}.

Die Zustände werden wie folgt angegeben:
\begin{bf}state:\end{bf}\begin{em}state(s)\end{em}. Will man mehrere
Zustände angeben, werden diese mit Komma getrennt. Um z.B. nur Pakete
durchzulassen, die zu bestehenden Verbindungen gehören, kann man
folgendes schreiben (für input und forwarding):
\begin{bf}state:\end{bf}\begin{em}ESTABLISHED,RELATED\end{em}

\subsubsection{Einschränkung der Häufigkeit einer Aktion}

Unter bestimmten Umständen möchte man die Häufigkeit von Aktionen
begrenzen, z.B. nur einen {\em echo request} pro Sekunde zulassen. Das
kann man mit der {\em limit} Einschränkung erreichen, die wie folgt
aussieht: {\bf limit:}\begin{em}Häufigkeit:Burst\end{em}. Die
Häufigkeit wird dabei als n pro Zeiteinheit (second, minute, hour, day)
angegeben wobei zusätzlich noch Ereignisse gehäuft auftreten
können (Burst). {\em limit:3/minute:5} heißt z.B. 3 Ereignisse pro Minute,
wobei auch mal 5 Ereignisse dicht aufeinander folgend akzeptiert
werden.

\marklabel{sec:templates}{
\subsection{Der Einsatz von Templates im Paketfilter}
}
Um den Umgang mit dem Paketfilter weiter zu vereinfachen gibt es die
Möglichkeit häufig vorkommende Regeln zu sogenannten Templates
zusammenzufassen. Damit ist es möglich eine ganze Reihe von
Paketfilterregeln zusammenzufassen und dieser Sammlung von Regeln
einen symbolischen Namen zu geben. Anstatt direkt mit Protokollen und
Portnummern arbeiten Sie dann mit Einträgen wie 'tmpl:ssh' wenn Sie
mit dem SSH Protokoll arbeiten wollen. Wie mit Templates zu verfahren
ist, wird hier am Beispiel von SSH gezeigt.

Wollen Sie Ihren fli4l-Router vom Internet aus per SSH erreichen, so
schreiben Sie als Wert in der Variablen \var{INPUT\_LIST\_x} den
entsprechenden Dienstnamen mit vorangestelltem \emph{tmpl:} und der
Aktion, die für diesen Dienst gelten soll. Beispiel:

\var{INPUT\_LIST\_2}='tmpl:ssh ACCEPT'

Hierbei steht \emph{tmpl:} dafür, dass eine Regel aus einem Template
erstellt werden soll. Den Namen des Dienstes geben Sie nach dem ':'
an. In unserem Beispiel also 'ssh'. Zum Schluss geben Sie an welche
Aktion mit dem Dienst verbunden werden soll. Da Sie den fli4l-Router
aus dem Internet erreichen wollen erlauben wir die Verbindung mit
'ACCEPT'. Einschränkungen von IP-Adressen oder Netzen sind nicht
angegeben, also ist der SSH Dienst von allen Netzen und Interfaces
erreichbar. Sie könnten bei Bedarf die gewohnten Schreibenweisen vom
Paketfilter benutzen um den Zugriff auf den SSH Dienst weiter
einzuschränken.

Für welche Dienste Regeln vorbereitet sind (=Templates existieren)
kann in der Template Datei in opt/etc/fwrules.tmpl/templates
nachgelesen werden, hier die Aufstellung in Tabellenform (siehe
Tabelle \ref{tab:fwrules_tmpl}).

Die Syntax fuer diese Form der Paketfilterregeln lautet
also immer

    tmpl:$<$Name des Dienstes$>$ $<$Einschränkungen$>$ $<$Gewünschte Aktion$>$

Wobei als $<$Einschränkungen$>$ alles erlaubt ist was unter
\ref{sec:fwrules_limits} beschrieben wird. Die möglichen Werte für
$<$Gewünschte Aktion$>$ sind in \ref{sec:fwrules_actions} aufgelistet und
beschrieben.

Ein paar weitere Beispiele verdeutlichen die Arbeitsweise. Zuerst
gucken wir uns meine \var{PREROUTING\_LIST} an.

\begin{verbatim}
PREROUTING_LIST_N='2'
PREROUTING_LIST_1='tmpl:xbl dynamic DNAT:@xbox'
PREROUTING_LIST_2='tmpl:https dynamic DNAT:192.168.193.250'
\end{verbatim}

Die Regel \var{PREROUTING\_LIST\_1} versorgt meine Xbox mit allem was für
Xbox Live notwendig ist. Im einzelnen wird mit 'tmpl:xbl' alle Ports
und Protokolle die für Xbox Live notwendig sind an den Host 'xbox'
weitergeleitet. Anstelle der IP-Adresse wird ein Eintrag aus der
\var{HOST\_x\_NAME} Liste benutzt. Durch 'dynamic' weiss der fli4l, dass die
Ports vom Internetinterface weitergeleitet werden sollen.

Die zweite Regel leitet das https Protokoll an einen Webserver in der
DMZ weiter.

Jetzt sehen wir uns an wie es mit den \var{INPUT\_LIST} weitergeht.

\begin{verbatim}
INPUT_LIST_N='3'
INPUT_LIST_1='if:IP_NET_1_DEV:any ACCEPT'
INPUT_LIST_2='if:pppoe:any prot:tcp 113 ACCEPT'
INPUT_LIST_3='if:br0:any tmpl:dns @xbox 192.168.193.254 ACCEPT'
\end{verbatim}

Die erste Regel läßt alle aus dem Netz das mit \var{IP\_NET\_1} definiert
ist auf den Router zugreifen. Die zweite Regel ist für das oident
Paket. Dort wird der ident Port geöffnet. Die dritte und letzte Regel
erlaubt der Xbox den Zugriff auf den DNS Server auf dem fli4l. Hier
ist auch wieder schon zu sehen wie man einen Hostalias
einsetzt. Anstelle der IP-Adresse 192.168.193.254 hätte ich auch
IP\_NET\_1\_IPADDR schreiben können.

In meiner \var{FORWARD\_LIST} und \var{POSTROUTING\_LIST} steht nichts 'tmpl:'
spezifisches mehr.

\begin{figure}[htbp]
  \centering
  \includegraphics[width=\columnwidth]{etc_fwrules_tmpl_dir}
  \caption{Verzeichnisstruktur fli4l}
  \label{fig:etc_fwrules_tmpl_dir}
\end{figure}

Es ist auch möglich, dass Sie eigene Templates anlegen oder das
opt--Pakete ihre eigenen Templates mitbringen. Um ein eigenes
Template anzulegen muss lediglich eine Datei mit den Namen des
Templates erstellt werden und die entsprechenden Regeln dort
aufgenommen werden. Wenn Sie eine private Templatedatei anlegen wollen
erstellen Sie in dem Verzeichnis etc/fwrules.tmpl unterhalb Ihres
config Verzeichnisses die Templatedatei, so wie es die Abbildung
\ref{fig:etc_fwrules_tmpl_dir} zeigt. Wenn das Verzeichnis etc/fwrules.tmpl
unterhalb Ihres config Verzeichnisses noch nicht existiert legen Sie
bitte zuerst beide Verzeichnisse neu an. Alternativ können
opt--Entwickler oder Benutzer die Templates für mehr als eine
Konfiguration anlegen wollen Ihre Regeln direkt in das Verzeichnis
opt/etc/fwrules.tmpl ablegen. In dieses Verzeichnis kommen dann die
neuen Templates. Dabei gilt die Regel, dass die Templates im config
Verzeichnis des Benutzers vor den Templates von opt--Paketen
kommen. Zum Schluss wird die templates Datei, die zum Lieferumfang von
fli4l gehört, ausgewertet. Sie können also Einträge in der fli4l
templates Datei dadurch \glqq{}überschreiben\grqq{} indem Sie eine
Templatedatei mit dem Namen des zu überschreibenden Templates in Ihrem
config Verzeichnis anlegen.

Wenn Sie zum Beispiel das Template vpn\_freunde anlegen wollen, legen
Sie die Datei vpn\_freunde an. Das Template soll die Dienste ssh,
smtp, dns und samba enthalten. Also schreiben Sie in die Datei
vpn\_freunde folgendes:

\begin{example}
\begin{verbatim}
prot:tcp 22
prot:tcp 25
53
prot:udp 137-138
prot:tcp 139
prot:tcp 445
\end{verbatim}
\end{example}

Wann immer Sie jetzt das Template vpn\_freunde benutzen, werden daraus
Regeln für alle darin aufgeführten Protokolle und Ports erzeugt. Wenn
Sie also schreiben FORWARD\_LIST\_x='tmpl:vpn\_freunde ACCEPT' werden
daraus folgende Regeln erstellt:

\begin{example}
\begin{verbatim}
FORWARD_LIST_x='prot:tcp 22 ACCEPT'
FORWARD_LIST_x='prot:tcp 25 ACCEPT'
FORWARD_LIST_x='53 ACCEPT'
FORWARD_LIST_x='prot:udp 137-138 ACCEPT'
FORWARD_LIST_x='prot:tcp 139 ACCEPT'
FORWARD_LIST_x='prot:tcp 445 ACCEPT'
\end{verbatim}
\end{example}

\begin{center}
  \begin{longtable}[htbp]{|lll|}
     \hline
     Templatename & Protokoll & Port(s) \\ \hline
     \input fwrules_tmpl_table.inc
     \caption{Die im Lieferumfang von fli4l enthaltenen Templates}
     \label{tab:fwrules_tmpl}
  \end{longtable}
\end{center}

\subsection{Die Konfiguration des Paketfilters}

Der Paketfilter im wesentlichen wird über 3 Listen konfiguriert:

\begin{itemize}
\item Input-Liste
\item Forward-Liste
\item Masquerade-Liste
\end{itemize}

Aktiviert wird die Konfiguration durch \var{NEW\_FW\_CONFIG}='yes'.

\subsubsection{Die Input-Liste}

Über die Input-Liste wird konfiguriert, wer auf den Router zugreifen
darf. Trifft keine der Regeln der Input-Liste zu, bestimmt die
Default-Policy, was mit dem Paket passieren soll und die Log-Variable,
ob es bei einer Ablehnung ins System-Log geschrieben werden soll.

Bei den verwendeten Parametern gibt es zwei Einschränkungen:
\begin{itemize}
\item {\em MASQUERADE} und {\em SNAT} können nicht als Aktion angegeben werden
\item bei einer Interface-Einschränkung kann man nur das
  Eingangsinterface einschränken.
\end{itemize}

\begin{description}
\config{INPUT\_POLICY}{INPUT\_POLICY}{INPUTPOLICYNEW}

Diese Variable beschreibt die Default Policy, die angewand wird,
wenn keine der anderen Regeln zutrifft. Möglich sind:

\begin{itemize}
\item ACCEPT (nicht empfohlen)
\item REJECT
\item DROP (nicht empfohlen)
\end{itemize}

\config{INPUT\_ACCEPT\_DEF}{INPUT\_ACCEPT\_DEF}{INPUTACCEPTDEF}

Steht diese Variable auf 'yes', werden drei default-Regeln generiert.
Die erste gestattet {\em icmp echo requests} ('prot:icmp:8 ACCEPT'),
die zweite akzeptiert Pakete, die zu bestehenden Verbindungen gehören
('state:ESTABLISHED,RELATED ACCEPT', damit auch alle icmp pakete, die
Resultat einer bestehenden Verbindung sind) und die dritte lokale
Kommunikation ('if:lo:any ACCEPT'). Im Zweifelsfalle sollte man hier
'yes' eintragen.


\config{INPUT\_LOG}{INPUT\_LOG}{INPUTLOG}

Definiert, ob abgelehnte Pakete ins System-Log geschrieben werden
sollen.

\configlabel{INPUT\_LIST\_x}{INPUTLISTx}
\config{INPUT\_LIST\_N INPUT\_LIST\_x}{INPUT\_LIST\_N}{INPUTLISTN}

Liste der Regeln, die beschreiben, welche Pakete vom Router angenommen
bzw. verworfen werden.

\config{INPUT\_LOG\_LIMIT}{INPUT\_LOG\_LIMIT}{INPUTLOGLIMIT}

Definiert, wie häufig Log-Einträge generiert werden, die Häufigkeit
wird analog zur Limit-Einschränkung als n pro Zeiteinheit mit Bursts
beschrieben, also z.B. '3/minute:5'. Ist dieser Eintrag leer, wird keine Limitierung durchgeführt.

\configlabel{INPUT\_UDP\_REJ\_LIMIT}{INPUTUDPREJLIMIT}
\config{INPUT\_REJ\_LIMIT INPUT\_UDP\_REJ\_LIMIT}{INPUT\_REJ\_LIMIT}{INPUTREJLIMIT}

Definiert, wie häufig bei einer Ablehnung eines reinkommenden Paketes
auch ein entsprechendes Reject-Paket generiert wird, die Häufigkeit
wird analog zur Limit-Einschränkung als n pro Zeiteinheit mit Bursts
beschrieben, also z.B. '3/minute:5'. Ist das Limit überschritten, wird
das Paket einfach gedroppt. Ist dieser Eintrag leer, wird keine Limitierung durchgeführt.

\end{description}

\subsubsection{Die Forward-Liste}

Über die Forward-Liste wird konfiguriert, welche Pakete vom Router
weitergeleitet werden. Trifft keine der Regeln der Forward-Liste zu,
bestimmt die Default-Policy, was mit dem Paket passieren soll und die
Log-Variable, ob es bei einer Ablehnung ins System-Log geschrieben
werden soll.

Bei den verwendeten Parametern gibt es zwei Einschränkungen:
\begin{itemize}
\item {\em MASQUERADE} und {\em SNAT} können nicht als Aktion angegeben werden.
\item {\em REJECT} kann (momentan noch) nicht als Aktion angegeben werden.
\end{itemize}

\begin{description}
\config{FORWARD\_POLICY}{FORWARD\_POLICY}{FORWARDPOLICY}

Die Default Policy wird angewand, wenn keine der Regeln
zutrifft. Möglich sind:

\begin{itemize}
\item ACCEPT
\item DROP
\end{itemize}

\config{FORWARD\_ACCEPT\_DEF}{FORWARD\_ACCEPT\_DEF}{FORWARDACCEPTDEF}

Bestimmt, ob der Router Pakete akzeptiert, die zu bestehenden
Verbindungen gehören. Steht diese Variable auf 'yes', generiert fli4l
automatisch eine Regel, die Pakete mit dem entsprechenden Zustand
akzeptiert.

\config{FORWARD\_LOG}{FORWARD\_LOG}{FORWARDLOG}

Definiert, ob abgelehnte Pakete ins System-Log geschrieben werden
sollen.

\config{FORWARD\_LOG\_LIMIT}{FORWARD\_LOG\_LIMIT}{FORWARDLOGLIMIT}

Definiert, wie häufig Log-Einträge generiert werden, die Häufigkeit
wird analog zur Limit-Einschränkung als n pro Zeiteinheit mit Bursts
beschrieben, also z.B. '3/minute:5'. Ist dieser Eintrag leer, wird keine Limitierung durchgeführt.

\configlabel{FORWARD\_UDP\_REJ\_LIMIT}{FORWARDUDPREJLIMIT}
\config{FORWARD\_REJ\_LIMIT FORWARD\_UDP\_REJ\_LIMIT}{FORWARD\_REJ\_LIMIT}{FORWARDREJLIMIT}

Definiert, wie häufig bei einer Ablehnung eines reinkommenden Paketes
auch ein entsprechendes Reject-Paket generiert wird, die Häufigkeit
wird analog zur Limit-Einschränkung als n pro Zeiteinheit mit Bursts
beschrieben, also z.B. '3/minute:5'. Ist das Limit überschritten, wird
das Paket einfach gedroppt. Ist dieser Eintrag leer, wird keine Limitierung durchgeführt.

\configlabel{FORWARD\_LIST\_x}{FORWARDLISTx}
\config{FORWARD\_LIST\_N FORWARD\_LIST\_x}{FORWARD\_LIST\_N}{FORWARDLISTN}

Liste der Regeln, die beschreiben, welche Pakete vom Router
weitergeleitet werden bzw. verworfen werden.

\end{description}

\subsubsection{Die NAT-Listen (network address translation)}

Pakete können vor und nach Routing-Entscheidungen noch manipuliert
werden, sie können zum Beispiel eine neue Zieladresse erhalten, um sie
an einen anderen Rechner weiterzuleiten (Portforwarding) oder eine
andere Quell-Adresse erhalten, um das hinter dem Router liegende
Netzwerk zu maskieren. Maskieren nutzt man z.B. um ein privates Netz
über eine öffentliche IP ins Netz zu bringen oder in einem DMZ Setup
die Struktur des lokalen Netzes vor den Rechnern in der DMZ zu
verbergen.

Die Konfiguration erfolgt über zwei Listen, die pre- und die
postrouting-Liste.

Über die Postrouting-Liste wird konfiguriert, welche Pakete vom Router
maskiert werden. Trifft keine der Regeln der Postrouting-Liste zu,
werden die Pakete unmaskiert weitergeleitet.

Beim Maskieren gibt es zwei Varianten, eine für Interfaces, die bei
der Einwahl erst eine IP zugewiesen bekommen ({\em MASQUERADE}) und
eine für Interfaces mit statischer IP ({\em SNAT}). Letzteres erwartet
dabei zusätzliche Parameter:
\begin{itemize}
\item die IP, die im Paket als Quelle eingetragen werden soll. Diese
  kann als
  \begin{itemize}
  \item IP-Adresse (SNAT:1.2.3.4),
  \item IP-Bereich (SNAT:1.2.3.4-1.2.3.10),

  \item oder als Interface-Name angegeben werden, dessen IP-Adresse
    als Quelle dienen soll (SNAT:ip:eth\_x\_ipaddr).
  \end{itemize}
\end{itemize}

Bei beiden kann ein Port/Portbereich angegeben werden, auf den der
Quellport gemapped werden soll (Normalerweise ist das nicht nötig,
da der Kern die Ports allein auswählen  kann. Es gibt aber
Anwendungen, die verlangen, daß der Quellport unverändert bleibt
(erfordern ein 1:1 NAT oder verbieten PAT (Port Address Translation)
bzw. NAPT (Network Port Address Translation)). Der Portbereich wird
einfach hinten angehängt, z.B. so: SNAT:IP\_NET\_1\_IPADDR:4000-8000.

Bei den verwendeten Parametern gibt es zwei Einschränkungen:
\begin{itemize}
\item {\em DROP} kann nicht als Aktion angegeben werden.
\item {\em REJECT} kann nicht als Aktion angegeben werden.
\end{itemize}

\begin{description}

\configlabel{POSTROUTING\_LIST\_x}{POSTROUTINGLISTx}
\config{POSTROUTING\_LIST\_N POSTROUTING\_LIST\_x}{POSTROUTING\_LIST\_N}{POSTROUTINGLISTN}

Liste der Regeln, die beschreiben, welche Pakete vom Router maskiert
werden (bzw. unmaskiert weitergeleitet werden). Will man Pakete vom
Maskieren ausklammern, kann man eine Accept-Regel für die
auszuklammernden Pakete der Masquerade-Regel voranstellen.

\end{description}

Über die Prerouting-Liste wird konfiguriert, welche Pakete an einen
anderen Rechner weitergeleitet werden sollen. Trifft keine der Regeln
der Prerouting-Liste zu, werden die Pakete unverändert
weiterbehandelt.

DNAT erwartet als Parameter eine IP, die als neue Adresse des Paketes
eingetragen werden soll und akzeptiert auch einen neuen Port:
\begin{itemize}
\item IP-Adresse: DNAT:1.2.3.4
\item IP-Adresse und neuer Port: DNAT:1.2.3.4:8080
\item IP-Adresse als Name: DNAT:client1
\end{itemize}

Redirect verhält sich wie DNAT, nur daß die Ziel-IP-Adresse immer auf
127.0.0.1  gesetzt wird und damit das Paket lokal zugestellt wird.

Will man Portforwarding auf Interfaces mit dynamischen IPs machen,
weiß man zum Zeitpunkt der Konfiguration noch nicht, an welche IP die
Pakete gerichtet sein werden. Daher kann man in der Prerouting-Liste
{\em dynamic } als Platzhalter für die später zugewiesene IP
verwenden. z.B. wie folgt:

\begin{example}
\begin{verbatim}
    'dynamic:80  DNAT:1.2.3.4'           # forwarde http-Pakete
                                         # an die ip 1.2.3.4
    'prot:gre any dynamic DNAT:1.2.3.4'  # forwarde gre (teil des pptp
                                         # protokolls) an die ip 1.2.3.4
\end{verbatim}
\end{example}

Bei den verwendeten Parametern gibt es eine Einschränkung, {\em
  REJECT} kann nicht als Target angegeben werden.

\begin{description}

\configlabel{PREROUTING\_LIST\_x}{PREROUTINGLISTx}
\config{PREROUTING\_LIST\_N PREROUTING\_LIST\_x}{PREROUTING\_LIST\_N}{PREROUTINGLISTN}

Liste der Regeln, die beschreiben, welche Pakete vom Router an ein
anderes Ziel weitergeleitet werden sollen.
\end{description}
\subsection{Beispiele}

Im folgenden einige Beispiele für die neue Konfiguration.


\subsubsection{Die Fli4l-Standardkonfiguration}

Die fli4l-Standardkonfiguration der Distribution sah wie folgt aus,
wenn man alle deaktivierten Optionen wegläßt:

\begin{example}
\begin{verbatim}
    MASQ_NETWORK='192.168.6.0/24' # networks to masquerade (e.g. our LAN)
    INPUT_POLICY='REJECT'         # policy for input chain: reject or drop
    FORWARD_DENY_PORT_N='1'       # no. of ports to reject/deny forwarding
    FORWARD_DENY_PORT_1='137:139 reject'  # drop/reject forwarding of netbios
    DENY_ICMP='no'                # deny icmp (ping): yes or no
    PACKETFILTER_LOG='no'         # log access to rejected/denied ports
\end{verbatim}
\end{example}

Nehmen wir diese Optionen und die im Paketfilter-Kapitel beschriebenen
Annahmen, sieht eine Übersetzung ins neue Schema wie folgt aus:

\begin{example}
\begin{verbatim}
    INPUT_POLICY='REJECT'
    INPUT_ACCEPT_DEF='yes'
    INPUT_LOG='no'
    INPUT_LIST_N='1'
    INPUT_LIST_1='IP_NET_1 ACCEPT'
\end{verbatim}
\end{example}

Damit erreichen wir, daß
\begin{itemize}
\item Rechner im lokalen Netzwerk auf den Router zugreifen dürfen
  (Regel 1),
\item lokale Kommunikation auf dem Router erlaubt ist
  (\var{INPUT\_ACCEPT\_DEF}),
\item Pakete, die zu vom Router aufgebauten Verbindungen gehören,
  akzeptiert werden (\var{INPUT\_ACCEPT\_DEF}),
\item alles andere abgelehnt wird (\var{INPUT\_POLICY}),
\item aber nicht ins Systemlog geschrieben wird.
\end{itemize}

Für die Forward-Liste sieht das so ähnlich aus. Nur Pakete unseres
lokalen Netzes und Pakete, die zu Verbindungen gehören, die von
Rechnern im lokalen Netz aufgebaut wurden, sollen weitergeleitet
werden. Netbios-Pakete und der neue cifs Port werden verworfen.

\begin{example}
\begin{verbatim}
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'
    FORWARD_LIST_N='2'
    FORWARD_LIST_1='tmpl:samba DROP'
    FORWARD_LIST_2='IP_NET_1 ACCEPT'
\end{verbatim}
\end{example}

Was man hier gut sieht, ist die Abhängigkeit von der Reihenfolge der
Regeln. Als erstes werden Netbios-Pakete verworfen, dann werden die
Pakete des lokalen Netzes akzeptiert.

Nun kann das lokale Netz mit dem Router kommunizieren, seine Pakete
werden weitergeleitet, es fehlt nur noch das Maskieren, welches für
den Zugriff eines privaten Netzwerkes auf das Internet notwendig ist:

\begin{example}
\begin{verbatim}
    POSTROUTING_LIST_N='1'
    POSTROUTING_LIST_1='IP_NET_1  MASQUERADE'
\end{verbatim}
\end{example}

Für diesen einfachen Fall sieht die ursprüngliche Konfiguration
wesentlich einfacher aus. Das ändert sich, wenn wir die anderen
Optionen mit hinzunehmen, die da sind:

\begin{itemize}
\item trusted nets
\item route network
\item white list
\item black list
\end{itemize}


\subsubsection{Trusted Nets}

Wollen wir lokal mehrere Subnetze haben, die frei und unmaskiert
miteinander kommunizieren können, müssen wir dasfür sorgen, daß Pakete
zwischen diesen Subnetzen nicht verworfen und auch nicht maskiert
werden. Dazu wurden in der originalen FW-Konfiguration diese Netze in
\var{TRUSTED\_NETS} aufgezählt. In der neuen Konfiguration fügen wir
einfach eine Regel hinzu oder modifizieren die vorhandene.

Angenommen, die beiden Subnetze sind \var{IP\_NET\_1} (192.168.6.0/24) und
\var{IP\_NET\_2} (192.168.7.0/24) und wir haben einen DSL-Zugang über pppoe.
Dann würde die Konfiguration wie folgt aussehen:

\begin{example}
\begin{verbatim}
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'
    FORWARD_LIST_N='4'
    FORWARD_LIST_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
    FORWARD_LIST_2='tmpl:samba DROP'
    FORWARD_LIST_3='IP_NET_1 ACCEPT'
    FORWARD_LIST_4='IP_NET_2 ACCEPT'

    POSTROUTING_LIST_N='3'
    POSTROUTING_LIST_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
    POSTROUTING_LIST_2='IP_NET_1 MASQUERADE'
    POSTROUTING_LIST_3='IP_NET_2 MASQUERADE'
\end{verbatim}
\end{example}

Die Regel eins sorgt jetzt dafür, daß Pakete zwichen den beiden
Subnetzen ohne weitere Prüfung weitergeleitet werden. Regel 3 und 4 sorgen
dafür, daß beide Subnetze auch ins Internet kommen. Die erste Regel
der MASQ-Liste sorgt dafür, daß die Kommunikation zwischen den
Subnetzen unmaskiert erfolgt. Alternativ könnten wir auch sagen, daß
nur Pakete, die über das pppoe-Device rausgehen, maskiert werden
sollen:

\begin{example}
\begin{verbatim}
    POSTROUTING_LIST_N='1'
    POSTROUTING_LIST_1='if:any:pppoe MASQUERADE'
\end{verbatim}
\end{example}

Genauso hätte man die Filterung der Ports auch auf das pppoe-device
beschränken und die beiden Subnetze zu einem zusammenfassen können,
das würde dann wie folgt aussehen:

\begin{example}
\begin{verbatim}
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'
    FORWARD_LIST_N='2'
    FORWARD_LIST_1='if:any:pppoe tmpl:samba DROP'
    FORWARD_LIST_2='192.168.6.0/23 ACCEPT'

    POSTROUTING_LIST_N='1'
    POSTROUTING_LIST_1='if:any:pppoe MASQUERADE'
\end{verbatim}
\end{example}

Pakete, die über das pppoe-Device hinaus gehen und die an die Ports
137-138 udp sowie 139 und 445 tcp adressiert sind, werden verworfen
(Regel 1), alle anderen Pakete, die aus dem Subnetz 192.168.6.0/23
kommen, werden weitergeleitet (Regel 2).

\subsubsection{Route Network}

Fügen wir dem ganzen noch ein Netzwerk 10.0.0.0/24 hinzu (z.B. ein
Dial-In-Netzwerk, mit dem wir unmaskiert kommunizieren wollen, wobei
die Ports 137-138 udp, 139 und 445 tcp verworfen werden sollen. Das würde wie
folgt aussehen:

\begin{example}
\begin{verbatim}
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'
    FORWARD_LIST_N='4'
    FORWARD_LIST_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
    FORWARD_LIST_2='tmpl:samba DROP'
    FORWARD_LIST_3='192.168.6.0/23 ACCEPT'
    FORWARD_LIST_4='10.0.0.0/24 ACCEPT'

    POSTROUTING_LIST_N='2'
    POSTROUTING_LIST_1='10.0.0.0/24 ACCEPT BIDIRECTIONAL'
    POSTROUTING_LIST_2='192.168.6.0/23 MASQUERADE'
\end{verbatim}
\end{example}

\begin{itemize}
\item Regel 1 erlaubt die freie Kommunikation zwischen den Subnetzen
  \var{IP\_NET\_1} und \var{IP\_NET\_2}
\item Regel 2 verwirft die Samba-Ports
\item Regel 3 und 4 lassen Pakete durch, die aus den Subnetzen
  192.168.6.0/24, 192.168.7.0/24 und 10.0.0.0/24 kommen, die
  Rückrichtung wird von \var{FORWARD\_\-ACCEPT\_\-DEF}='yes'
  abgedeckt.
\item Regel 1 der Masq-Liste sorgt dafür, daß Pakete in das/aus dem
  10.0.0.0/24 Subnetz nicht maskiert werden.
\end{itemize}

Alternativ ginge auch:

\begin{example}
\begin{verbatim}
    POSTROUTING_LIST_N='1'
    POSTROUTING_LIST_1='if:any:pppoe MASQUERADE'
\end{verbatim}
\end{example}

Nur Pakete, die über das pppoe-Interface hinausgehen, werden maskiert.


\subsubsection{Blacklists, Whitelists}

Blacklists (ein Rechner in dieser Liste darf etwas nicht) und
Whitelists (ein Rechner in dieser Liste darf etwas) werden prinzipiell
ähnlich umgesetzt. Es werden Regeln geschrieben, die am Anfang sehr
speziell sind und nach hinten immer allgemeiner werden. Bei einer
Blacklist stehen am Anfang Regeln, die etwas verbieten und am Ende
Regeln, die allen bisher nicht erwähnten etwas erlauben, bei einer
Whitelist ist es genau umgekehrt. Einfaches Beispiel: Alle Rechner im
Subnetz 192.168.6.0/24 außer Rechner 12 dürfen ins Internet, solange
sie nicht mit den CIFS Ports 137-138 udp, 139 und 445 tcp kommunizieren wollen:

\begin{example}
\begin{verbatim}
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'
    FORWARD_LIST_N='3'
    FORWARD_LIST_1='192.168.6.12 DROP'
    FORWARD_LIST_2='tmpl:samba DROP'
    FORWARD_LIST_3='192.168.6.0/23 ACCEPT'

    POSTROUTING_LIST_N='1'
    POSTROUTING_LIST_2='192.168.6.0/24 MASQUERADE'
\end{verbatim}
\end{example}

Nur Rechner 12 darf ins Internet (aber nicht an die Ports ...), alle
anderen dürfen nur lokal mit einem anderen Subnetz kommunizieren:

\begin{example}
\begin{verbatim}
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'
    FORWARD_LIST_N='3'
    FORWARD_LIST_1='192.168.6.0/24 192.168.7.0/24 ACCEPT BIDIRECTIONAL'
    FORWARD_LIST_2='tmpl:samba DROP'
    FORWARD_LIST_3='192.168.6.12 ACCEPT'

    POSTROUTING_LIST_N='1'
    POSTROUTING_LIST_1='if:any:pppoe MASQUERADE'
\end{verbatim}
\end{example}

\subsection{Standardkonfigurationen}

\subsubsection{Einfacher maskierender Router mit einem Netz dahinter}

\begin{example}
\begin{verbatim}
ORIG_FW_CONFIG='no'
NEW_FW_CONFIG='yes'

#
# Zugriff auf den Router
#
INPUT_POLICY='REJECT'
INPUT_ACCEPT_DEF='yes'
INPUT_LOG='no'
INPUT_LIST_N='1'
INPUT_LIST_1='IP_NET_1 ACCEPT'   # alle hosts im lokalen netz dürfen
				 # auf den router zugreifen

#
# Zugriff auf das ``Internet''
#
FORWARD_POLICY='REJECT'
FORWARD_ACCEPT_DEF='yes'
FORWARD_LOG='no'

FORWARD_LIST_N='2'
FORWARD_LIST_1='tmpl:samba DROP' # samba pakete, die das netz
				 # verlassen wollen, werden verworfen
FORWARD_LIST_2='IP_NET_1 ACCEPT' # alle anderen pakete dürfen das
				 # lokale netz verlassen

#
# Maskieren des lokalen Netzes
#
POSTROUTING_LIST_N='1'
POSTROUTING_LIST_1='IP_NET_1 MASQUERADE'  # masquerade traffic leaving
                                 # the subnet
\end{verbatim}
\end{example}
\subsubsection{Einfacher maskierender Router mit zwei Netzen dahinter}

\begin{example}
\begin{verbatim}
ORIG_FW_CONFIG='no'
NEW_FW_CONFIG='yes'

#
# Zugriff auf den Router
#
INPUT_POLICY='REJECT'
INPUT_ACCEPT_DEF='yes'
INPUT_LOG='no'
INPUT_LIST_N='2'
INPUT_LIST_1='IP_NET_1 ACCEPT'   # alle hosts im lokalen netz dürfen
				 # auf den router zugreifen
INPUT_LIST_2='IP_NET_2 ACCEPT'   # alle hosts im lokalen netz dürfen
				 # auf den router zugreifen

#
# Zugriff auf das ``Internet''
#
FORWARD_POLICY='REJECT'
FORWARD_ACCEPT_DEF='yes'
FORWARD_LOG='no'

#
# Kein Samba zwischen den Netzen
#
FORWARD_LIST_N='3'
FORWARD_LIST_1='tmpl:samba DROP' # samba pakete, die das netz
				 # verlassen wollen, werden verworfen
FORWARD_LIST_2='IP_NET_1 ACCEPT' # alle anderen pakete dürfen das
				 # lokale netz verlassen
FORWARD_LIST_3='IP_NET_2 ACCEPT' # alle anderen pakete dürfen das
				 # lokale netz verlassen

#
# Freie Kommunikation zwischen den Netzen
#
FORWARD_LIST_N='4'
FORWARD_LIST_1='IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
FORWARD_LIST_2='tmpl:samba DROP' # samba pakete, die das netz
				 # verlassen wollen, werden verworfen
FORWARD_LIST_3='IP_NET_1 ACCEPT' # alle anderen pakete dürfen das
				 # lokale netz verlassen
FORWARD_LIST_4='IP_NET_2 ACCEPT' # alle anderen pakete dürfen das
				 # lokale netz verlassen

#
# Maskieren der lokalen Netze, unmaskierte Kommunikation zwischen den
# Netzen
#
POSTROUTING_LIST_N='3'
POSTROUTING_LIST_1'IP_NET_1 IP_NET_2 ACCEPT BIDIRECTIONAL'
POSTROUTING_LIST_2='IP_NET_1 MASQUERADE'  # masquerade traffic leaving
                                 	  # the subnet
POSTROUTING_LIST_3='IP_NET_2 MASQUERADE'  # masquerade traffic leaving
                                 	  # the subnet
\end{verbatim}
\end{example}

\subsubsection{Maskierender DSL-Router mit zwei Netzen dahinter und
ssh/http-Zugriff aus dem Internet}

\begin{example}
\begin{verbatim}
ORIG_FW_CONFIG='no'
NEW_FW_CONFIG='yes'

#
# Zugriff auf den Router
#
INPUT_POLICY='REJECT'
INPUT_ACCEPT_DEF='yes'
INPUT_LOG='no'
INPUT_LIST_N='4'
INPUT_LIST_1='IP_NET_1 ACCEPT'   # alle hosts im lokalen netz dürfen
				 # auf den router zugreifen
INPUT_LIST_2='IP_NET_2 ACCEPT'   # alle hosts im lokalen netz dürfen
				 # auf den router zugreifen
INPUT_LIST_3='tmpl:ssh ACCEPT'   # gestatte Zugriff auf ssh-Service
				 # von Überall her
INPUT_LIST_4='tmpl:http 1.2.3.4/24 ACCEPT'  # gestatte Rechner aus
				 # einem bestimmten Subnetz Zugriff
				 # auf http-Service


#
# Zugriff auf das ``Internet''
#
FORWARD_POLICY='REJECT'
FORWARD_ACCEPT_DEF='yes'
FORWARD_LOG='no'

#
# Keine Kommunikation zwischen den Netzen, beide Netze dürfen ins 
# Internet, Samba-Pakete werden verworfen
#
FORWARD_LIST_N='2'
FORWARD_LIST_1='tmpl:samba if:any:pppoe DROP' # samba pakete, die das netz
				     # verlassen wollen, werden verworfen
FORWARD_LIST_2='if:any:pppoe ACCEPT' # alle anderen pakete dürfen das
				     # lokale netz verlassen

#
# Maskieren der lokalen Netze, unmaskierte Kommunikation zwischen den
# Netzen
#
POSTROUTING_LIST_N='1'
POSTROUTING_LIST_1='if:any:pppoe MASQUERADE'  # masquerade traffic leaving
                                	      # the subnet
\end{verbatim}
\end{example}


\subsubsection{Portforwarding}

Will man statt der alten Portforwarding-Konfiguration die neue
verwenden, läßt sich das wie folgt übersetzen:

\begin{example}
\begin{verbatim}
TARGET='<port>'
NEW_TARGET='<ip>'
PROTOCOL='<proto>'
PREROUTING_LIST_x='prot:<proto> dynamic:<port> DNAT:<ip>'

TARGET='<port1>-<port2>'
NEW_TARGET='<ip>'
PROTOCOL='<proto>'
PREROUTING_LIST_x='prot:<proto> dynamic:<port1>-<port2> DNAT:<ip>'

TARGET='<ip>:<port-a>'
NEW_TARGET='<ip>:<port-b>'
PROTOCOL='<proto>'
PREROUTING_LIST_x='prot:<proto> <ip>:<port-a> DNAT:<ip>:<port-b>'
\end{verbatim}
\end{example}

\subsubsection{Transparent Proxy}
Will man bestimmte Zugriffe auf das Internet nur über einen lokalen Proxy
zulassen, kann man das mit Hilfe der Pre/Postroutinglisten erzwingen,
ohne dass der Client davon etwas merkt.

Prinzipiell sind dazu drei Schritte notwendig:

\begin{enumerate}
\item Anfragen an den http Port, die nicht vom proxy kommen, an den
Proxy umleiten (PREROUTING).
\item Die umgeleiteten Pakete so verändern, dass der Proxy denkt, sie
kommen vom Router, sodaß er sie wieder dorthin zurückschickt (POSTROUTING).
\item Die Pakete durch die Forwardchain durchlassen, sofern ein
Eintrag alà \var{FORWARD\_LIST\_x}='IP\_NET\_1 ACCEPT' nicht existiert (FORWARD).
\end{enumerate}

1. Beispiel: Angenommen wir haben nur ein Netz \var{IP\_NET\_1}, 
in dem auf einem Rechner namens ``proxy'' ein Squid läuft und
wollen den gesamten http-Traffic über ihn leiten. Squid lauscht auf 
Port 3128. Der Einfachheit halber beziehen wir uns via '@proxy' auf den
eingetragenen Host aus \var{HOST\_1\_NAME}='proxy' (vgl.
\jump{sec:domainkonfiguration}{Domainkonfiguration}).

Das ganze würde wie folgt aussehen:


\begin{example}
\begin{verbatim}
...
  PREROUTING_LIST_x='@proxy ACCEPT'
      # Pakete vom Proxy sollen nicht umgeleitet werden

  PREROUTING_LIST_x='prot:tcp IP_NET_1 any:80 DNAT:@proxy:3128'
      # http-Pakete aus IP_NET_1 mit einem beliebigen Ziel werden
        umgeleitet nach @proxy Port 3128

  POSTROUTING_LIST_x='any @proxy:3128 SNAT:IP_NET_1_IPADDR'
      # alle Pakete an den Proxy Port 3128 so umschreiben als wären sie
        vom fli4l (IP_NET_1_IPADDR)

  FORWARD_LIST_x='prot:tcp @proxy 80 ACCEPT'
      # http-Pakete vom Proxy durch die Forwardchain durchlassen
        (wenn nötig)
...
\end{verbatim}
\end{example}

Gibt es mehrere Netze oder potentielle Konflikte mit anderen
Portforwardings (die ja auchnichts anderes sind als DNAT-Regeln), muss
man die Regeln vielleicht noch etwas enger formulieren. 

2. Beispiel: Unser Proxy namens ``proxy'' steht in \var{IP\_NET\_1}, lauscht
auf Port 3128 und soll nur für Clients aus \var{IP\_NET\_1} wirksam werden.
\var{IP\_NET\_1} ist über \var{IP\_NET\_1\_DEV} erreichbar. Pakete aus weiteren Netzen
sollen nicht berücksichtigt werden.

\begin{example}
\begin{verbatim}
...
  PREROUTING_LIST_x='if:ip_net_1_dev:any !@proxy 80 DNAT:@proxy:3128'
      # Anfragen an den http Port, die nicht vom proxy aber über ein
        internes Interface (ip_net_1_dev) kommen, an den Proxy Port
        umleiten
      # An dieser Stelle ist es wichtig, mit if:ip_net_1_dev:any zu
        überprüfen ob die Pakete von innen kommen da sonst auch Pakete
        von außen
      # umgeleitet werden würden (Sicherheitslücke)

  POSTROUTING_LIST_x='prot:tcp IP_NET_1 @proxy:3128
SNAT:IP_NET_1_IPADDR'   # (alles eine Zeile!)
      # http-Pakete die aus IP_NET_1 stammen und für den Proxy Port 3128
        gedacht sind, so umschreiben als wären sie vom fli4l
       (IP_NET_1_IPADDR)

  FORWARD_LIST_x='prot:tcp @proxy 80 ACCEPT'
      # http-Pakete vom proxy durch die Forwardchain durchlassen (wenn
        nötig)
...
\end{verbatim}
\end{example}

3. Beispiel: Um sich das Leben etwas zu erleichtern und die Regeln
kürzer zu gestalten, kann man auch Templates einsetzen (vgl. \jump{sec:templates}{Templates im Paketfilter}).
Zweckmäßig ist an dieser Stelle das tmpl:http.

tmpl:http wird zu 'prot:tcp any any:80' und so wird bspw. aus 
'tmpl:http IP\_NET\_1 DNAT:@proxy:3128' 'prot:tcp IP\_NET\_1 80 DNAT:@proxy:3128'

Sowohl \var{IP\_NET\_1} als auch \var{IP\_NET\_2} sollen transparent über den Proxy
umgeleitet werden. Damit ließe sich vereinfacht auch schreiben:

\begin{example}
\begin{verbatim}
...
  PREROUTING_LIST_x='tmpl:http @proxy   ACCEPT'
  # http-Pakete von IP_NET_2 sollen umgeleitet werden
  PREROUTING_LIST_x='tmpl:http IP_NET_1 DNAT:@proxy:3128'
  # http-Pakete aus IP_NET_1 sollen umgeleitet werden
  PREROUTING_LIST_x='tmpl:http IP_NET_2 DNAT:@proxy:3128'
  # http-Pakete aus IP_NET_2 sollen umgeleitet werden

  POSTROUTING_LIST_x='IP_NET_1 @proxy:3128 SNAT:IP_NET_1_IPADDR'

  FORWARD_LIST_x='tmpl:http @proxy ACCEPT'
...
\end{verbatim}
\end{example}

Und so ließe sich das endlos fortsetzen \ldots

\marklabel{sec:dmz}{
\subsection{DMZ -- Demilitarisierte Zone}
}

Fli4l gestattet auch den Aufbau einer einfachen DMZ. Voraussetzung ist
ein Router mit drei Interfaces, eines zum WAN (das rote Interface),
eines in die DMZ (das orange Interface) und mindestens eins in lokale
Netzwerke (grüne Interfaces). Die DMZ kann so konfiguriert werden, daß
das im folgenden beschriebene möglich wird.


\subsubsection{Kommunikation zwischen Grün und Rot}

Diese Kommunikation wird ganz normal wie oben beschrieben
konfiguriert.

\subsubsection{Kommunikation zwischen Grün und Orange}

Grüne Netze dürfen frei mit Rechnern im orangen Netz
kommunizieren. Die Rechner im orangen Netz sehen dabei nichts von der
Struktur der grünen Netze; die Verbindungen scheinen alle vom orangen
Interface des Routers auszugehen (SNAT).

Die Rechner aus dem orangen Subnetz dürfen keine Verbindungen in grüne
Netzwerke hinein aufbauen. Es werden lediglich Pakete durchgelassen,
die zu Verbindungen gehören, die von Rechnern eines grünen Netzwerkes
aufgebaut wurden.

\subsubsection{Kommunikation zwischen Rot und Orange}

Verbindungen aus dem roten Netz ins orange Netz können über
Portforwarding eingerichtet werden. Die dort aufgeführten Dienste sind
aus dem Wan erreichbar. Pakete, die zu solchen Verbindungen gehören,
dürfen das orange Netz auch wieder verlassen. Beim Verlassen des
orangen Netzes werden die Pakete maskiert, erhalten also die IP des
roten Interfaces.

Sollen auch andere Pakete das orange Subnet verlassen, muss das separat
konfiguriert werden (DMZ\_ORANGE\_RED\_x).

\subsubsection{Kommunikation zwischen Orange und dem Router}

Rechner aus dem Orangen Netz können ausgewählte Dienste des Routers
nutzen; welche das sind, wird über \var{DMZ\_\-ORANGE\_\-ROUTER\_x}
konfiguriert.

\subsubsection{Konfiguration der DMZ}

Die Typen der Subnetze werden bei ihrer Definition mit
festgelegt. Dazu wurde die Variable IP\_NET\_x\_TYPE eingeführt. Die
anderen Parameter werden in DMZ\_*-Variablen definiert.

\begin{description}

\config{OPT\_DMZ}{OPT\_DMZ}{OPTDMZ}

Aktiviert eine DMZ Konfiguration.

\config{IP\_NET\_x\_TYPE}{IP\_NET\_x\_TYPE}{IPNETxTYPE}

Definiert den Typen des Subnetz. Erlaubte Werte sind 'green' und
'orange'. Wird diese Variable weggelassen, wird das Netz bei der
DMZ-Konfiguration ignoriert.

\config{DMZ\_RED\_DEV}{DMZ\_RED\_DEV}{DMZREDDEV}

Das Interface zum Internet. Dieses kann als pppoe für ein
dsl-Interface, ppp$<$index$>$ für ein ppp-Device, ippp+ für
isdn-Interfaces oder als IP\_NET\_x\_DEV angegeben werden.

\config{DMZ\_NAT}{DMZ\_NAT}{DMZNAT}

Wenn in der DMZ private Adressen genutzt werden, muß der Router diese
maskieren. \var{DMZ\_NAT}='yes' aktiviert das maskieren.

\configlabel{DMZ\_ORANGE\_RED\_x}{DMZORANGEREDx}
\config{DMZ\_ORANGE\_RED\_N
  DMZ\_ORANGE\_RED\_x}{DMZ\_ORANGE\_RED\_N}{DMZORANGEREDN}

Definiert, welche Verbindungen vom orangen Subnetz aus aufgebaut
werden können. Die Syntax entspricht der Syntax des Paketfilters.

\configlabel{DMZ\_ORANGE\_ROUTER\_x}{DMZORANGEROUTERx}
\config{DMZ\_ORANGE\_ROUTER\_N
  DMZ\_ORANGE\_ROUTER\_x}{DMZ\_ORANGE\_ROUTER\_N}{DMZORANGEROUTERN}

Definiert, welche Dienste des Routers im oranges Subnetz in Anspruch
genommen werden können. Die Syntax entspricht der Syntax des Paketfilters.

\config{DMZ\_LOG}{DMZ\_LOG}{DMZLOG}

Aktiviert das Loggen abgelehnter Pakete.
\end{description}

Ein kleines Beispiel mit einem Mail-, Web-Server und einem Web-Proxy in der
DMZ könnte wie folgt aussehen:

\begin{example}
\begin{verbatim}
IP_NET_N='3'
IP_NET_1_DEV='eth0'
IP_NET_1='192.168.6.1/24'
IP_NET_1_TYPE='green'
IP_NET_2_DEV='eth1'
IP_NET_2='192.168.7.1/24'
IP_NET_2_TYPE='green'
IP_NET_3_DEV='eth3'
IP_NET_3='192.168.8.1/24'
IP_NET_3_TYPE='orange'

OPT_DMZ='yes'
DMZ_NAT='yes'
DMZ_LOG='yes'
DMZ_RED_DEV='ppp0'
DMZ_ORANGE_RED_N='2'
DMZ_ORANGE_RED_1='prot:tcp 80 ACCEPT' # allow access to http
DMZ_ORANGE_RED_2='prot:tcp 25 ACCEPT' # allow access to smtp
DMZ_ORANGE_ROUTER_N='1'
DMZ_ORANGE_ROUTER_1='53 ACCEPT'       # accept dns requests

PORTFW_N='2'
PORTFW_1_TARGET='80'                  # forward http
PORTFW_1_NEW_TARGET='192.168.8.2'     # ...to dmz host 192.168.8.2
PORTFW_1_PROTOCOL='tcp'               # ...using tcp
PORTFW_2_TARGET='25'                  # forward smtp
PORTFW_2_NEW_TARGET='192.168.8.3'     # ...to dmz host 192.168.8.3
PORTFW_2_PROTOCOL='tcp'               # ...using tcp

\end{verbatim}
\end{example}

\marklabel{sec:portfw}{
\subsection{Port-Forwarding}
}

  Für einige Internet-Protokolle ist es nötig, einen Verbindungsaufbau
  eines Rechners von außen in das interne Netz umzuleiten. Ist das
  Netz nach außen hin maskiert (IP-Masquerading), also nur eine
  offizielle IP-Adresse für das gesamte LAN vorhanden, kann man
  bestimmte Ports oder Protokolle, die von außen erreichbar sein
  sollen, auf einen bestimmten internen Rechner umleiten. Dieses nennt
  man Port-Forwarding (bzw. allgemeiner Destination Network Address
  Translation, kurz DNAT).  Die Problematik des Port-Forwarding wird
  bei der Beschreibung von \var{MASQ\_\-MODULE\_\-N} noch
  angesprochen (s.u.).

  Oft müssen bei Spielen, Chat oder Internet-Telefonie solche Ports
  freigeschaltet werden. Können dies die Masquerading-Module selber
  nicht lösen, kann man selbst Port-Weiterleitungen einrichten.

  \begin{description}
    \config{PORTFW\_N}{PORTFW\_N}{PORTFWN}

    {Hiermit wird die Anzahl der Port-Weiterleitungen angegeben. Diese
      werden in \var{PORTFW\_\-x\_\-TARGET}, \var{PORTFW\_\-x\_NEW\_\-TARGET} und
      \var{PORTFW\_\-x\_\-PROTOCOL} definiert.}

    \config{PORTFW\_x\_TARGET}{PORTFW\_x\_TARGET}{PORTFWxTARGET}

    { Pakete sind an ein bestimmtes Ziel gerichtet (normalerweise eine
      IP-Adresse und ein Port) und gehören zu einem bestimmten
      Protokoll. Dieses Ziel ist in einem maskierten Netz der Router,
      das eigentliche Ziel liegt aber im maskierten Netz, die Pakete
      müssen also dorthin weitergereicht werden.

      \var{PORTFW\_x\_TARGET} gibt an, an welches Ziel Pakete
      gerichtet sein müssen, um weitergeleitet zu werden.
      Kommt ein solches Paket am Router an, wird es an das eigentliche
      Ziel weitergeleitet.

Das Ziel wird immer durch eine IP-Adresse,
ein Protokoll und evtl. noch einen Port beschrieben. Bei einem Router
mit dynamisch zugewiesener IP-Adresse ist die IP zum Zeitpunkt der
Konfiguration noch nicht bekannt, kann also nicht angegeben
werden. Hier wird das Port-Forwarding erst beim Aufbau der Verbindung
eingerichtet, wenn die IP-Adresse bekannt ist und es bezieht sich
immer auf Pakete, die am Router ankommen und an die dynamisch
zugewiesene IP gerichtet sind.

Im Gegensatz dazu wird das Forwarding bei bekannter IP-Adresse bereits
beim Booten eingerichtet. \wichtig{Bei Routern mit fester IP Adresse
muß diese hier angegeben werden, sonst wird das Port-Forwarding
aufgrund des fehlenden Einwählens nicht korrekt aufgesetzt.}

      Folgende Formate sind hier möglich:

      {\tt \var{PORTFW\_\-x\_\-TARGET}='<port>'}

      Leitet alle Pakete weiter, die
      auf dem Port {\tt <port>} ankommen an einen anderen Rechner weiter.

      {\tt \var{PORTFW\_\-x\_\-TARGET}='<port1>-<port2>'}

      Leitet alle Pakete, die auf den Ports im Bereich zwischen
      {\tt <port1>} und {\tt <port2>} ankommen, an einen anderen Rechner
          weiter.

      {\tt \var{PORTFW\_\-x\_\-TARGET}='<ip>:<port>'}
      {\tt \var{PORTFW\_\-x\_\-TARGET}='<ip>:<port1>-<port2>'}

      Leitet alle Pakete, die auf der IP {\tt <ip>} des Routers auf
      Port {\tt <port>} (oder im Port-Bereich {\tt <port1>-<port2>}) ankommen, an einen anderen Rechner weiter. Die
      IP-Adresse kann über einen der in
      \var{HOST\_x\_NAME/HOST\_x\_ALIAS\_x} angegebenen Namen bzw. als
      Referenz auf \var{IP\_NET\_x} (das in dieser Variable angegebene
      Netzwerk) oder \var{IP\_NET\_x\_IPADDR} (die dort enthaltene
      IP-Adresse) angegeben werden.

      {\tt \var{PORTFW\_\-x\_\-TARGET}='<circuit>:<port>'}

      Leitet alle Pakete, die bei eingewähltem Circuit {\tt <circuit>} an
      der dazugehörigen IP-Adresse am Port {\tt <port>} ankommen, an einen
      anderen Rechner weiter. {\tt <circuit>} ist entweder die Nummer eines
      ISDN-Circuits oder ``pppoe'' für eine DSL-Verbindung (siehe
      Package DSL).}

      {\tt \var{PORTFW\_\-x\_\-TARGET}='none'}

      Keine Einschränkung des Ziels. Alle Pakete, die am Router
      ankommen und zum in \var{PORTFW\_x\_PROTOCOL} angegebenen Protokoll
      gehören, werden an einen anderen Rechner weitergeleitet.

      {\tt \var{PORTFW\_\-x\_\-TARGET}='<ip>:none'}

      Alle Pakete, die am Router ankommen, als Zieladresse die
      angegebene IP-Adresse haben und zum in \var{PORTFW\_x\_PROTOCOL}
      angegebenen Protokoll gehören, werden an einen anderen Rechner
      weitergeleitet.

    \config{PORTFW\_x\_NEW\_TARGET}{PORTFW\_x\_NEW\_TARGET}{PORTFWxNEWTARGET}

    {Dieser Parameter gibt das Ziel eines Port-Forwardings an. Dies
      ist in der Regel ein anderer Computer im internen Netzwerk.
      Folgende Formate sind hier möglich:

      {\tt \var{PORTFW\_\-x\_\-NEW\_TARGET}='<ip>'}

      Leitet alle Pakete, die für diese Regel ankommen, an den Rechner
      mit der IP {\tt <ip>} weiter. Die IP-Adresse kann über einen der
      in \var{HOST\_x\_NAME/HOST\_x\_ALIAS\_x} angegebenen Namen bzw.
      als Referenz auf \var{IP\_NET\_x} (das in dieser Variable
      angegebene Netzwerk) oder \var{IP\_NET\_x\_IPADDR} (die dort
      enthaltene IP-Adresse) angegeben werden.

      {\tt \var{PORTFW\_\-x\_\-NEW\_TARGET}='<ip>:<port>'}

      Leitet alle Pakete, die für diese Regel ankommen, an den Rechner
      mit der IP {\tt <ip>} an den Port {\tt <port>} weiter. Diese Regel
      ist für Portbereiche ({\tt <port1>-<port2>}) unzulässig! Die
      IP-Adresse kann über einen der in
      \var{HOST\_x\_NAME/HOST\_x\_ALIAS\_x} angegebenen Namen bzw. als
      Referenz auf \var{IP\_NET\_x} (das in dieser Variable angegebene
      Netzwerk) oder \var{IP\_NET\_x\_IPADDR} (die dort enthaltene
      IP-Adresse) angegeben werden.}

    \config{PORTFW\_x\_PROTOCOL}{PORTFW\_x\_PROTOCOL}{PORTFWxPROTOCOL}

    {\begin{sloppypar}
        Dieser Parameter gibt das Protokoll an, für das diese Regel
        zutrifft.  Zugelassen sind hier `tcp', `udp', `gre' und die
        Angabe der Protokollnummer (siehe Liste der Protokoll-Nummern
        der IANA unter
        \link{http://www.iana.org/assignments/protocol-numbers}.
    \end{sloppypar}}

    In früheren Versionen bestand die Möglichkeit, eigene Regeln in
    einem speziellen Script abzulegen. Diese Möglichkeit besteht seit
    fli4l 2.1.0 NICHT mehr, da dieses Script das variablengesteuerte
    Port-Forwarding stören würde und eine reibunglose Funktion nicht
    mehr garantiert werden könnte.

    Ich habe auf meiner Homepage ein Script hinterlegt, welches die
    Regeln, die man auf dieser Seite findet, in das
    fli4l-Konfigurationsformat umwandelt. Hiermit können auch
    Port-Forwarding-Scripts aus alten fli4l-Versionen in das neue Format
    umgewandelt werden:

    \link{http://portfolio16.de/fli4l/portfw.pl}

    Mit dem Windows-Client imonc ist es möglich, die Regeln zur
    Laufzeit des Routers zu ändern und die aktualisierte Fassung
    wieder zurück an den fli4l-Router zu schicken.

%    \var{PORTFW\_N} wird gepflegt von Tobias Gruetzmacher
%    (\email{fli4l@portfolio16.de}). Ich leiste keinen Support für
%    Online-Spiele, Filesharing-Programme und andere Anwendungszwecke
%    des \var{PORTFW\_N}.

  \end{description}

\marklabel{sec:masqueradingmodule}{
\subsection{Masquerading Module}
}

    { Die Verwendung von IP-Masquerading\index{Masquerading}
      hat zwar den Vorteil, daß mehrere Rechner im LAN über eine
      einzige offizielle IP-Adresse geroutet werden kann, es gibt aber
      auch Nachteile, die man in Kauf nehmen muß.

      Ein großes Problem ist zum Beispiel, daß kein Rechner von außen
      von sich aus eine Verbindung zu einem Rechner aufnehmen kann.
      Das ist zwar aus Sicherheitsgründen eigentlich durchaus
      erwünscht, aber bestimmte Protokolle funktionieren nicht mehr,
      weil sie einen Verbindungsaufbau von außen einfach erfordern.

      Ein klassisches Beispiel ist ftp. Neben dem Kommunikationskanal,
      auf dem Befehle und Antworten ausgetauscht werden, wird ein
      weiterer Kanal (in Form eines IP-Ports) verwendet, um die
      eigentlichen Nutzdaten zu versenden. fli4l verwendet dafür
      bestimmte Masquerading-Module, um solche zusätzlichen Ports, die
      verwendet werden, ad hoc dann freizuschalten und an den internen
      Rechner weiterzuleiten, wenn sie benötigt werden. Dabei
      ``horcht'' das Masquerading-Modul in den Datenstrom, um zu
      erkennen, wann ein zusätzlicher Port benötigt wird.

      Typische Anwendungen für Masquerading-Module sind
      Chat-Protokolle und Spiele im Internet.

    \begin{description}
    \configlabel{MASQ\_MODULE\_x}{MASQMODULEx}
    \configlabel{MASQ\_MODULE\_x\_OPTION}{MASQMODULExOPTION}
    \config{MASQ\_MODULE\_N  MASQ\_MODULE\_x MASQ\_MODULE\_x\_OPTION}{MASQ\_MODULE\_N}{MASQMODULEN}
    \end{description}

      Bisher wurde für fli4l das ftp-Masquerading-Modul immer
      automatisch geladen. Mittlerweile sind weitere Module verfügbar.
      Diese lassen sich auch mit zusätzlichen Optionen aufrufen. Dies
      ist zum Beispiel dann nötig, wenn ein FTP-Server auf einem
      anderen Port als 21 angesprochen werden soll. Hier eine
      Übersicht aller Module mit ihren Parametern, die vorgegebenen
      Werte sind die Standardwerte:

      \begin{description}
      \item[ftp]             File Transfer Protocol\index{ftp}

        Parameter:
        \begin{description}
        \item[ports=21] Gibt Ports an, die dieses Modul überwachen
          soll.  Wenn also ein FTP-Server auch auf Port 2021
          angesprochen werden soll, muß dieser Parameter
          ``ports=21,2021'' lauten.
%        \item[in\_ports=] Gibt Ports an, auf denen FTP-Server im
%          maskierten Netz erreicht werden können. Wird z.B. der Port
%          2121 auf einen FTP-Server weitergeleitet, dann lautet dieser
%          Parameter ``in\_ports=2121''. Weitere Ports können, mit
%          Komma getrennt, angegeben werden.
%        \item[noport=6000] Hiermit kann die Sicherheit von
%          FTP-Verbindungen erhöht werden. Hier angegebene Ports können
%          nicht für FTP- Datenverbindungen benutz werden.
%          Standardmäßig sind alle Ports unter 1024 und der Port 6000
%          (X-Windows) gesperrt.  Siehe
%          \link{http://www.securityfocus.com/templates/archive.pike?list=82\&date=2000-03-08\&msg=38C8C8EE.544524B1@enternet.se}{http://www.securityfocus.com/templates/archive.pike?''list=82\&date=2000-03-08''\&msg=38C8C8EE.544524B1@enternet.se}
%        \item[mark=0]
%        \item[in\_mark=0] Werden diese Optionen auf ``1'' gestellt,
%          werden die FTP-Pakete für die Firewall markiert. Diese
%          Option ist nur für erfahrene Benutzer relevant.
        \end{description}

      \item[irc] Internet Relay Chat\index{irc}

        Parameter:
        \begin{description}
        \item[ports=6667] Gibt die Ports an, auf denen ein IRC-Server
          laufen kann, zu dem man sich verbinden möchte.
%        \item[insecure=0] Auf ``1'' setzen, um einige
%          Sicherheitsabfragen auszuschalten.
        \end{description}
        Bemerkungen: mIRC\index{mIRC} ist standardmäßig falsch
        konfiguriert, so daß er nicht mit diesem Modul
        zusammenarbeitet. Um mIRC richtig einzustellen, geht man
        folgendermaßen vor (Verbindung zum IRC-Server erst trennen):
        Im ``Options''-Dialog: Auswahlliste: ``Connect'', dann ``Local
        Info'', hier beide Eingabefelder löschen (falls etwas drin
        steht), dann ``Lookup Method:'' auf ``Normal'' stellen.

%      \item[h323] H323-Telefonie (z.B. Netmeeting)\index{h323}
%
%        Parameter: keine, horcht immer auf Port 1720
%
%        Bemerkungen: Das h323-Modul ermöglicht IP-Telefonie über das
%        Internet. MS-Netmeeting benutzt dieses Protokoll ebenfalls.
%        Damit `Anrufe' an den Client durchgestellt werden können,
%        müssen die TCP Ports 1503 (T.120) und 1720 (H.323 call setup)
%        an den Client weitergeleitet werden (siehe
%                \jump{PORTFWN}{PORTFW\_N}).
%
%        Homepage:
%        \link{http://www.coritel.it/coritel/ip/sofia/nat/nat2/nat2.htm}
%
%      \item[icq] ICQ - Instant Messenging Service\index{ICQ}
%
%        Parameter:
%        \begin{description}
%        \item[ports=4000] Gibt Ports an, die das Modul auf
%          Verbindungen zu einem ICQ-Server überwachen soll.
%        \item[range=60200,61000] Gibt Ports an, die für
%          Dateiübertragungen benutzt werden sollen.
%        \item[udp\_timeout=600] Wie lange (in Sekunden) soll ein
%          UDP-Paket gültig sein?
%        \item[tcp\_timeout=14400] Wie lange soll eine TCP-Verbindung
%          gültig sein? Da über eine solche Verbindung
%          User-2-User-Chats laufen, wo möglicherweise lange nichts
%          gesagt wird, sollte dieser Wert entsprechend hoch sein. (4
%          Stunden ist Standard)
%        \item[tcp\_fin\_timeout=60] Diese Option einfach so lassen!
%        \item[log=i] Was soll geloggt werden? Hier kann eine Reihe von
%          Buchstaben angegeben werden, bitte in der Orginal- README
%          des Modules nachlesen.
%        \item[limit=512] Beschränkt einige Optionen, damit kein
%          Speicherüberlauf produziert werden kann.
%        \item[hide\_local\_ip=1] IP-Adresse des internen Netzes mit
%          der externen IP ersetzen oder nicht?
%        \item[hide\_remote\_local\_ip=0] Echte IP-Adresse andere
%          Benutzer verstecken?
%        \item[intranet=1] Direktverbindung zwischen zwei ICQ-Benutzern
%          hinter dem gleichen Router erlauben.
%        \end{description}
%        Bemerkungen: Funktionert mit allen ICQ-Versionen bis 99, die
%        2000er funktioneren nicht. Wie es mit 2001 steht, ist noch
%        nicht geklärt.
%
%        Homepage: \link{http://djsf.narod.ru/masq-icq/} (geht zur Zeit
%        noch\ldots)
%
%      \item[raudio] Real Audio\index{Real Audio}
%
%        Parameter:
%        \begin{description}
%        \item[ports=554,7070] Gibt die Ports an, auf denen PNA- und
%          RTSP-Streams übertragen werden.
%        \end{description}
%
%      \item[vdolive] VDOLive
%
%        Parameter:
%        \begin{description}
%        \item[ports=7000] Gibt die VDOLive-Ports an.
%        \end{description}
%
%      \item[quake] Quake\index{Quake}
%
%        Parameter: keine, horcht immer auf Port 26000 und 27000
%
%      \item[cuseeme] CUSeeMe\index{CUSeeMe}
%
%        Parameter:
%        \begin{description}
%        \item[ports=7648] Gibt die CUSeeMe-Ports an.
%        \end{description}
%
%      \item[mms] Microsoft Messenger\index{Microsoft Messenger}
%
%        Parameter:
%        \begin{description}
%        \item[ports=1863] Gibt die Ports des MMS-Servers an.
%        \end{description}
%        Homepage:
%        \link{http://lrp.steinkuehler.net/files/kernels/2.2.19-3-source/patches/files/mmsmasq/}
%
%      \item[pptp] PPTP Masquerading
%
%        Parameter: keine, horcht immer auf 1723
%
%      \item[ipsec] IPSec Masquerading
%
%        Parameter: keine, horcht immer auf 500
%
%      \item[dplay] Direct Play\index{Direct Play}
%
%        Parameter:
%        \begin{description}
%        \item[host=$<$ip$>$] Gibt einen Rechner an, an den alle
%          eingehenden DirectPlay-Anfragen weitergeleitet werden.
%        \end{description}
%        Bemerkungen: Zwei Spieler können nicht auf dem gleichen Server
%        spielen. Steht der Server im maskierten Netz, gehen Pakete von
%        externen Spielern an interne teilweise verloren.
%
%        Homepage: \link{http://dplay-masq.sourceforge.net/}
%
%      \item[msn-0.01] MSN Game Zone - Version 0.01\index{MSN Game
%          Zone}
%      \item[msn-0.02] MSN Game Zone - Version 0.02 (beta)
%
%        Parameter: keine, horcht immer auf 47624
%
%        Bemerkungen: Das 0.02er Modul sollte meistens funktionieren.
%
%        Homepage: \link{http://user.rli.net/kevin/masq.html}
%
%      \item[udp\_dloose] UDP-Loose-Patch, hilft bei manchen
%        Internet-Spielen
%
%        Bemerkungen: Das hier ist eigentlich kein Masqerading-Modul,
%        sondern ein Kernel-Schalter, der einige Restiktionen in der
%        Firewall aufhebt, so daß mehr Pakete ihr Ziel erreichen. Die
%        unten genannte Internet-Seite gibt detailierte Informationen.
%
%        Homepage: \link{http://alumni.caltech.edu/\%7Edank/peer-nat.html}


      \end{description}
      \achtung{Alle Parameter, die eine Liste von Ports annehmen,
      können höchstens 12 Ports übergeben bekommen.}

      Natürlich kann man nicht für jedes Protokoll, welches
      zusätzliche Ports verwendet, ein separates Masquerading-Modul
      programmieren.  Aus diesem Grund gibt es neben den oben
      aufgeführten Modulen auch noch eine andere Möglichkeit, neue
      Ports an einen internen Rechner weiterzuleiten. Siehe dafür auch
      die Beschreibung zu \jump{PORTFWN}{PORTFW\_N} (Port-Forwarding).
          Noch ein Tip: Auf \link{http://www.fli4l.de} wurde speziell zum
          Thema Port-Forwarding eine eigene FAQ eingerichtet.

      Zu den Konfigurationsvariablen:

      \var{MASQ\_\-MODULE\_\-N} gibt die Anzahl der zu ladenden
      Masquerading-Module an.  \var{MASQ\_\-MODULE\_\-x} gibt das x'te zu
      ladende Masquerading-Modul an. Desweitern gibt
      \var{MASQ\_\-MODULE\_\-x\_\-OPTION} die Parameter des entspechenden
      Masquerading- Moduls an. Hier können die oben beschriebenen
      Parameter, mit Leerzeichen getrennt angegeben werden.

      Die Standardeinstellung für \var{MASQ\_\-MODULE\_\-N} ist `1'. Damit wird
      nur das erste Modul, nämlich ftp, geladen. Möchte man weitere
      Module laden, ist \var{MASQ\_\-MODULE\_\-N} entsprechend zu erhöhen. Die
      Reihenfolge in der beigefügten Datei config/base.txt ist nur ein
      Beispiel. Sie kann also beliebig geändert werden, z.B.

\begin{example}
\begin{verbatim}
        MASQ_MODULE_N='2'
        MASQ_MODULE_1='ftp'
        MASQ_MODULE_1_OPTION='ports=21,2121'
        MASQ_MODULE_2='irc'
        MASQ_MODULE_2_OPTION=''
\end{verbatim}
\end{example}

%        MASQ_MODULE_1='ftp'
%        MASQ_MODULE_1_OPTION='ports=21,2121 in_ports=5021,6021'

      Weitere Inhalte von \var{MASQ\_\-MODULE\_\-x} werden einfach ignoriert.

      Hier wurde auch gleich ein Beispiel für die Parameter des
      FTP-Moduls angegeben.}

  \marklabel{sec:domainkonfiguration}{
    \section{Domain-Konfiguration}
  }


  Windows-PCs im LAN haben unter anderem ;-) eine unangenehme
  Eigenschaft: Sobald ein Nameserver benötigt wird und man diesen
  deshalb im Windows einstellt, fragen diese Windows-Rechner den
  angegebenen Nameserver in regelmäßigen Abständen ab (bei mir so alle
  5 Minuten) - auch wenn man gar nicht daran arbeitet!

  Würde man also auf dem Windows-PC einen DNS-Server im Internet angeben,
  wird's teuer :-(

  Der Trick ist nun folgender: Wenn im LAN nicht bereits ein
  DNS-Server vorhanden ist, kann man das DNS im fli4l-Router
  verwenden.

  Es wird DNSMASQ als DNS-Server eingesetzt.

  Wenn man jedoch mit der DNS-Konfiguration beginnt, sollte man sich
  zunächst Gedanken über den Domain-Namen und die Namen der PCs im
  Netz machen. Der verwendete Domain-Name wird nicht im Internet
  sichtbar. Deshalb kann man sich hier prinzipiell beliebige
  Domain-Namen ausdenken.

  Ausserdem sollte man jedem Windows-Rechner einen Namen verpassen.
  Diese Namen müssen dem fli4l-Router bekannt sein.

  \begin{description}

    \config{DOMAIN\_NAME}{DOMAIN\_NAME}{DOMAINNAME}

    {In der Auslieferung ist als Domain einfach ``lan.fli4l''
      eingestellt.  Hier kann sich jeder austoben, da die lokal
      verwendete Domain nicht im Internet sichtbar wird.
      Sie sollten lediglich vermeiden, einen Namen zu benutzen, den es im
      Internet geben könnte (z.B. irgendwas.de), da sie sonst nicht
      auf diese Domain zugreifen können werden.}
      

    \config{DNS\_FORWARDERS}{DNS\_FORWARDERS}{DNSFORWARDERS}

    {Hier ist die DNS-Server-Adresse des Internet-Providers anzugeben,
      wenn fli4l als Router in das Internet verwendet wird. Der
      fli4l-Router gibt dann sämtliche DNS-Queries, die er nicht
      selbst beantworten kann, an diese Adresse weiter.

      Möchte man mehrere DNS-Forwarder angeben, trennt man die
      IP-Adressen durch Blanks.

      \achtung{Achtung: Auch wenn
        \begin{itemize}
        \item \jump{PPPOEUSEPEERDNS}{PPPOE\_USEPEERDNS},
        \item \jump{ISDNCIRCxUSEPEERDNS}{ISDN\_CIRC\_x\_USEPEERDNS}
          oder
        \item \jump{DHCLIENTUSEPEERDNS}{DHCLIENT\_USEPEERDNS}
        \end{itemize}


        gesetzt (='yes') ist, ist hier die Eintragung eines Servers
        nötig, da sonst direkt nach dem Start keine Namensauflösung
        möglich ist.}

      Ausnahme: fli4l als Router in einem lokalen Netz \_ohne\_
      Anschluß an das Internet oder (Firmen-)Netze mit weiteren
      DNS-Servern. In diesem Fall ist 127.0.0.1 anzugeben, um das
      Forwarding zu unterbinden.}


    \config{OPT\_DNS}{OPT\_DNS}{OPTDNS}

    {Um den DNS-Server zu aktivieren ist die Variable \var{OPT\_DNS}
    mit `yes` zu belegen.

    Werden im LAN keine Windows-Rechner verwendet oder ist bereits
      ein DNS-Server vorhanden, kann man \var{OPT\_DNS} auf `no' setzen
      und den Rest in diesem Abschnitt übergehen.

      Im Zweifel immer (Standard-Einstellung): \var{OPT\_DNS}='yes'}

    \config{DNS\_TRIGGER\_DIAL\_IN}{DNS\_TRIGGER\_DIAL\_IN}{DNSTRIGGERDIALIN}
    { Aus diversen Gründen mag es passieren, dass eine
Namensauflösung, die eine Einwahl anstößt, schief geht. Daher kann der
Nameserver vor der eigentlichen Weiterleitung des DNS Requests
explizit ein Paket loschicken, das die Einwahl auslöst. Ist der Router
on-line, wird der eigentliche Request weitergeleitet. Diese Variable
kann 3 Werte annehmen:
\begin{description}
\item[no] Der DNS-Request wird sofort weitergeleitet - sollte genutzt
werden, wenn es keine Einwahl gibt und der Router permanent online
ist.
\item[yes] Es wird ein Paket an die IP 169.254.0.1, Port 9 gesendet,
um eine Einwahl auszulösen.
\item[IP-Adresse] Es wird ein Paket an die angegebene IP, Port 9 gesendet,
um eine Einwahl auszulösen.
\end{description}

Der Standardwert ist \var{DNS\_TRIGGER\_DIAL\_IN}='yes', der empfohlene
Wert für Router, die sich erst einwählen müssen.
}



    \configlabel{DNS\_LISTENIP\_x}{DNSLISTENIPx}
    \config{DNS\_LISTENIP\_N DNS\_LISTENIP\_x}{DNS\_LISTENIP\_N}{DNSLISTENIPN}
                {Wenn Sie \var{OPT\_DNS}='yes' gewählt haben, kann mit
                 \var{DNS\_LISTENIP\_N} die Anzahl, und mit \var{DNS\_LISTENIP\_1} bis
                 \var{DNS\_LISTENIP\_N} lokale IP's angegeben werden, auf denen dnsmasq dns
                 Anfragen annehmen darf. Wenn Sie bei \var{DNS\_LISTENIP\_N} eine 0
                 eingetragen haben, beantwortet dnsmasq dns Anfragen auf allen lokalen
                 IP's.
                 An dieser Stelle dürfen nur IP's von existierenden Schnittstellen
                 (ethernet, wlan ...) verwendet werden, es kommt sonst zu Warnmeldungen
                 beim Start des Routers. Alternativ ist nun möglich hier auch ALIAS-Namen
                 zu verwenden z.b. `IP\_NET\_1\_IPADDR'

                Im Zweifelsfalle können die Standardeinstellungen übernommen werden.}


    \config{DNS\_VERBOSE}{DNS\_VERBOSE}{DNSVERBOSE}

    { Logging von DNS-Queries: `yes' oder `no'

                Für ausführlichere Ausgaben des DNS, muß \var{DNS\_VERBOSE} auf yes
                        gesetzt werden.  In diesem Fall werden DNS-Anfragen
      an den Nameserver protokolliert - und zwar über die
      syslog-Schnittstelle. Damit die Ausgaben auch sichtbar werden,
      ist dann auch die Variable \jump{OPTSYSLOGD}{OPT\_SYSLOGD='yes'}
          zu setzen, s.u.}


    \config{DNS\_MX\_SERVER}{DNS\_MX\_SERVER}{DNSMXSERVER}

      {Mit dieser Variable gibt man hier den Hostnamen für den MX-Record
      (Mail-Exchanger) für die in \var{DOMAIN\_NAME} definierte Domain an.
      Ein MTA (Mail-Transport-Agent, wie z.B. sendmail)
      auf einem internen Server fragt per DNS nach einem Mail-Exchanger
      für die Zieldomain der zuzustellenden Mail. Der DNS-Server liefert
      hiermit dem MTA den entsprechenden Host, der für Mails der Domain
      \var{DOMAIN\_NAME} zuständig ist.

      \achtung{Dies ist keine automatische Konfiguration für Mail-Clients,
      wie z.B. Outlook! Also bitte nicht gmx.de hier eintragen und dann
      wundern, warum Outlook nicht funktioniert.}
      }


    \configlabel{DNS\_FORBIDDEN\_x}{DNSFORBIDDENx}
    \config{DNS\_FORBIDDEN\_N DNS\_FORBIDDEN\_x}{DNS\_FORBIDDEN\_N}{DNSFORBIDDENN}

    {Hier können Domains angegeben werden, bei welchen DNS-Queries vom
      DNS-Server prinzipiell als ``nicht vorhanden'' beantwortet
      werden sollen.

      Beispiel:

\begin{example}
\begin{verbatim}
        DNS_FORBIDDEN_N='1'
        DNS_FORBIDDEN_1='foo.bar'
\end{verbatim}
\end{example}

      In diesem Fall wird zum Beispiel eine Anfrage nach www.foo.bar
      mit einem Fehler beantwortet.

      Man kann damit auch ganze Top-Level-Domains verbieten:

\begin{example}
\begin{verbatim}
        DNS_FORBIDDEN_1='de'
\end{verbatim}
\end{example}

      Dann ist die Namensauflösung für sämtliche Rechner in der
      DE-Topleveldomain abgeschaltet.}


    \configlabel{DNS\_REDIRECT\_x}{DNSREDIRECTx}
    \configlabel{DNS\_REDIRECT\_x\_IP}{DNSREDIRECTxIP}
    \config{DNS\_REDIRECT\_N DNS\_REDIRECT\_x DNS\_REDIRECT\_x\_IP}{DNS\_REDIRECT\_N}{DNSREDIRECTN}

    {Hier können Domains angegeben werden, bei welchen DNS-Queries vom
      DNS-Server auf eine spezielle IP umgeleitet werden.

      Beispiel:

\begin{example}
\begin{verbatim}
        DNS_REDIRECT_N='1'
        DNS_REDIRECT_1='yourdom.dyndns.org'
        DNS_REDIRECT_1_IP='192.168.6.200'
\end{verbatim}
\end{example}

      In diesem Fall wird zum Beispiel eine Anfrage nach yourdom.dyndns.org
      mit der IP 192.168.6.200 beantwortet. Somit kann man externe Domains
      auf andere IPs umleiten.}


     \config{DNS\_BOGUS\_PRIV}{DNS\_BOGUS\_PRIV}{DNSBOGUSPRIV}

     {Setzt mann diese Variable auf `yes` werden reverse-lookups für IP-Adressen
      nach RFC1918 (Private Address Bereiche) nicht vom dnsmasq an andere DNS-Server
      weitergeleitet, sonder vom dnsmasq beantwortet.}

     \config{DNS\_FILTERWIN2K}{DNS\_FILTERWIN2K}{DNSFILTERWIN2K}

     {setzt man diese Variable auf 'yes' werden alle Windows-Spezifischen
     Namensanfragen gefiltert sowie alle SRV requests gefiltert/geblockt.}

    \configlabel{HOST\_x\_NAME}{HOSTxNAME}
    \configlabel{HOST\_x\_IP}{HOSTxIP}
    \configlabel{HOST\_x\_ALIAS\_N}{HOSTxALIASN}
    \configlabel{HOST\_x\_ALIAS\_x}{HOSTxALIASx}
    \configlabel{HOST\_x\_MAC}{HOSTxMAC}
    \config{HOSTS\_N  HOST\_x\_\{attribute\}}{HOSTSN}{HOSTSN}

    {Es sollten alle Rechner im LAN beschrieben werden - mit
      IP-Adresse, Namen, Aliasnamen und evtl. Mac-Adressen für die
      dhcpd-Konfiguration . Dazu setzt man zunächst die Anzahl der
      Rechner (incl. fli4l-Router) mit der Variablen \var{HOSTS\_\-N}.

      Anschließend werden mit den Attributen die Eigenschaften des
      Hostes definiert. Dabei sind einige Attribute Pflicht, wie z.B.
      IP-Adresse und Name, die anderen optional, d.h. man kann, aber
      man muß sie nicht spezifizieren.

      \begin{description}
      \item[NAME]         -- Name des n-ten Hostes
      \item[IP]           -- IP-Adresse des n-ten Hostes
      \item[ALIAS\_N]     -- Anzahl der Alias-Namen des n-ten Hostes
      \item[ALIAS\_m]     -- m-ter Alias-Name für den n-ten Host
      \item[MAC]          -- Mac Adresse des n-ten Hostes
      \end{description}



      In der Beispiel-Datei sind 4 Rechner konfiguriert - nämlich die
          PCs ``fli4l'', ``client2'', ``client3'' und ``client4''.
          ``fli4l'' ist der fli4l-Router selbst (identisch mit HOSTNAME,
          s.o.). Alternativ kann für Name auch der Wert ``HOSTNAME''
          eingesetzt werden, Dieser wird automatisch gegen den Wert der
          bei \var{HOSTNAME} gesetzt wurde ersetzt.
          Es ist sinnvoll, Rechner auch dann hier einzutragen,
          wenn sie selbst den Router nicht zum Übergang in ein anderes
          Netz verwenden dürfen (s. \jump{FORWARDHOSTN}{FORWARD\_HOST\_N}),
          damit diese auch von anderen Rechnern im LAN über den Namen
          ansprechbar sind.
          Statt der Eingabe eine IP-Adresse ist es auch möglich einen
          Aliasbezug zu einer IP die für ein Interface konfguriert ist
          anzugeben: IP\_NET\_1\_IPADDR wird durch die IP von der ersten
          Netzwerkkonfig \var{IP\_NET\_1} ersetzt
          Der Eintrag für den Router selbst sieht dann z.B. so aus (er hat
          keine Alias-Namen und braucht auch keine Mac-Adresse, da er nicht
          vom dhcpd konfiguriert wird):

\begin{example}
\begin{verbatim}
         HOST_1_NAME='fli4l'                 # 1st host: ip and name
         HOST_1_IP='192.168.6.1'
\end{verbatim}
\end{example}

      Hier nochmal ein alternatives Beispiel:

\begin{example}
\begin{verbatim}
         HOST_1_NAME='HOSTNAME'
         HOST_1_IP='IP_NET_1_IPADDR'
\end{verbatim}
\end{example}


      Aliasnamen müssen mit kompletter Domain angegeben werden.

      Die MAC-Adresse ist optional und ist nur dann relevant, wenn
      fli4l zusätzlich als DHCP-Server eingesetzt wird. Dies wird in
      der Beschreibung zum optionalen Programmpaket ``\var{OPT\_\-DHCP}''
      erklärt, siehe unten. Ohne Einsatz als DHCP-Server sind
      lediglich die IP-Adresse, der Name des Rechners und eventuell
      Aliasnamen einzusetzen.  Die MAC-Adresse ist eine 48-Bit-Adresse
      und besteht aus 6 Hex-Werten, welche durch einen Doppelpunkt
      voneinander getrennt werden, z.B.

\begin{example}
\begin{verbatim}
        HOST_2_MAC='de:ad:af:fe:07:19'
\end{verbatim}
\end{example}
      }


  \end{description}

  \section{Spezielle DNS-Server}

  \begin{description}

    \configlabel{DNS\_SPECIAL\_x}{DNSSPECIALx}
    \config{DNS\_SPECIAL\_N  DNS\_SPECIAL\_x}{DNS\_SPECIAL\_N}{DNSSPECIALN}

    { Es gibt besondere Situationen, wo die Angabe eines oder mehrerer
      DNS-Server sinnvoll ist, z.B. bei Einsatz von fli4l im Intranet
      ohne Internet-Anschluss oder einem Mix von diesen (Intranet mit
      eigenem DNS--Server und zusätzlich Internet-Anschluss).

      Stellen wir uns folgendes Szenario vor:

      \begin{itemize}
      \item Circuit 1: Einwahl in das Internet
      \item Circuit 2: Einwahl in das Firmen-Netz 192.168.1.0 (firma.de)
      \end{itemize}


      Dann wird man \var{ISDN\_\-CIRC\_\-1\_\-ROUTE} auf `0.0.0.0' und
      \var{ISDN\_\-CIRC\_\-2\_\-ROUTE} auf `192.168.1.0' setzen. Bei Zugriff auf
      Rechner mit IP-Adresse 192.168.1.x wird fli4l dann den Circuit
      2, sonst den Circuit 1 benutzen.  Wenn das Firmen-Netz aber
      nicht öffentlich ist, wird in diesem vermutlich ein eigener
      DNS-Server betrieben. Nehmen wir an, die Adresse dieses
      DNS-Servers wäre 192.168.1.12 und der Domain-Name wäre
      ``firma.de''.

      In diesem Fall gibt man an:

\begin{example}
\begin{verbatim}
        DNS_SPECIAL_N='1'
        DNS_SPECIAL_1='firma.de 192.168.1.12'
\end{verbatim}
\end{example}

      Dann werden bei DNS-Queries von xx.firma.de der firmeninterne
      DNS-Server, sonst die DNS-Server im Internet verwendet.


      Ein anderer Fall:
      \begin{itemize}
      \item Circuit 1: Internet
      \item Circuit 2: Firmen-Netz 192.168.1.0 *mit* Internet-Anschluss
      \end{itemize}

      Hier hat man also die Möglichkeit, auf 2 Wegen in das Internet
      zu gelangen. Möchte man Geschäftliches und Privates trennen,
      bietet sich dann folgendes an:

\begin{example}
\begin{verbatim}
        ISDN_CIRC_1_ROUTE='0.0.0.0'
        ISDN_CIRC_2_ROUTE='0.0.0.0'
\end{verbatim}
\end{example}

      Man legt also auf beide Circuits eine Default-Route und schaltet
      dann die Route mit dem imond-Client um - je nach Wunsch. Auch in
      diesem Fall sollte man \var{DNS\_SPECIAL\_\-N} und \var{DNS\_SPECIAL\_\-N} wie oben beschrieben
      einstellen.}

  \end{description}

  \section{dns-dhcp-Server-Konfiguration}

  \begin{description}

    \config{OPT\_DNSDHCP}{OPT\_DNSDHCP}{OPTDNSDHCP}

    Mit {\var{OPT\_DNSDHCP} kann man einstellen, ob der im DNS-Server integrierte
    DHCP-Server aktiviert wird.}

    \config{DNSDHCP\_AUTORITATIVE}{DNSDHCP\_AUTORITATIVE}{DNSDHCPAUTORITATIVE}
    (Optional)
    Diese Option setzt den DHCP-Server \glqq{}authoritative\grqq{}. Damit weist er ihm
    unbekannte Leases ab, dies ist z.B. sinnvoll wenn man ein Notebook von 
    einem ins andere Netz umsteckt.
    Diese Option darf nur aktiviert werden, wenn fli4l der einzige DHCP-Server 
    im Netz ist! 

    \config{DNSDHCP\_LS\_TIME\_DYN}{DNSDHCP\_LS\_TIME\_DYN}{DNSDHCPLSTIMEDYN}

    {legt die standard Lease-Time für dynamisch vergebene IP-Adressen fest.}

    \config{DNSDHCP\_MAX\_LS\_TIME\_DYN}{DNSDHCP\_MAX\_LS\_TIME\_DYN}{DNSDHCPMAXLSTIMEDYN}

    {legt die maximale Lease-Time für dynamisch vergebene IP-Adressen fest.}

    \config{DNSDHCP\_LS\_TIME\_FIX}{DNSDHCP\_LS\_TIME\_FIX}{DNSDHCPLSTIMEFIX}

    {legt die standard Lease-Time für statisch zugeordnete IP-Adressen fest.}

    \config{DNSDHCP\_MAX\_LS\_TIME\_FIX}{DNSDHCP\_MAX\_LS\_TIME\_FIX}{DNSDHCPMAXLSTIMEFIX}

    {legt die maximale Lease-Time für statisch zugeordnete IP-Adressen fest.}

    \config{DNSDHCP\_LEASES\_DIR}{DNSDHCP\_LEASES\_DIR}{DNSDHCPLEASESDIR}

    {legt das Verzeichnis für die Leases-Datei fest.}

    \config{DNSDHCP\_WINSSERVER\_1}{DNSDHCP\_WINSSERVER\_1}{DNSDHCPWINSSERVER1}

    {legt die Adresse des ersten WINS-Server fest. Bei installiertem und aktiviertem
     WINS-Server wird die Adresse von WINS-Server des SAMBA-Paketes übernommen.}

    \config{DNSDHCP\_WINSSERVER\_2}{DNSDHCP\_WINSSERVER\_2}{DNSDHCPWINSSERVER2}

    {legt die Adresse des zweiten WINS-Server fest. Bei installiertem und aktiviertem
     WINS-Server wird die Adresse von WINS-Server des SAMBA-Paketes übernommen.}


    \config{DNSDHCP\_RANGE\_x\_START}{DNSDHCP\_RANGE\_x\_START}{DNSDHCPRANGExSTART}

    {legt die erste zu vergebende IP-Adresse für das in \var{IP\_NET\_x} fest.}

    \config{DNSDHCP\_RANGE\_x\_END}{DNSDHCP\_RANGE\_x\_END}{DNSDHCPRANGExEND}

    {legt die letzte zu vergebende IP-Adresse für das in \var{IP\_NET\_x} fest.}

    \config{DNSDHCP\_RANGE\_x\_DNS\_SERVER}{DNSDHCP\_RANGE\_x\_DNS\_SERVER}{DNSDHCPRANGExDNSSERVER}

    {legt die Adresse des DNS-Server für DHCP-Hosts des Netzes in \var{IP\_NET\_x} fest.
    Diese Variable ist optional. Wird hier nichts eingetragen, oder die Variable einfach weggelassen,
    wird die IP-Adresse, die in \var{IP\_NET\_x} definiert ist, verwendet.
    Es ist auch möglich, diese Variable auf 'none' zu setzen. Dann wird kein DNS-Server übertragen.}

    \config{DNSDHCP\_RANGE\_x\_NTP\_SERVER}{DNSDHCP\_RANGE\_x\_NTP\_SERVER}{DNSDHCPRANGExNTPSERVER}

    {legt die Adresse des NTP-Server für DHCP-Hosts des Netzes in \var{IP\_NET\_x} fest.
    Diese Variable ist optional. Wird hier nichts eingetragen, oder die Variable einfach weggelassen,
    wird die IP-Adresse, die in \var{IP\_NET\_x} definiert ist, verwendet.
    Es ist auch möglich, diese Variable auf 'none' zu setzen. Dann wird kein NTP-Server übertragen.}

    \config{DNSDHCP\_RANGE\_x\_GATEWAY}{DNSDHCP\_RANGE\_x\_GATEWAY}{DNSDHCPRANGExGATEWAY}

    {legt die Adresse des Gateway für DHCP-Hosts des Netzes in \var{IP\_NET\_x} fest.
    Diese Variable ist optional. Wird hier nichts eingetragen, oder die Variable einfach weggelassen,
    wird die IP-Adresse, die in \var{IP\_NET\_x} definiert ist, verwendet.
    Es ist auch möglich, diese Variable auf 'none' zu setzen. Dann wird kein Gatway übertragen.}

    \config{DNSDHCP\_EXTRA\_RANGE\_N}{DNSDHCP\_EXTRA\_RANGE\_N}{DNSDHCPEXTRARANGEN}

    {legt die Anzahl von DHCP-Bereichen fest, die an nicht lokale Netze vergeben werden. Hierzu
    ist am Gateway zum entsprechenden Netz ein DHCP-Relay zu installieren.}

    \config{DNSDHCP\_EXTRA\_RANGE\_x\_START}{DNSDHCP\_EXTRA\_RANGE\_x\_START}{DNSDHCPEXTRARANGExSTART}

    {erste zu vergebende IP-Adresse.}

    \config{DNSDHCP\_EXTRA\_RANGE\_x\_END}{DNSDHCP\_EXTRA\_RANGE\_x\_END}{DNSDHCPEXTRARANGExEND}

    {letzte zu vergebende IP-Adresse.}

    \config{DNSDHCP\_EXTRA\_RANGE\_x\_NETMASK}{DNSDHCP\_EXTRA\_RANGE\_x\_NETMASK}{DNSDHCPEXTRARANGExNETMASK}

    {Netzwerkmaske für diesen Bereich.}

    \config{DNSDHCP\_EXTRA\_RANGE\_x\_DNS\_SERVER}{DNSDHCP\_EXTRA\_RANGE\_x\_DNS\_SERVER}{DNSDHCPEXTRARANGExDNSSERVER}

    {Adresse des DNS-Servers für diesen Bereich.}

    \config{DNSDHCP\_EXTRA\_RANGE\_x\_NTP\_SERVER}{DNSDHCP\_EXTRA\_RANGE\_x\_NTP\_SERVER}{DNSDHCPEXTRARANGExNTPSERVER}

    {Adresse des NTP-Servers für diesen Bereich.}

    \config{DNSDHCP\_EXTRA\_RANGE\_x\_GATEWAY}{DNSDHCP\_EXTRA\_RANGE\_x\_GATEWAY}{DNSDHCPEXTRARANGExGATEWAY}

    {Adresse des Default-Gateway für diesen Bereich.}

    \config{DNSDHCP\_EXTRA\_RANGE\_x\_DEVICE}{DNSDHCP\_EXTRA\_RANGE\_x\_DEVICE}{DNSDHCPEXTRARANGExDEVICE}

    {Netzwerkinterface über den dieser Bereich erreicht wird.}

    \config{DNSDHCP\_DENY\_MAC\_N}{DNSDHCP\_DENY\_MAC\_N}{DNSDHCPDENYMACN}

    {Anzahl der MAC-Adressen von Host, dennen der Zugriff auf DHCP-Adressen verweigert wird.}

    \config{DNSDHCP\_DENY\_MAC\_x}{DNSDHCP\_DENY\_MAC\_x}{DNSDHCPDENYMACx}

    {MAC-Adresse des Hosts, dem der Zugriff auf DHCP-Adressen verweigert wird.}

  \end{description}

  \section{imond-Konfiguration}

  \begin{description}

    \config{START\_IMOND}{START\_IMOND}{STARTIMOND}

    {Mit \var{START\_\-IMOND} kann man einstellen, ob der imond-Server
      aktiviert werden soll. imond übernimmt dabei das
      Monitoring/Controlling und Least-Cost-Routing des fli4l-Routers.
      Der Beschreibung von imond ist deshalb ein extra Kapitel
      gewidmet (s.u.).

      Wichtig: Die LC-Routing-Features von fli4l können nur mit imond
      genutzt werden. Ein zeitabhängiges Umschalten von Verbindungen
      ist ohne imond nicht möglich!

      Für ISDN- und DSL-Routing ist imond ab Version 1.5 zwingend
      erforderlich.  In diesem Fall ist \var{START\_\-IMOND}='yes'
      einzustellen.

      Wird fli4l lediglich als Router zwischen 2 Netzwerken
      eingesetzt, sollte \var{START\_\-IMOND}='no' eingestellt werden.

      Standard-Einstellung: \var{START\_\-IMOND}='no'}

    \config{IMOND\_USE\_ORIG}{IMOND\_USE\_ORIG}{IMONDUSEORIG}
    Wählt zwischen normalem und experimentellem imond. Nur für
    Entwickler gedacht, sollte auf 'yes' gelassen werden.

    \config{IMOND\_PORT}{IMOND\_PORT}{IMONDPORT}

    {TCP/IP-Port, auf dem imond auf Verbindungen horcht.  Der
      Standard-Wert `5000' sollte nur in Ausnahmefällen geändert
      werden.}


    \config{IMOND\_PASS}{IMOND\_PASS}{IMONDPASS}

    {Hier kann ein spezielles User-Password für imond gesetzt werden.
      Meldet sich ein Client auf Port 5000 an, erwartet imond (und
      damit auch seine Clients) die Eingabe dieses Passworts, bevor er
      irgendeinen Befehl korrekt beantwortet. Ausnahme: Befehle
      ``quit'', ``help'' und ``pass''.  Ist \var{IMOND\_\-PASS} leer, wird
      kein Password benötigt.

      Ob der Client im User-Modus bestimmte Steuerbefehle, wie Dial,
      Hangup, Reboot, Umschalten der Default-Route bereits ausführen
      kann oder dafür die Eingabe des Admin-Passwords zwingend
      notwendig ist, wird über die Variablen
      \begin{itemize}
      \item \jump{IMONDENABLE}{IMOND\_ENABLE},
      \item \jump{IMONDDIAL}{IMOND\_DIAL},
      \item \jump{IMONDROUTE}{IMOND\_ROUTE} und
      \item \jump{IMONDREBOOT}{IMOND\_REBOOT}
      \end{itemize}

      eingestellt, siehe unten.

      Standard-Einstellung: \var{IMOND\_\-PASS}=''}


    \config{IMOND\_ADMIN\_PASS}{IMOND\_ADMIN\_PASS}{IMONDADMINPASS}

    { Mit Hilfe der Admin-Passwords erhält der Client alle Rechte und
      kann so sämtliche Steuerfunktionen des imond-Servers nutzen - und
      zwar unabhängig von den Variablen \var{IMOND\_\-ENABLE}, \var{IMOND\_\-DIAL} usw.
      Lässt man \var{IMOND\_\-ADMIN\_\-PASS} leer, so reicht die Eingabe des
      User-Passwords, um sämtliche Rechte zu erhalten!

      Standard-Einstellung: \var{IMOND\_ADMIN\_\-PASS}=''
    }


    \config{IMOND\_LED}{IMOND\_LED}{IMONDLED}

    {imond kann den Online/Offline-Status nun über eine LED anzeigen.
      Diese wird folgendermaßen an einen COM-Port angeschlossen:

      Verbindung 25-polig:

\begin{example}
\begin{verbatim}
        20 DTR  -------- 1kOhm ----- >| ---------- 7 GND
\end{verbatim}
\end{example}


      Verbindung  9-polig:
\begin{example}
\begin{verbatim}
         4 DTR  -------- 1kOhm ----- >| ---------- 5 GND
\end{verbatim}
\end{example}

      Ist eine ISDN- oder DSL-Verbindung aufgebaut, leuchtet die LED.
      Ansonsten ist sie ausgeschaltet. Sollte es genau umgekehrt sein,
      ist die Leuchtdiode umzupolen. Sollte die LED zu schwach
      leuchten, kann der Vorwiderstand bis auf 470 Ohm reduziert
      werden.

      Es ist auch möglich, 2 verschiedenfarbige LEDs anzuschließen.
      Dann ist die zweite LED ebenso über einen Vorwiderstand zwischen
      DTR und GND anzuschließen, jedoch genau umgekehrt. Dann leuchtet
      je nach Zustand die eine oder die andere LED. Oder man verwendet
      direkt eine DUO-LED (zweifarbig, 3 Anschlussbeinchen).

      Im Moment verhält sich der RTS-Anschluß der seriellen
      Schnittstelle genauso wie DTR. Hier könnte also noch eine
      weitere LED angechlossen werden, die den Online/Offline-Zustand
      anzeigt. Das könnte sich jedoch in einer zukünftigen
      fli4l-Version ändern.

      Als Wert von \var{IMOND\_\-LED} muss ein COM-Port angegeben werden, also
      `com1', `com2', `com3' oder `com4'. Ist keine LED angeschlossen,
      sollte die Variable leer gelassen werden.}


    \config{IMOND\_BEEP}{IMOND\_BEEP}{IMONDBEEP}

    {Mit \var{IMOND\_\-BEEP}='yes' gibt imond einen Zweiklang-Ton über den
      PC-Lautsprecher aus, wenn der Zustand von Offline nach Online
      wechselt und umgekehrt. Im ersten Fall wird zuerst ein tiefer,
      dann ein hoher Ton ausgegeben. Beim Wechsel in den
      Offline-Status zurück wird zuerst der höhere, dann der tiefere
      Ton ausgegeben.}


    \config{IMOND\_LOG}{IMOND\_LOG}{IMONDLOG}

    {Wird \var{IMOND\_\-LOG}='yes' eingestellt, werden Verbindungen in der
      Datei /var/log/imond.log protokolliert. Diese Datei kann z.B.
      für Statistikzwecke per scp auf einen Rechner im LAN kopiert
      werden. Für den scp-Zugriff ist aber dann noch das Paket
      sshd zu installieren und so zu konfigurieren, daß es auch scp zur
      Verfügung stellt.

      Das Format der Logdateieinträge ist in Tabelle \ref{tab:imondlog}
      beschrieben.
      \begin{table}[htbp]
        \begin{tabular}[h!]{|l|p{10cm}|}
          \hline
          Eintrag & Bedeutung \\
          \hline \hline
          Circuit & der Name des Circuits, für den der Eintrag erzeugt
          wurde \\
          Startzeit & Datum und Uhrzeit der Einwahl dieses Circuits \\
          Stopzeit & Datum und Uhrzeit des Auflegens dieses Circuits \\
          Online-Zeit & die Zeit, die dieser Circuit online war \\
          Abgerechnete Zeit & die Zeit, die der Provider abrechnen wird
          (hängt vom Takt ab) \\
          Kosten & die Kosten, die der Provider für die Zeit in Rechnung
          stellt \\
          Bandbreite & die genutzte Bandbreite getrennt nach in und out
          (in zuerst), dargestellt als zwei vorzeichenlose
          Integerzahlen, für die gilt: Bandbreite = $4GByte*<erste
          Zahl>+<zweite Zahl>$ \\
          Device & das Gerät, über das Kommuniziert wurde \\
          Abrechnungstakt & der Takt, das vom Provider zur
          Abrechnung herangezogen wird (Daten der Circuit-Konfiguration)\\
          Taktgebühren & die Gebühren, die pro Takt fällig werden
          (Daten der Circuit-Konfiguration)\\
          \hline
        \end{tabular}
        \caption{Fileformat des Imond-Logfiles}
        \label{tab:imondlog}
      \end{table}

      Die Kosten werden in Euro ausgegeben. Wichtig ist dabei die
      korrekte Definition der entsprechenden Circuit-Variablen
      \jump{ISDNCIRCxTIMES}{ISDN\_CIRC\_x\_TIMES}.

      Standard-Einstellung: \var{IMOND\_\-LOG}='no'}


    \config{IMOND\_LOGDIR}{IMOND\_LOGDIR}{IMONDLOGDIR}

    {Ist das Protokollieren eingeschaltet, kann über \var{IMOND\_\-LOGDIR} ein
      alternatives Verzeichnis statt /var/log angegeben werden, z.B.
      `/boot'. Dann wird die LOG-Datei imond.log auf der Diskette
      angelegt. Dazu muß dann die Diskette auch Read/Write
      ``gemounted'' sein.}


    \configlabel{IMOND\_DIAL}{IMONDDIAL}
    \configlabel{IMOND\_ROUTE}{IMONDROUTE}
    \configlabel{IMOND\_REBOOT}{IMONDREBOOT}
    \configlabel{IMOND\_ENABLE}{IMONDENABLE}
    \config{IMOND\_ENABLE  IMOND\_DIAL  IMOND\_ROUTE  IMOND\_REBOOT}{IMOND\_ENABLE}{IMONDENABLE}

    {Durch diese Variablen werden bestimmte Kommandos, die von
      imonc-Clients zum imond-Server gesendet werden, bereits im
      User-Modus freigeschaltet.

      Hiermit kann man einstellen, ob der imond-Server die
      ISDN-Schnittstelle ein-/ausschalten, wählen/einhängen, neu
      routen und/oder den Rechner booten darf.


      Standard-Einstellungen:

\begin{example}
\begin{verbatim}
        IMOND_ENABLE='yes'
        IMOND_DIAL='yes'
        IMOND_ROUTE='yes'
        IMOND_REBOOT='yes'
\end{verbatim}
\end{example}

      Alle weiteren Features der Client-/Server-Schnittstelle von imond sind in
      einem \jump{IMONDSCHNITTSTELLE}{eigenen Kapitel} beschrieben.}

  \end{description}

  \section{Allgemeine Circuit-Konfiguration}

  \begin{description}

    \config{IP\_DYN\_ADDR}{IP\_DYN\_ADDR}{IPDYNADDR}

    {Wird eine Verbindung mit dynamischer Adressvergabe verwendet, ist
      \var{IP\_\-DYN\_\-ADDR} auf `yes' zu stellen, ansonsten auf `no'. Die
      meisten Internet-Provider verwenden eine dynamische
      Adressvergabe.

      Standard-Einstellung: \var{IP\_\-DYN\_\-ADDR}='yes'}


    \config{DIALMODE}{DIALMODE}{DIALMODE}

    {Der Standard-Wählmodus von fli4l ist `auto', d.h. es wird
      automatisch gewählt, wenn eine IP-Adresse außerhalb des eigenen
      Netzes angesprochen wird. Es ist aber auch möglich, als Dialmode
      `manual' oder `off' anzugeben. In diesem Fall kann man eine
      Wählverbindung nur über den Client imonc auslösen.

      Standard-Einstellung: DIALMODE='auto'}

  \end{description}

  \chapter{Packages}

  Für fli4l sind mittlerweile eine Unmenge von Zusatzpaketen
  verfügbar.  Diese sind nicht im rootfs-Image enthalten, sondern
  werden als zusätzliches Archiv opt\_tar.bz2 auf die Diskette geschrieben
  und beim Booten nachträglich in der Ramdisk installiert. Wie das
  funktioniert, ist in src/README beschrieben.

  Seit der Version 2.0 wird ein neues Modulkonzept benutzt. Neben
  der Basisinstallation (base) gibt es Packages. Diese enthalten ein
  oder mehrere OPT-Pakete, die bei Bedarf zu base hinzuinstalliert
  werden können. Einige dieser Packages sind Bestandteil des
  Basis-Paketes, andere kommen separat. Eine Übersicht über die vom
  Fli4l-Team bereitgestellten Pakete finden Sie auf der Download-Seite
  (\link{http://www.fli4l.de/german/download.php}), die von anderen
  Autoren bereitgestellten Pakete sind in der Opt-Datenbank
  (\link{http://www.fli4l.de/german/extern/opt/}) zu finden.  Im
  folgenden werden die vom Fli4l-Team bereitgestellten Pakete
  beschrieben.

  Nicht alle Pakete wird man zur gleichen Zeit auf die Diskette bekommen.
  Bei einer Standard-fli4l-Konfiguration bleiben ca. 400 kB komprimierter
  Speicherplatz auf der Diskette frei. Diese können dann für weitere Pakete
  eingesetzt werden.

  \section{Programme im Basispaket}

  Im Basispaket befinden sich die folgenden Programme:

  \begin{tabular}{lp{10cm}}
    Name     &       Beschreibung \\
    \hline    \hline
    \var{OPT\_SYSLOGD} &    \jump{OPTSYSLOGD}{Programm zum Protokollen von Systemfehlermeldungen} \\
    \var{OPT\_KLOGD}   &    \jump{OPTKLOGD}{Programm zum Protokollen von Kernelfehlermeldungen} \\
    \var{OPT\_Y2K}     &    \jump{OPTY2K}{Datumskorrektur bei nicht Y2K-festen Rechnern} \\
    \var{OPT\_PNP}     &    \jump{OPTPNP}{Installation von isapnp tools} \\
  \end{tabular}


  \marklabel{OPTSYSLOGD}{\subsection{OPT\_SYSLOGD - Programm zum Protokollen von Systemfehlermeldungen}}

  Viele Programme verwenden die Syslog-Schnittstelle, um
  Meldungen auszugeben. Damit diese auch auf der Console
  sichtbar werden, muss in diesem Falle der Daemon syslogd gestartet
  werden.

  Sind Debug-Meldungen gewünscht, stellt man \var{OPT\_\-SYSLOGD} auf `yes',
  ansonsten auf `no'.

  Siehe auch \jump{ISDNCIRCxDEBUG}{ISDN\_CIRC\_x\_DEBUG} und
  \jump{PPPOEDEBUG}{PPPOE\_DEBUG}.


  Standard-Einstellung: \var{OPT\_\-SYSLOGD}='no'


  \begin{description}
    \configlabel{SYSLOGD\_DEST\_x}{SYSLOGDDESTx}
    \config{SYSLOGD\_DEST\_N SYSLOGD\_DEST\_x}{SYSLOGD\_DEST\_N}{SYSLOGDDESTN}

  {Mit \var{SYSLOGD\_\-DEST\_\-x} gibt man Ziele an, wohin System-Meldungen, die
  von syslogd entgegengenommen werden, ausgegeben werden. Im
  Normalfall ist dies die Console von fli4l, also

\begin{example}
\begin{verbatim}
        SYSLOGD_DEST_1='*.* /dev/console'
\end{verbatim}
\end{example}

  Möchte man eine Datei als Protokoll verwenden, ist z.B. einzutragen:

\begin{example}
\begin{verbatim}
        SYSLOGD_DEST_1='*.* /var/log/messages'
\end{verbatim}
\end{example}

  Der Syslogdaemon setzt in regelmässigen Zeitabstand einen --- MARK -- Eintrag
  falls es nichts zu protokollieren gibt. Damit soll ein eventueller Ausfall
  des Syslogd im Log nachvollziehbar sein.
  Allerdings kann man darauf verzichten wenn das System stabil läuft oder
  das Logfile übersichtlich bleiben soll.

\begin{example}
\begin{verbatim}
	SYSLOGD_DEST_1='*.*;mark.!info /var/log/messages'
\end{verbatim}
\end{example}

  Ist ein sog. Loghost im Netz vorhanden, können die Meldungen auch
  auf diesen Rechner umgeleitet werden - unter Angabe der IP-Adresse.

  Beispiel:
\begin{example}
\begin{verbatim}
        SYSLOGD_DEST_1='*.* @192.168.4.1'
\end{verbatim}
\end{example}
  Das @-Zeichen ist dann der IP-Adresse voranzustellen.

  Sollen die Systemmeldungen an mehrere Ziele ``ausgeliefert'' werden,
  muss man \var{SYSLOGD\_\-DEST\_\-N} (Anzahl der Ziele) entsprechend erhöhen
  und die Variablen \var{SYSLOG\_\-DEST\_\-1}, \var{SYSLOG\_\-DEST\_\-2} usw. füllen.

  Der Parameter `*.*' bedeutet, dass sämtliche Meldungen protokolliert
  werden. Man kann jedoch die Meldungen für bestimmte ``Destinations''
  über sog. ``Priorities'' einschränken. In diesem Fall ersetzt man
  das Sternchen (*) hinter dem Punkt (.) durch eines der folgenden
  Schlüsselwörter:
  \begin{itemize}
  \item debug
  \item info
  \item notice
  \item warning (veraltet: warn)
  \item err (veraltet: error)
  \item crit
  \item alert
  \item emerg (veraltet: panic)
  \end{itemize}

  Die Reihenfolge in der Liste spiegelt dabei das ``Gewicht'' der
  Meldungen wider. Die Schlüsselwörter error, warn und panic sind
  veraltet und sollten nicht mehr verwendet werden.

  Vor dem Punkt kann eine sog. ``Facility'' statt des Sternchens (*)
  eingetragen werden. Eine Erklärung würde aber hier zu weit gehen.
  Der geneigte Leser kann hierfür eine Suchmaschine seiner Wahl
  bemühen. Eine Übesicht über mögliche Facilities
  finden sich auf den Manpages der syslog.conf:
  \link{http://www.die.net/doc/linux/man/man5/syslog.conf.5.html}
  Normalerweise ist das Sternchen aber vollkommen ausreichend.
  
  Beispiel:
  \begin{example}
\begin{verbatim}
          SYSLOGD_DEST_1='*.warning @192.168.4.1'
  \end{verbatim}
\end{example}

  Nicht nur Unix-/Linux-Rechner können als Loghost dienen, sondern
  auch Windows-Rechner. Auf \link{http://www.fli4l.de} findet man im Ordner
  ``Links'' Verweise auf entsprechende Software. Die Verwendung eines
  Loghosts wird dringend empfohlen, wenn eine detaillierte
  Protokollierung gewünscht ist. Auch hilft die Protokollierung bei
  der Fehlersuche.  Mittlerweile ``versteht'' auch imonc als
  Windows-Client das Syslog-Protokoll und kann die Meldungen in einem
  Fenster ausgeben.}

  \end{description}

  Leider lassen sich die Boot-Meldungen von fli4l nicht über syslogd
  umlenken. Jedoch kann man fli4l auch so konfigurieren, daß die
  Console ein serielles Terminal (bzw. Terminalemulation) ist. Wie das
  geht, steht in Kap. 3.3 dieser Doku (\jump{SERCONSOLE}{OPT\_Serial
  Console}).


  \marklabel{OPTKLOGD}{\subsection{OPT\_KLOGD - Kernel-Message-Logger}}

  Viele der auftretenden Fehler - z.B. fehlgeschlagene Einwahl -
  werden vom Linux-Kernel direkt auf die Console geschrieben. Mit
  \var{OPT\_\-KLOGD}='yes' werden diese Meldungen an den syslogd umgelenkt,
  welcher diese dann entweder in Dateien protokollieren oder an einen
  Loghost weiterleiten kann, s.o. Dann hat man auf der fli4l-Console
  (fast) Ruhe.

  Empfehlung: Wenn \var{OPT\_\-SYSLOGD}='yes' eingestellt wird, sollte man auch
  \var{OPT\_\-KLOGD}='yes' setzen.

  Standard-Einstellung: \var{OPT\_\-KLOGD}='no'




  \marklabel{OPTY2K}{\subsection{OPT\_Y2K - Datumskorrektur bei nicht
      Y2K-festen Rechnern}}

  Meist werden fli4l-Router aus alten Hardware-Teilen zusammengesetzt.
  Dabei kann das BIOS des Mainboards nicht Y2K-fest sein. Das ist z.B.
  bei meinem 486er der Fall: Wenn ich den 27.05.2000 im BIOS
  einstelle, steht beim nächsten Booten immer der 27.05.2094 drin!
  Linux zeigt dann übrigens 27.05.1994 :-)

  Eigentlich kann das eingestellte Datum für den fli4l-Router egal
  sein und sollte deshalb keine Rolle spielen. Wird fli4l jedoch als
  Least-Cost-Router eingesetzt, kann dies jedoch sehr wohl eine Rolle
  spielen.

  Grund: Der 27.05.1994 war ein Freitag, der 27.05.2000 jedoch ein
  Samstag. Und am Wochenende gibt's günstigere Tarife bzw. günstigere
  Provider \ldots

  Für fli4l ist dies folgendermaßen gelöst:

  Ich habe das BIOS-Datum am 27.05.2000 auf den 28.05.1994 gestellt.
  Das war ebenso ein Samstag. Damit war das Problem eigentlich gelöst.

  Was mich aber störte, war das falsche Datum, denn fli4l verwendet
  nicht nur den Wochentag und die momentane Uhrzeit für das
  LC-Routing, sondern berücksichtigt auch die Feiertage.

  Y2K\_DAYS - N Tage auf Systemdatum addieren

  Da mein gesetztes Datum genau 2191 Tage zum tatsächlichen Datum
  differiert, werden bei Angabe von

\begin{example}
\begin{verbatim}
        Y2K_DAYS='2191'
\end{verbatim}
\end{example}

  auf das BIOS-Datum 2191 Tage addiert und dieses dann als Linux-Datum
  gesetzt. Das BIOS-Datum bleibt davon jedoch unberührt, sonst würde
  beim nächsten Booten das Ding wieder auf 2094 (bzw. 1994) stehen ;-)

  Es gibt noch eine Alternative:

  Mit dem Zugriff auf einen Time-Server kann sich fli4l die aktuelle
  Datum/Uhrzeit aus dem Internet holen. Dafür steht ein optionales Paket
  (OPT\_CHRONY) zur verfügung. Beide Einstellungen lassen
  sich kombinieren. Das ist sinnvoll, um mit Y2K\_DAYS zunächst das
  Datum schon einmal zu korrigieren und anschließend über den
  Time-Server die genaue Uhrzeit einzustellen.

  Wer mit Y2K keine Probleme hat: Variable \var{OPT\_\-Y2K}='no' setzen und
  einfach nicht mehr darüber nachdenken \ldots


  \marklabel{OPTPNP}{\subsection{OPT\_PNP - Installation von isapnp tools}}

  Teilweise müssen ISDN-PnP-Karten (ISA) über das Tool isapnp
  konfiguriert werden. Dies betrifft insb. die Karten mit \var{ISDN\_\-TYPE}
  7, 12, 19, 24, 27 und 28 - aber nur, wenn es sich auch wirklich um
  ISA-PnP-Karten handelt.

  Zur Konfiguration ist die Erstellung einer Konfigurations-Datei
  etc/isapnp.conf notwendig.

  Hier eine Kurzanleitung zur Erstellung:

  \begin{itemize}
  \item In config/base.txt die Variable \var{OPT\_\-PNP}='yes' und
    \var{MOUNT\_\-BOOT}='rw' setzen
  \item fli4l booten - die PnP-Karte wird wahrscheinlich nicht erkannt
  \item Auf fli4l-Console eingeben:
\begin{example}
\begin{verbatim}
        pnpdump -c >/boot/isapnp.conf
        umount /boot
\end{verbatim}
\end{example}
    Damit ist die Konfiguration auf der Diskette gespeichert.
  \end{itemize}
  Weiter auf PC (Unix/Linux/Windows):
  \begin{itemize}
  \item Die Datei isapnp.conf von Diskette nach opt/etc/isapnp.conf
    kopieren
  \item isapnp.conf mit Editor öffnen
  \item die entsprechenden Daten (IRQ/IO) in die config/isdn.txt
    übernehmen
  \item Neue Boot-Diskette erzeugen
  \end{itemize}
  \achtung {Die automatisch generierte Datei ist im UNIX-Format
    gespeichert und enthält keine CRs. Startet man unter Windows den
    Notepad-Editor, zeigt dieser alle Zeilen in einer einzigen Zeile
    an. Der DOS-Editor ``edit'' kann jedoch mit Unix-Dateien umgehen.
    Er speichert sie dann als DOS-Datei (mit CRs) ab.}

  Abhilfe:
  \begin{itemize}
  \item DOS-Box starten
  \item In das Verzeichnis opt/etc wechseln
  \item Eingeben:
    edit isapnp.conf
  \item Datei bearbeiten und abspeichern
  \end{itemize}
  Anschließend kann die Datei auch wieder mit Notepad bearbeitet
  werden.

  Man kann auch unter Windows einfach den Wordpad-Editor verwenden.

  Die zusätzlich generierten CRs werden beim Booten von fli4l wieder
  herausgefiltert. Sie stören also nicht.


  Zunächst sollte man versuchen, ohne \var{OPT\_\-PNP} auszukommen. Wird die
  Karte nicht erkannt, sollte wie oben beschrieben vorgegangen werden.

  Bei einem Update auf eine neuere fli4l-Version kann die früher
  erstellte Datei isapnp.conf weiter verwendet werden.

  Standard-Einstellung: \var{OPT\_\-PNP}='no'
