Linux ISDN HOWTO <author>Klaus Franken (<tt/i4l@klaus.franken.de/) <date>v1.2-3, 2. September 1998 <abstract> Einrichtung eines Internet-Zugang-Rechners mit ISDN4Linux - eine praxisorientierte Beschreibung mit Übungen. </abstract>  <toc>  <sect>Einleitung <label id="DE-ISDN-HOWTO-Einleitung"> <nidx>ISDN</nidx> Das Tutorium wendet sich an ISDN-Einsteiger und solche mit ersten Erfahrungen, die sich jetzt auch für die weitere Konfiguration des Gesamt-Systems (z.B. Mailsystem, Firewalls, etc.) interessieren. Das Tutorium wird praxisorientiert durchgeführt. Es werden nicht alle Grundlagen und Features im Detail besprochen, sondern der Teilnehmer hat nach dem Tutorium einen entsprechend konfigurierten Rechner bzw. die Grundlagen dazu. Im Tutorium wird die Distribution <htmlurl name="SuSE Linux 5.2" url="http://www.suse.de"> benutzt. Andere Distributionen wie z.B. Debian oder RedHat können selbstverständlich auch benutzt werden. Bei Bedarf müssen die notwendigen Skripte installiert werden. Informationen hierzu befinden sich im Abschnitt <ref id="DE-ISDN-HOWTO-installation" name="Installation">. In der SuSE Distribution sind sowohl die notwendigen Tools als auch Konfigurationsskripte enthalten, die eine abstraktere Konfiguration der ISDN-Verbindungen erlauben. Im Tutorium wird jeweils der <em/einfache/ Weg über die Skripte und dann zur Referenz der manuelle Weg beschrieben. <sect1>Voraussetzungen <label id="DE-ISDN-HOWTO-Voraussetzungen"> Der Teilnehmer sollte über Linux-Grundkenntnisse verfügen. Auf dem Rechner sollte die Basis-Installation schon erfolgreich durchgeführt sein. Weiterhin sollte eine unterstützte ISDN-Karte eingebaut sein. Zu empfehlen ist z.B. eine AVM-Fritz classic oder eine ELSA QS1000. Siehe <tscreen><htmlurl url="http://www.suse.de/Support/sdb/isdn.html" name="http://www.suse.de/Support/sdb/isdn.html"></tscreen> für eine Liste der unterstützten Karten. <sect1>Was soll erreicht werden? <label id="DE-ISDN-HOWTO-Was soll erreicht werden?"> Folgende Aufgabe wird gelöst: Ein Linux-Rechner mit ISDN-Karte soll Internet-Zugangs-Rechner (IZG) werden. Der Rechner wählt sich bei einem Verbindungswunsch automatisch beim Internet-Service-Provider (ISP) ein und stellt die Netzverbindung transparent her. Die Benutzer dieser Arbeitsstation haben nun vollständigen Zugriff auf das Internet und können z.B. WWW- und FTP-Dienste nutzen. Das Mailsystem wird so eingerichtet, daß beim Verbindungsaufbau automatisch die E-Mails ausgetauscht werden. Ein eigenes Kapitel behandelt die Anbindung eines lokalen Netzwerkes mit vollständiger Internet-Nutzung (Masquerading, Mail, WWW, FTP-Nutzung) und der besonderen Probleme, die daraus erwachsen. Da es sich um eine Wählleitung handelt, wird besonderes Augenmerk darauf gerichtet, daß zwar ein voller Internetzugang besteht, aber die Telefonkosten möglichst gering gehalten werden. Um den roten Faden nicht zu verlieren, werden folgende Annahmen gemacht, die für die meisten Privatanwender, aber auch für kleine Firmen, die nur einen <em/privaten/ Internet-Zugang nutzen, zutreffen: <itemize> <item>ISDN-Wählleitung ohne TK-Anlage (Euro-ISDN) <item>Protokoll: syncPPP mit dynamischen IP-Nummern <item>kein Proxy-Zwang <item>E-Mails können über SMTP verschickt und POP3 abgeholt werden </itemize> Diese Voraussetzungen treffen inzwischen auf die meisten Privat-Zugänge wie z.B. T-Online oder Personal-Eunet und viele private Vereine zu. Weiterhin wird auf sicherheitsrelevante Fragen, Probleme mit dynamischen IP-Nummern und den Anschluß eines lokalen Netzwerks an den IZR besprochen. <sect1>Was muß ich lesen, was soll ich lesen? Der Text ist recht lang geworden, da an vielen Stellen auf besondere Probleme eingegangen wird und Tips zum Troubleshooting gegeben werden. Wer an diesen Stellen keine Probleme hat, braucht sich natürlich nicht damit aufzuhalten - es schadet aber auch nicht. Ähnlich verhält es sich mit einigen Grundlagen, z.B. Routing oder dem Konfigurieren spezieller Anwendungen, z.B. Mailaustausch. Der erfahrene Leser wird hier wenig Neues erfahren und kann diese Abschnitte überlesen. Sie wurden aber deswegen hier aufgenommen, weil das Verständnis hierfür unabdingbar ist und genau an diesen Punkten oft die meisten Probleme im Alltag auftauchen.  <sect1>Sprache Der Einfachheit und der besseren Lesbarkeit wegen werde ich Dich, den Leser, im weiteren Verlauf des Textes duzen. <sect1>Keine Gewährleistung Der Text ist nach bestem Wissen und Gewissen geschrieben. Der Autor übernimmt keine Gewährleistung, daß die hier vorgestellten Methoden richtig sind, funktionieren, sicher sind oder tatsächlich keine unnötigen Verbindungen aufgebaut werden. Der Leser soll aber für ein einfaches System in die Lage versetzt werden, genau dies in den Griff zu bekommen :-). <sect1>Feedback Rückmeldungen zu diesem Text sind erwünscht. Sie können per E-Mail an folgende Adresse geschickt werden: <tt><htmlurl url="mailto:i4l@klaus.franken.de" name="i4l@klaus.franken.de"></tt> <sect1>Copyright Dieses Dokument ist urheberrechtlich geschützt. Das Copyright liegt bei Klaus Franken. Das Dokument darf gemäß der GNU <htmlurl name="General Public License" url="DE-GPL.html"> verbreitet werden. Insbesondere bedeutet dieses, daß der Text sowohl über elektronische wie auch physikalische Medien ohne die Zahlung von Lizenzgebühren verbreitet werden darf, solange dieser Copyright-Hinweis nicht entfernt wird. Eine kommerzielle Verbreitung ist erlaubt und ausdrücklich erwünscht. Bei einer Publikation in Papierform ist das Deutsche Linux HOWTO Projekt hierüber zu informieren. <sect>Grundlagen <label id="DE-ISDN-HOWTO-Grundlagen"> <nidx>ISDN!Grundlagen</nidx> Ich kenne mich mit Linux ein wenig aus. Ich kann mich sogar vielleicht schon mit meinem Modem in's Internet einwählen. Jetzt habe ich ISDN - und finde mich überhaupt nicht mehr zurecht. Warum eigentlich? <sect1>ISDN4Linux: Modem oder Netzwerk? <label id="DE-ISDN-HOWTO-ModemNetzwerk"> <nidx>ISDN!Unterschiede zum Modem</nidx> Vergiß alles, was Du über Modems weißt. Bei ISDN ist alles anders: <enum> <item>Es klickt und pfeift nicht. <item>Es blinken keine Lämpchen. <item>Der Verbindungsaufbau geht so schnell, daß man innerhalb von Stunden ein Monatsgehalt loswerden kann. <item>Es macht mehr Spaß. </enum> Die Konzepte unterscheiden sich in der Art der: <enum> <item>Hardwareanbindung <item>Nutzung <item>Kontrollmöglichkeiten <item>Konfiguration </enum> Bei ISDN4Linux wird die ISDN-Karte als Netzwerkkarte mit besonderen Eigenschaften betrachtet. <sect1>Überblick über die Features <nidx>ISDN!Features von Linux</nidx> Die Linux-Implementierung von ISDN bietet folgende Features: <itemize> <item>schnelle ISDN-Verbindungen <item>volle Integration als Netzwerk <item>Client und Server <item>syncPPP <item>Modememulation (AT-Befehlssatz) <item>Dial-On-Demand (DoD) <item>volle Übersicht und Kontrolle <item>Callback <item>Kanalbündelung </itemize> <sect1>Überblick über die fehlenden Features Folgende Features bietet Linux zur Zeit noch nicht: <itemize> <item>serielle Anbindung (z.B. Fax) <item>CAPI-Schnittstelle (z.B. über Netz) <item>einheitliche Umgebung ... <item>PmX-Karten </itemize> <sect1>Überblick über die Tools <descrip> <tag/isdnlog/ <tt/isdnlog/ horcht ständig im Hintergrund auf dem S0-Bus und protokolliert ein- und ausgehende Verbindungen zur späteren Auswertung (inkl. Gebühren) und zur Diagnose. <tag/isdnctrl/ Stellt wichtige I4l-spezifische Parameter wie z.B. die Telefonnummern ein. <tag/HiSax/ Dieses ist der ISDN-Treiber für fast alle passiven ISDN-Karten, der fest oder als Modul ins Kernel eingebunden wird. <tag/hisaxctrl/ Mit diesem Programm wird der HiSax-Treiber kontrolliert. <tag/ipppd/ Dieses ist der PPP-Daemon für ISDN (syncPPP). <tag/messages/ In der Datei <tt>/var/log/messages</tt> oder via Syslog werden die ISDN-Aktionen protokolliert. Dieses kann sehr nützlich bei der Diagnose von Fehlern sein. <tag/ttyI/ Über die Terminal-Devices <tt>/dev/ttyI0</tt> bis <tt>/dev/ttyI64</tt> kann mit <em/normalen/ Terminalprogrammen auf ISDN zugegriffen werden - Achtung: kein analoger Zugriff! <tag/vbox/ Der Anrufbeantworter für ISDN. </descrip> <sect>Hardware-Modul laden <label id="DE-ISDN-HOWTO-Hardware"> <nidx>ISDN!Treiber</nidx> <nidx>Module!isdn</nidx> <nidx>Module!slhc</nidx> Die Treiber für die Hardware werden durch Module bereitgestellt. Man könnte die notwendigen Treiber auch direkt in den Kernel einkompilieren, aber davon ist abzuraten. Für das I4L-Subsystem ist das Modul <tt/isdn/ zuständig, das je nach Kompilierung noch das Modul <tt/slhc/ benötigt. Diese Module sind für den eigentlichen Hardwaretreiber Voraussetzung und müssen vorher geladen sein. Wenn man die Module über das Tool <tt/modprobe/ lädt, braucht man sich darum aber nicht zu kümmern, da dadurch die Abhängigkeiten selbständig geprüft werden. <bf/Merke:/ Benutze nur <tt/modprobe/ zum Laden der Module. Je nach verwendeter Hardware sind unterschiedliche Module notwendig. Für passive ISDN-Karten ist das Modul <tt/HiSax/ notwendig. Für aktive Karten werden herstellerspezifische Module benötigt. <sect1>isdnlog konfigurieren <label id="DE-ISDN-HOWTO-isdnlogConf"> <nidx>ISDN!isdnlog</nidx> Der <tt/isdnlog/ horcht ständig auf dem D-Kanal und liefert uns sowohl zur Diagnose, als auch später zur Auswertung wichtige Daten. Der <tt/isdnlog/ wird kurz nach dem Laden des HiSax-Treibers gestartet; bei aktiven Karten siehe weiter unten. Wir gehen später auf die Funktionen und den Start des <tt/isdnlog/ ein, hier nur kurz die wichtigsten Punkte zur Konfiguration: <descrip> <tag>/etc/isdn/isdn.conf</tag> <nidx>/etc/isdn/isdn.conf</nidx> <nidx>ISDN!/etc/isdn/isdn.conf</nidx> <nidx>ISDN!Areacode</nidx> Es werden einige Daten über die Umgebung mitgeteilt, z.B. den Areacode (Vorwahl), den i4l nicht automatisch ermitteln kann. Passe in dem Beispiel zumindest den Areacode an: <tscreen><verb> # Beispiel für /etc/isdn/isdn.conf # Kopiere diese Datei nach /etc/isdn/isdn.conf und # editiere sie # # Mehr Informationen: # /usr/doc/packages/i4l/isdnlog/README [GLOBAL] COUNTRYPREFIX = + COUNTRYCODE = 49 AREAPREFIX = 0 # Editiere diese Zeile: AREACODE = 911 # Beispiel: #AREACODE = 911 # Nürnberg [VARIABLES] [ISDNLOG] LOGFILE = /var/log/isdn.log ILABEL = %b %e %T %ICall to tei %t from %N2 on %n2 OLABEL = %b %e %T %Itei %t calling %N2 with %n2 REPFMTWWW = "%X %D %17.17H %T %-17.17F %-20.20l SI: %S %9u %U %I %O" REPFMTSHORT = "%X%D %8.8H %T %-14.14F%U%I %O" REPFMT = " %X %D %15.15H %T %-15.15F %7u %U %I %O" </verb></tscreen> <tag>Optionen für isdnlog</tag> <tt/isdnlog/ verträgt eine Menge Optionen, die man entweder als Kommandozeilenparameter, oder über eine Konfigdatei mitgeben kann. Bei SuSE wird die Datei <tt>/etc/isdn/isdnlog.isdnctrl0.options</tt> verwendet (0: erste Karte, 2: zweite Karte, 4: dritte Karte), und beim Start des <tt/isdnlog/ mit dem Parameter <tt/-f/ übergeben. Diese Datei ist kommentiert und enthält die wichtigsten Parameter. Mehr Infos gibt es in der README-Datei zu <tt/isdnlog/, die in dem Quellpaket dabei ist. Bei SuSE ist die Datei unter <tt>/usr/doc/packages/i4l/isdnlog/README</tt> zu finden. Von Hand sollte <tt/isdnlog/ mit mindestens folgenden Optionen gestartet werden: <tscreen><verb> isdnlog -D -l1015 -x4087 -M -n -W80 /dev/isdnctrl0 & </verb></tscreen> <tag>Telefonbuch (optional)</tag> <nidx>ISDN!Telefonbuch</nidx> <tt/isdnlog/ kann den ein- und ausgehenden Nummern automatisch einen Aliasnamen zuweisen, der statt der Telefonnummer angezeigt wird. Diese Daten stehen in: <tt>/etc/isdn/callerid.conf</tt>. Beispiel: <tscreen><verb> [NUMBER] NUMBER = +4991152145922 ALIAS = Eunet-N ZONE = 1 </verb></tscreen> Darüber lassen sich auch weitere Aktionen definieren, z.B. das Starten eines bestimmten Programmes beim Klingeln. </descrip> <sect1>Plug&Play-Karten <label id="DE-ISDN-HOWTO-pnp"> <nidx>Plug&Play-Karten</nidx> <nidx>ISDN!Plug&Play-Karten</nidx> <nidx>isapnp</nidx> <nidx>/etc/isapnp.conf</nidx> PnP-Karten müssen im 2.0er Kernel noch manuell konfiguriert werden. Das ist etwas mühsam, muß aber zum Glück nur einmal gemacht werden. Zum Konfigurieren unter Linux dient das Paket <em/isapnp/, das zwei Programme enthält: <descrip> <tag/pnpdump/ Dieses Programm scannt den ISA-Bus nach Karten und erstellt eine Vorlage für die Konfigurationsdatei. <tag/isapnp/ Mit diesem Tool werden die PnP-Karten entsprechend der Konfigurationsdatei initialisiert. </descrip> Erst nachdem die Karte(n) hiermit konfiguriert wurde(n), kann durch Treiber auf die Hardware zugegriffen werden. PnP-Karten können also nur durch Module, jedoch nicht durch fest in den Kernel einkompilierte Treiber benutzt werden. Zuerst suchen wir nach PnP-Karten, aber Vorsicht: <tt/pnpdump/ kann den Rechner zum Stillstand bringen. Starte das Programm nicht unter X und möglichst nur im Single-User-Mode. Die Ausgabe von <tt/pnpdump/ leiten wir gleich in die Konfigurationsdatei um: <tscreen><verb> pnpdump > /etc/isapnp.conf </verb></tscreen> Hier ein Beispiel für eine Elsa QS3000: <tscreen><verb> # This is free software, see the sources for details. # This software has NO WARRANTY, use at your OWN RISK # # For details of this file format, see isapnp.conf(5) # # For latest information on isapnp and pnpdump see: # http://www.roestock.demon.co.uk/isapnptools/ # # Compiler flags: -DREALTIME -DNEEDSETSCHEDULER # # Trying port address 0203 # Board 1 has serial identifier e5 00 00 00 00 34 01 93 15 # (DEBUG) (READPORT 0x0203) (ISOLATE) (IDENTIFY *) # Card 1: (serial identifier e5 00 00 00 00 34 01 93 15) # ELS0134 Serial No 0 [checksum e5] # Version 1.0, Vendor version 0.0 # ANSI string -->ELSA QuickStep 3000<-- # # Logical device id ELS0134 # # Edit the entries below to uncomment out the configuration required. # Note that only the first value of any range is given, this may be changed if r equired # Don't forget to uncomment the activate (ACT Y) when happy (CONFIGURE ELS0134/0 (LD 0 # Multiple choice time, choose one only ! # Start dependent functions: priority acceptable # Logical device decodes 16 bit IO address lines # Minimum IO base address 0x0160 # Maximum IO base address 0x0360 # IO base alignment 16 bytes # Number of IO addresses required: 16 #(IO 0 (BASE 0x0160)) # IRQ 3, 4, 5, 7, 10, 11, 12 or 15. # High true, edge sensitive interrupt (by default) #(INT 0 (IRQ 3 (MODE +E))) # End dependent functions #(ACT Y) )) # End tag... Checksum 0x00 (OK) # Returns all cards to the "Wait for Key" state (WAITFORKEY) </verb></tscreen> Anhand der ausgegebenen Identifier kann man erkennen, welche Karten erkannt wurden und ob es überhaupt PnP-Karten gibt. Diese Datei wird editiert; die Kommentarzeichen müssen entfernt werden und ggf. passende Werte eingesetzt werden. In den Kommentaren werden gültige Werte angegeben. <tscreen><verb> (IO 0 (BASE 0x0160)) (INT 0 (IRQ 3 (MODE +E))) (ACT Y) </verb></tscreen> Man beachte, daß auch <tt/(ACT Y)/ gesetzt werden muß. Ansonsten passiert gar nichts. Diese Konfiguration kann nun auf die PnP-Karte heruntergeladen werden: <tscreen><verb> isapnp /etc/isapnp.conf Board 1 has Identity e5 00 00 00 00 34 01 93 15: ELS0134 Serial No 0 [checksum e5] </verb></tscreen> Die Ausgabe ist leider nicht sehr aufschlußreich, aber man sollte zumindest den Identifier der Karte erkennen. Bei SuSE wird das <tt/isapnp/ Kommando automatisch in den Init-Skripten ausgeführt. Ansonsten muß man selbst für diesen Aufruf sorgen. <sect1>HiSax-Treiber laden <label id="DE-ISDN-HOWTO-HiSax"> <nidx>ISDN!Treiber!HiSax</nidx> Dem HiSax-Treiber wird durch Parameter beim Laden mitgeteilt, nach welcher Karte bzw. welchen Karten an welchen Adressen zu suchen ist. <sect2> Laden mit YaST Bei SuSE kann die Konfiguration der ISDN-Hardware mittels YaST in der Maske Administration des Systems, Hardware in System integrieren, ISDN-Hardware konfigurieren vorgenommen werden. Neben der Auswahl der Karte und dem Setzen der Parameter kann hier auch sofort das Modul geladen werden, und zwar durch <em/Starten/. Bei Problemen kann man sofort andere Werte probieren. Bei Erfolg werden die Parameter mittels <em/Speichern/ in <tt/rc.config/ abgelegt, so daß die Module beim nächsten Systemstart wieder geladen werden. Die Syntax ist in <tscreen><htmlurl url="file:/usr/src/linux/Documentation/isdn/README.HiSax" name="/usr/src/linux/Documentation/isdn/README.HiSaX"></tscreen> beschrieben. <sect2> Laden über /etc/rc.config <nidx>ISDN!/etc/rc.config</nidx> <nidx>/etc/rc.config</nidx> Die ISDN-Hardware kann direkt in der <tt>/etc/rc.config</tt> eingetragen und/oder kontrolliert werden. Die Variablen sind kommentiert. Hier ein Beispiel für eine <idx>Elsa QS-3000</idx>: <tscreen><verb> # # i4l starten? ("yes" oder "no") # siehe: /usr/doc/packages/i4l/README.SuSE # I4L_START="yes" # # Treiber-ID für HiSax-Treiber # - auf "HiSax" setzen # - oder auf das, was immer Du beim Laden des Treibers # ins Kernel definiert hast # - auf "" setzen, falls keine HiSax-Karte installiert # ist # I4L_TELES_ID="hisax1" # # D-Kanal Protokoll 1=1TR6, 2=EDSS1(Euro-ISDN) für HiSax # I4L_PROTOCOL="2" # Typ ISDN-Karte Benötigte Parameter --- ---------- ------------------- # 1 Teles 16.0 irq, mem, io # 2 Teles 8.0 irq, mem # 3 Teles 16.3 (nicht PnP) irq, io # 4 Creatix/Teles PnP irq, io0 (ISAC), # io1 (HSCX) # 5 AVM A1 (Fritz) irq, io # 6 ELSA PCC/PCF cards io oder nichts für eine # automatische Erkennung # (die iobase ist nur not- # wendig, falls Du mehr als # eine ELSA-Karte im PC # hast) # 7 ELSA Quickstep 1000 irq, io (vom isapnp # Setup) # 8 Teles 16.3 PCMCIA irq, io # 9 ITK ix1-micro Rev.2 irq, io # seit: HiSax 2.5: # 10 ELSA PCMCIA irq, io (mit dem Card # Manager setzen) # 11 Eicon.Diehl Diva ISA PnP irq, io # 11 Eicon.Diehl Diva PCI keine Parameter # 12 ASUS COM ISDNLink irq, io (vom isapnp # Setup) # 13 HFC-2BS0 basierte Karten irq, io # 15 Sedlbauer Speed Karte irq, io # (= Teledat 100) # 16 USR Sportster intern irq, io # 17 MIC Karte irq, io # 18 ELSA Quickstep 1000PCI keine Parameter # I4L_TELES_TYPE="7" # # IRQ für Teles Karte # z.B. 12 oder 15 wenn als Modul geladen # auf "" setzen, wenn der Treiber fest im Kernel ist # I4L_TELES_IRQ="3" # # Portadresse der Teles Karte (z.B. 0xd80, "0" für S0/8) # I4L_TELES_PORT="0x0160" </verb></tscreen> Der String <tt/TELES/ hat hier nur historische Gründe. Mit diesen Angaben wird die Parameterzeile für den HiSax-Treiber selbständig generiert. Zusätzlich kann man auch die Parameterzeile komplett selbst vorgeben, was z.B. bei neuen Karten notwendig ist, oder wenn man mehrere Karten einbinden will (s.u.). Beispiel für eine <idx/AVM-Fritz/ und eine <idx/ELSA PCF/-Karte: <tscreen><verb> I4L_TELES_MODUL_OPTIONS="type=5,6 protocol=2,2 io=0x340 \ irq=10 id=Fritz%Elsa" </verb></tscreen> Zum Laden der Module benutzt man dann ein Init-Skript: <nidx>/sbin/init.d/i4l_hardware</nidx> <nidx>ISDN!/sbin/init.d/i4l_hardware</nidx> <tscreen><verb> # /sbin/init.d/i4l_hardware start Loading ISDN drivers ... Loading HiSax driver ... /sbin/insmod /lib/modules/2.0.33/misc/hisax.o id=hisax1 \ type=7 protocol=2 irq=3 io=0x0160 Verbose-level set to 3. Starting isdnlog with /etc/isdn/isdnlog.isdnctrl0.options for isdnctrl0... </verb></tscreen> Man beachte, daß hiermit automatisch der <tt/isdnlog/ gestartet wird. Zum Entladen benutze man dasselbe Skript: <tscreen><verb> # /sbin/init.d/i4l_hardware stop Unloading ISDN drivers ... </verb></tscreen> <sect2> Laden von Hand Die Syntax ist in <tscreen><htmlurl url="file:/usr/src/linux/Documentation/isdn/README.HiSax" name="/usr/src/linux/Documentation/isdn/README.HiSax"></tscreen> beschrieben. Für eine <idx/ELSA-QS3000/ gebe man z.B. ein: <tscreen><verb> modprobe -v hisax id=hisax1 type=7 protocol=2 irq=3 \ io=0x0160 </verb></tscreen> Weiterhin sollten nach dem erfolgreichen Laden folgende Kommandos ausgeführt werden: <nidx>ISDN!hisaxctrl</nidx> <nidx>hisaxctrl</nidx> <nidx>ISDN!isdnctrl</nidx> <tscreen><verb> /sbin/hisaxctrl hisax1 1 4 /sbin/isdnctrl verbose 3 /sbin/isdnlog /dev/isdnctrl0 </verb></tscreen> Erklärt werden diese Kommandos in den entsprechenden Manual Pages und der mitgelieferten Dokumentation. Mit den SuSE-Skripts ist es halt einfacher ;-). <sect2> Troubleshooting <label id="DE-ISDN-HOWTO-HiSaxTrouble"> <nidx>ISDN!Probleme!Treiber</nidx> Während des Ladens des HiSax-Moduls bekommt man im Fehlerfall auf der Konsole keine aussagekräftigen Meldungen, sondern meist nur ein <tt/Device or resource busy/. Die echten Fehlermeldungen werden via Syslog zumeist in <tt><htmlurl url="file:/var/log/messages" name="/var/log/messages"></tt> gespeichert. Beispiel für einen Mißerfolg beim Laden des Treibers für eine AVM-Fritz-Karte: <tscreen><verb> Feb 6 22:45:05 glen kernel: HiSax: Driver for Siemens chip set ISDN cards Feb 6 22:45:05 glen kernel: HiSax: Version 2.1 Feb 6 22:45:05 glen kernel: HiSax: Revisions 1.15/1.10/1.10/1.30/1.8 Feb 6 22:45:05 glen kernel: HiSax: Total 1 card defined Feb 6 22:45:05 glen kernel: HiSax: Card 1 Protocol EDSS1 Id=HiSax (0) Feb 6 22:45:05 glen kernel: HiSax: AVM driver Rev. 1.6 Feb 6 22:45:05 glen kernel: AVM A1: Byte at 1b00 is ff Feb 6 22:45:05 glen kernel: AVM A1: Byte at 1b03 is ff Feb 6 22:45:05 glen kernel: AVM A1: Byte at 1b02 is ff Feb 6 22:45:05 glen kernel: AVM A1: Byte at 1b00 is ff Feb 6 22:45:05 glen kernel: HiSax: AVM A1 config irq:12 cfg:1b00 Feb 6 22:45:05 glen kernel: HiSax: isac:1700/1300 Feb 6 22:45:05 glen kernel: HiSax: hscx A:700/300 hscx B:f00/b00 Feb 6 22:45:05 glen kernel: AVM A1: HSCX version A: ??? B: ??? Feb 6 22:45:05 glen kernel: AVM A1: ISAC 2085 V2.3 Feb 6 22:45:05 glen kernel: AVM A1: wrong HSCX versions check IO address Feb 6 22:45:05 glen kernel: HiSax: Card AVM A1 not installed ! </verb></tscreen> Hier wurde an der angegebenen Portadresse keine Fritz-Karte gefunden. Es war auch keine vorhanden ;-). Anhand dieser Meldungen sollte man leicht erkennen können, was die genaue Ursache ist. Weitere häufige Fehler sind: <enum> <item> <tt/could not get interrupt/: mit dem angegebenen IRQ kann nicht gearbeitet werden. Probiere einfach einen anderen. Nicht belegte IRQs kann man durch <tscreen>cat /proc/interrupts</tscreen> ermitteln. <item> Die Portadresse wird nicht erkannt, obwohl alles richtig scheint. Es handelt sich um eine PnP-Karte und <tt/isapnp/ wurde vergessen; siehe hierzu Abschnitt <ref id="DE-ISDN-HOWTO-pnp" name="Plug&Play-Karten">. <item> Die Portadresse wird nicht erkannt, obwohl alles richtig scheint. Es wird eine Teleskarte verwendet, man kann also nicht wissen, um welchen Typ es sich wirklich handelt. Als Abhilfe sollte man sich die neueste HiSax-Version besorgen und alles ausprobieren, siehe hierzu Abschnitt <ref id="DE-ISDN-HOWTO-installation" name="Installation">. </enum> Bei hartnäckigem Mißerfolg wende Dich an einen guten Bekannten oder an die Mailingliste. Es sollte unbedingt ein Ausschnitt aus <tt>/var/log/messages</tt> angegeben werden.  <sect1>Hardware testen <label id="DE-ISDN-HOWTO-hwTesten"> <nidx>ISDN!Testanruf</nidx> Der beste und einfachste Test ist, sich selber anzurufen. Es spielt hierbei keine Rolle, ob man von einem internen oder externen Analog- oder ISDN-Telefon anruft. Es wird auch keine Verbindung zustande kommen. Wichtig ist nur, daß man in <tt><htmlurl url="file:/var/log/messages" name="/var/log/messages"></tt> eine Meldung über den Anruf finden kann. Beispiel für einen Voice-Call auf der MSN 123459: <tscreen><verb> Apr 6 22:15:20 glen kernel: isdn_net: call from 911123458,1,0 -> 123459 Apr 6 22:15:20 glen kernel: isdn_net: Service-Indicator not 7, ignored </verb></tscreen> Bei diesem Beispiel handelt es sich um einen Voice-Call (Service-Indicator: 0) von einem Anschluß mit Rufnummernübermittlung von der MSN 123458 aus dem Ortsnetz 0911 an die eigene MSN 123459. Nein, das ist nicht meine echte Nummer ;-). Wichtig ist hier vor allem die Angabe der Zielrufnummer hinter dem Pfeil, hier 123459. Man sollte hier alle eigenen Nummern durchprobieren. So wie es dort angegeben ist, ist auch später die eigene MSN zu setzen. <sect1>Übung: Hardware ansprechen <label id="DE-ISDN-HOWTO-uebungHW"> Ziel dieser Übung ist: die ISDN-Karte soll angesprochen und geprüft werden. <descrip> <tag>Welche Hardware/Umgebung habe ich?</tag> Notiere Dir: <enum> <item> Welche Karte hab ich (Hersteller, Typ, etc.)? <item> Wie ist die Karte gejumpert (Port)? <item> Mit welchen Werten kann die Karte unter anderen Systemen angesprochen werden? <item> Welches Protokoll wird auf dem S0-Bus benutzt (1TR6, DSS1)? <item> <em/Wo/ ist die ISDN-Karte angeschlossen (NTBA, TK-Anlage)? <item> Welche MSNs kann ich auf diesem S0-Bus benutzen? </enum> Schlimmstenfalls mußt Du Deinen Rechner aufschrauben, das falsche Betriebssystem booten und/oder den Administrator nerven. <tag>Betrachte messages</tag> <label id="DE-ISDN-HOWTO-lessVLM"> Nur in <tt>/var/log/messages</tt> steht die Wahrheit, sie ist für die gesamte Konfigurationsarbeit (und später) zu verfolgen. Öffne mindestens zwei virtuelle Linux-Konsolen oder unter X zwei <tt>xterm</tt>s. Auf einer Konsole starte entweder: <itemize> <item> <tt>tail -f /var/log/messages</tt> <item> <tt>less /var/log/messages</tt>, im Programm dann <tt>F</tt> (follow) drücken, um immer die neuesten Zeilen zu bekommen. Diesen Modus beendet man durch <tt>Ctrl-C</tt>, und <tt/less/ selbst wird mit <tt/q/ beendet. </itemize> <tag>PnP Karte?</tag> Falls es sich um eine Plug&Play-Karte handelt, konfiguriere sie; wenn Du es nicht weißt, starte <tt/pnpdump/. Siehe hierzu Abschnitt <ref id=DE-ISDN-HOWTO-pnp name="Plug&Play-Karten">. <tag>Modul laden</tag> Lade das entsprechende Modul nach Deiner bevorzugten Methode, also YaST ;-). Stelle sicher, daß die Einstellungen notiert sind und beim Systemstart automatisch das Modul wieder geladen wird. Prüfe mit <tt/lsmod/, ob das Modul geladen ist. Prüfe mit <tt>ps ax | grep isdnlog</tt>, ob der <tt/isdnlog/ läuft. Prüfe, ob <tt>/var/log/messages</tt> <em/normal/ aussieht. Siehe auch Abschnitt <ref id="DE-ISDN-HOWTO-HiSax" name="HiSax-Treiber laden">. <tag>ISDN testen</tag> Rufe Dich selbst an und notiere alle MSNs, unter denen Du angerufen werden kannst. Siehe Abschnitt <ref id="DE-ISDN-HOWTO-hwTesten" name="Hardware testen">. </descrip> <sect> Grundlagen ISDN, Parameter zur Verbindungskontrolle <label id="DE-ISDN-HOWTO-isdnctrl"> <nidx>ISDN!Grundlagen</nidx>  Dieser Abschnitt enthält einen Rundumschlag über die wichtigsten Begriffe und Konzepte, die man kennen muß, um ISDN unter Linux richtig zu nutzen. <sect1>ISDN <label id="DE-ISDN-HOWTO-isdn"> ISDN steht für <em/Integrated Services Digital Network/. Fangen wir von hinten an: Es handelt sich um ein <em/Netzwerk/. Über die beiden Kupferdrähte wird also z.B. nicht nur eine Point-To-Point Verbindung aufgebaut, sondern es können mehrere Verbindungen gleichzeitig bestehen. Die Daten werden alle <em/digital/ ausgetauscht. Analogdienste wie z.B. Fax der Gruppe 3 sind hierüber daher potentiell schwieriger zu handeln. Normalerweise werden Analogdienste über Spezialgeräte wie a/b-Wandler oder TK-Anlagen an ISDN angeschlossen. <em/Integrated Services/ deutet an, daß verschiedene Dienste über dieses Netzwerk behandelt werden können. Typische Services sind <em/Analoge-Sprache/ (SI=0) oder <em/ISDN-Daten/ (SI=7), was uns hier interessiert. <nidx>ISDN!NTBA</nidx> <nidx>NTBA</nidx> Der Endpunkt der Telekom-Leitung ist der <em/NTBA/ (kurz auch <em/NT/), der <em/Network Terminator Basis-Anschluß/. Das ist der kleine graue Kasten, an dem für die Telekom das Netzwerk aufhört. <nidx>ISDN!S0-Bus</nidx> <nidx>S0-Bus</nidx> An einem NTBA können normalerweise zwei Kabel herausgeführt werden, diese bilden gemeinsam ein Bus-System, den sogenannten <em/S0-Bus/. An den S0-Bus können acht <em/Endgeräte/ angeschlossen werden. Typische Endgeräte sind ISDN-Telefone, TK-Anlagen G4-Fax-Geräte, ISDN-Terminaladapter und ISDN-Karten. <nidx>ISDN!D-Kanal</nidx> <nidx>ISDN!B-Kanal</nidx> <nidx>D-Kanal</nidx> <nidx>B-Kanal</nidx> Der S0-Bus bietet drei Kanäle: einen Steuerkanal, der <em/D-Kanal/ genannt wird, und zwei Datenkanäle, die <em/Nutzkanäle/ oder <em/B-Kanäle/ genannt werden. Über die B-Kanäle werden die eigentlichen Daten übertragen. Jeder B-Kanal bietet eine Geschwindigkeit von 64 kbit/s, wobei die beiden B-Kanäle für Verbindungen zu zwei unterschiedlichen Partnern und für unterschiedliche Dienste genutzt werden können. <nidx>ISDN!1TR6</nidx> <nidx>ISDN!DSS1</nidx> <nidx>ISDN!N1</nidx> <nidx>1TR6</nidx> <nidx>DSS1</nidx> <nidx>N1</nidx> Auf dem D-Kanal können verschiedene Protokolle gefahren werden. Üblich sind <em/1TR6/ (altes nationales ISDN), <em/DSS1/ (<em/Euro-ISDN/, der Quasi-Standard in 24 Ländern) und <em/N1/ in den USA. Der D-Kanal dient u.a. zur Übermittlung des Wunsches eines Verbindungsauf- und abbaus, der Übermittlung der Telefonnummern und der Gebühren. Bei einem falsch eingestellten Protokoll klappt also sehr wenig. <nidx>ISDN!MSN</nidx> <nidx>MSN</nidx> <nidx>ISDN!EAZ</nidx> <nidx>EAZ</nidx> Die Art und Weise, wie die Telefonnummer gemeldet und genannt wird, hängt vom D-Kanal-Protokoll ab: <descrip> <tag/1TR1/ <em/EAZ/ (Endgeräte-Auswahl-Ziffer): Es handelt sich also nur um eine Ziffer, die Rufnummer des Basisanschlusses wird nicht betrachtet. <tag/DSS1/ <em/MSN/ (Multiple-Subscribe-Number): Hier ist eine komplette Rufnummer gemeint, also alles hinter der Vorwahl. </descrip> Die Bezeichnungen EAZ und MSN sind bei I4L ansonsten synonym zu benutzen, wenn das richtige Protokoll angegeben wurde. Bei einem eingehenden Anruf wird hoffentlich die Zielrufnummer übertragen, genannt <em/CPN/ (called party number). Ist sie nicht bekannt, setzt sie I4L auf <tt/0/. Bekanntlich können für einen Anschluß mehrere Telefonnummern vergeben werden. Diese signalisiert die Vermittlungsstelle, kurz <em/VSt/ genannt, auf dem D-Kanal (CPN) zusammen mit dem <em/Service-Indikator/ (<bf/SI/). Mehr passiert bei einem ankommenden Anruf erst mal nicht. Es ist danach Aufgabe der Endgeräte, sich entsprechend zu verhalten: ignorieren, abweisen, oder den Anruf annehmen. Da der SI zusammen mit der Nummer auf dem D-Kanal übermittelt wird, kann dieselbe Telefonnummer mehrfach genutzt werden. So reagiert z.B. das Telefon nur auf SI=0, der PC nur auf SI=7. Bei einem ausgehenden Call muß das Endgerät die MSN angeben; diese wird dann auch dem Partner übermittelt. Wird keine MSN gesetzt, was I4L nicht zuläßt, setzt die VSt die Nummer ein; wird eine falsche MSN gesetzt, bekommt man keine Verbindung (Erfahrungswerte). Mehr zu ISDN-Grundlagen findet sich auf: <tscreen><htmlurl url="http://www.dtag.de/angebot/isdn/lexikon/right.htm" name="http://www.dtag.de/angebot/isdn/lexikon/right.htm"></tscreen>  <sect1>TK-Anlagen <label id="DE-ISDN-HOWTO-GrundlagenTK"> <nidx>ISDN!Telefonanlage</nidx> Wer die Wahl hat zwischen einem direkten Anschluß am NTBA und einem internen S0-Bus an einer TK-Anlage, sollte sich für den direkten Anschluß entscheiden. Der Betrieb über TK-Anlagen birgt immer gewisse Überraschungen. Wenn man eine TK-Anlage am selben NTBA (S0-Bus) wie die ISDN-Karte angeschlossen hat, gibt es keine Probleme. Die TK-Anlage verhält sich wie ein normales ISDN-Endgerät. Welche Dienste die TK-Anlage den an sie angeschlossenen Endgeräten anbietet, spielt hier keine Rolle. Das Verhalten der TK-Anlage hängt unter anderem vom Typ, von der installierten Software und vor allem von deren Konfiguration und damit vom entsprechenden Service-Techniker ab. Bei älteren Anlagen wird oft entgegen allen Aussagen 1TR6 anstatt DSS1 gefahren. Die Verbindungstypen können abhängig vom Service-Indikator konfiguriert werden, wobei oft nur Voice-Calls konfiguriert sind. Weiterhin besteht die Schwierigkeit, herauszufinden, welche MSN/EAZ man zu benutzen hat. Bevor man sich auf andere verläßt, sollte man den Praxistest <em/Selbstanruf/ machen, siehe Abschnitt <ref id="DE-ISDN-HOWTO-hwTesten" name="Hardware testen">. Ein wesentlicher Unterschied ist, daß man nicht mit allen anderen lokalen Teilnehmern an einem Bus angeschlossen ist, sondern die TK-Anlage für jeden einzelnen Anschluß einen eigenen S0-Bus nach außen führt, an den meist nur ein Endgerät angeschlossen wird. Dieser Anschluß bekommt eine eigene Durchwahl zugewiesen, oft 2-stellig. Die beste Veranschaulichung ist die, daß man sich seine TK-Anlage als eine eigene Vst vorstellt. Beispiel: In Ortsnetz 321 ist eine TK-Anlage mit der Rufnummer 654 an einem Primärmultiplex-Anlagenanschluß installiert. Es gibt also mehr als zwei Amtsleitungen, alternativ könnte dies auch ein Bündelanschluß sein; dieses spielt aus dieser Sicht keine Rolle. Es sind 20 interne Leitungen vorhanden, wobei die ersten 10 für Telefone und die zweiten 10 für ISDN-Karten vorgesehen sind. Die Durchwahlnummern seien 10-19 für die Telefone und 20-29 für die ISDN-Karten. Die S0-Busse für die ISDN-Karten seien auf DSS1 konfiguriert. Dann ist als MSN jeweils 20 bis 29 zu benutzen, denn das sind die MSNs im Ortsnetz <em/Firma/ (=321654). Weiterhin ist zu beachten, daß man zusätzlich eine <tt/0/ wählen muß, um aus dem Ortsnetz <em/Firma/ erst mal herauszukommen. Um z.B. die Nummer 987 im Ortsnetz 654 anzurufen, muß man <tt/0987/ wählen, wobei der Gegenstelle als Rufnummer <tt/65420/ angezeigt wird. Will man in Berlin anrufen, wählt man selbst die <tt/0030..../ an und dort wird <tt/32165420/ übermittelt. Will man selber eine Benutzerauthenifizierung beim Dial-In über die Telefonnummer machen, gibt es nur eine sinnvolle Herangehensweise: anrufen lassen. Die in <tt>/var/log/messages</tt> angezeigte Nummer kann man dann mittels Cut&Paste in die entsprechende Konfigurationsdatei übernehmen. <sect1>Was ist meine MSN? <label id="DE-ISDN-HOWTO-msnWelche"> <nidx>ISDN!MSN</nidx> <nidx>MSN</nidx> Wie oben erwähnt, muß man bei I4L immer die MSN setzen, um wählen zu können. Die Angabe der MSN ist wichtig, da ansonsten meist nichts funktioniert. Die erste Frage ist dabei immer, ob man direkt am NTBA oder an einer TK-Anlage angeschlossen ist. <descrip> <tag>Anschluß an NTBA</tag> Man kann sich eine der drei oder mehr zugewiesenen MSNs aussuchen. Diese MSN wird der Gegenstelle übermittelt. Wird die MSN zur Überprüfung des Partners benutzt (z.B. bei rawip), muß man sich mit der Gegenstelle natürlich fest auf eine einigen. Ansonsten hat man die freie Wahl, man kann durchaus seine normale Voice-Nummer benutzen. <tag>Anschluß an TK-Anlage</tag> Man ist auf die Konfiguration der TK-Anlage angewiesen. Die einfachste Methode ist der Selbsttest, siehe Abschnitt <ref id="DE-ISDN-HOWTO-hwTesten" name="Hardware testen">. </descrip> <sect1> Probleme beim Verbindungsaufbau, die Cause-Meldungen <label id="DE-ISDN-HOWTO-cause"> <nidx>ISDN!Probleme!Verbindungsaufbau</nidx> <nidx>ISDN!isdn_cause</nidx> Das Protokoll auf dem D-Kanal erlaubt es, Meldungen zu verschicken, die über den Grund bei einem Verbindungsabbruch und bei nicht erfolgreichem Verbindungsaufbau informieren. Die Meldungen werden in <tt>/var/log/messages</tt> vom i4l-Subsystem als sogenannte <tt>cause</tt>-Meldungen gespeichert. Die Art der Meldung hängt vom verwendeten Protokoll ab (1TR6 oder DSS1). Bei DSS1 wird ein <tt/E/ (für Euro-ISDN) vorangestellt, dahinter folgen vier hexadezimale Ziffern. Die ersten beiden geben Auskunft darüber, wo diese Meldung generiert wurde (bei welcher VSt); die letzten beiden Ziffern geben den eigentlichen Grund an. Der <tt/isdnlog/ übersetzt uns freundlicherweise die Meldungen in Klartext; wenn der nicht läuft, z.B. bei aktiven ISDN-Karten, kann man die Meldungen mittels <tt/man isdn_cause/ auflösen. Nicht alle Meldungen müssen <em/dramatisch/ sein und auf einen Fehler hinweisen. Bei folgendem Beispiel ist die Ursache, daß der andere Teilnehmer <em/normal/, vermutlich wegen einem Timeout, aufgelegt hat: <tscreen><verb> kernel: isdn: hisax1,ch0 cause: E0010 kernel: ippp0: remote hangup </verb></tscreen> Bei dem zweiten Beispiel wird die Meldung dadurch verursacht, daß die VSt des anderen Teilnehmers uns mitteilt, daß dort der Anschluß besetzt ist: <tscreen><verb> kernel: isdn: hisax1,ch0 cause: E0511 isdnlog: Mar 19 20:00:32 tei 70 calling Leibnitz with Kfr User busy (Private network serving remote user) </verb></tscreen> Wenn alle Kanäle belegt sind, bekommt man folgende Meldung: <tscreen><verb> kernel: isdn: hisax1,ch0 cause: E0022 isdnlog: Mar 19 21:37:16 tei 70 calling Klein with +49 911/ 333, N|rnberg No circuit/channel available (User) </verb></tscreen> Die nachfolgende Meldung erhält man immer dann, wenn die Zielrufnummer nicht zugewiesen ist: <tscreen><verb> kernel: isdn0: dialing 1 1111111111... isdnlog: Apr 13 15:05:18 * tei 84 calling +49 911/111111111, N|rnberg with Kfr RING (Data) kernel: isdn: hisax1,ch0 cause: E0201 isdnlog: Apr 13 15:05:19 * tei 127 calling ? with ? Unallocated (unassigned) number (Public network serving local user) </verb></tscreen> <sect> syncPPP-Verbindung herstellen <label id="DE-ISDN-HOWTO-syncPPP"> <nidx>ISDN!PPP</nidx> <nidx>ISDN!synchrones PPP</nidx> <nidx>PPP!ISDN</nidx> Das <em/Point-to-Point Protocol/ (PPP) ist unter anderem in den RFCs 1661, 1662, 1332 und 1334 definiert. Es wurde ursprünglich entwickelt, um Daten über serielle Leitungen zu verschicken. Es kann grundsätzlich für verschiedene Netzwerkprotokolle wie Apple, IP, IPX, usw. verwendet werden; unter Linux ist aber nur IP vorgesehen. PPP bietet verschiedene Features, wie z.B. den Austausch der IP-Nummern, Authentifizierung, Komprimierung und einige andere. Aus diesem Grund findet zunächst durch das Link Control Protocol (LCP) ein Handshake statt, durch den die Verbindung initialisiert wird oder eben auch nicht. In der Praxis ergeben sich genau hierdurch die Probleme gemäß der Richtlinie <em/das schöne an Standards ist, daß sich jeder seinen eigenen aussuchen kann/. <sect1> Unterschiede Analog - ISDN <label id="DE-ISDN-HOWTO-pppIppp"> Wer analoges PPP gewöhnt ist, muß hier ein wenig umdenken.  Die Netzverbindung besteht logisch immer, gewählt wird aber nur bei Bedarf. <sect2>Analog <itemize> <item> manuelles Starten per Skript oder über <tt/diald/ <item> wählen, z.B. mit <tt/chat/ <item> <tt/pppd/ fährt hoch und macht Handshake mit Partner <item> <tt/ifconfig/ und <tt/route/ Aufrufe durch <tt/pppd/ <item> Optionsfile: <tt>/etc/ppp/options</tt> <item> Liest automatisch <tt>/etc/ppp/options.DEVICE</tt>, wobei <tt/DEVICE/ das aktuell verwendete serielle Device ist. </itemize> <sect2> ISDN <itemize> <item> Netz wird konfiguriert, diverse <tt/isdnctrl/ und ein <tt/ifconfig/ Aufruf <item> Setzen der Route <item> <tt/ipppd/ wird gestartet <item> Bei einem Verbindungswunsch wählt i4l selbständig die Nummer (<tt/isdnctrl/). <item> <tt/ipppd/ wird aktiviert; er läuft die ganze Zeit <item> <tt/ipppd/ macht Handshake <item> Bei dynamischen IP-Nummern legt der <tt/ipppd/ das Device neu an und startet <tt>/etc/ppp/ip-up</tt>. <item> Beim automatischen Abbau macht der <tt/ipppd/ ein Reconnect auf das Device; der analoge PPP-Daemon beendet sich. <item> Beim Abbau startet der <tt/ipppd/ <tt>/etc/ppp/ip-down</tt>. <item> Optionsfile: <tt>/etc/ppp/ioptions</tt> <item> Liest kein weiteres Optionsfile automatisch ein. </itemize> <sect1> Was ist eigentlich synchrones PPP? <label id="DE-ISDN-HOWTO-syncPPPwas"> Der Unterschied zwischen synchronem und asynchronem PPP ist das <em/Framing/, also das Einpacken der Rohdaten für die jeweilige Verbindungsart. SyncPPP packt in HDLC ein. Auf einer Modemstrecke bzw. einer seriellen Schnittstelle kann man aber nur zeichenweise arbeiten. Entsprechend packt asyncPPP seine Päckchen anders ein. Es gibt ein ausgewiesenes Byte, welches den Paketanfang bzw. das Ende markiert. Diese Byte muß, sofern es im Datenstrom auftaucht, natürlich anders dargestellt werden. Dafür gibt es ein weiteres reserviertes Byte, das Escape-Byte. <sect1> Die Konfiguration <label id="DE-ISDN-HOWTO-ipppdConfig"> <sect2> Netzdevices anlegen und konfigurieren <nidx>ISDN!isdnctrl</nidx> <nidx>ISDN!Netzwerkdevices</nidx> <nidx>Netzwerk!Device</nidx> Nachfolgend wird gezeigt, wie die Netzwerkdevices angelegt und konfiguriert werden: <tscreen><verb> NETDEV='ippp0' # neues Device isdnctrl addif $NETDEV # setzte MSN/EAZ isdnctrl eaz $NETDEV 456 # def. Nummer(n) zum Rauswählen isdnctrl addphone $NETDEV out 09011 # erlaube Nummern, die anrufen dürfen #isdnctrl addphone $NETDEV in # dürfen alle anrufen? Nein: setze secure=on isdnctrl secure $NETDEV on # Layer-2 Protokoll: (x75i, x75ui, x75bui, hdlc) isdnctrl l2_prot $NETDEV hdlc # Layer-3 Protokoll: (nur trans) isdnctrl l3_prot $NETDEV trans # Ecapsulation: (rawip, cisco_h, syncppp) isdnctrl encap $NETDEV syncppp # Idletime isdnctrl huptimeout $NETDEV 60 # maximale Wählversuche isdnctrl dialmax $NETDEV 5 # nur einen bestimmten Kanal benutzen #isdnctrl bind $NETDEV # PPP an Netzdevice binden isdnctrl pppbind $NETDEV 0 # Netzdevice konfigurieren ifconfig $NETDEV 1.1.1.1 pointopoint 193.102.150.13 up # OPEN-Meldung ausgeben: isdnctrl verbose 3 </verb></tscreen> Gelöscht wird das Interface durch die Befehle: <tscreen><verb> ifconfig $NETDEV down isdnctrl delif $NETDEV </verb></tscreen> <sect2> ipppd starten <label id="DE-ISDN-HOWTO-ipppdStart"> <nidx>ipppd!Start</nidx> <nidx>ISDN!ipppd!Start</nidx> Vor dem Start des <tt/ipppd/ müssen drei Voraussetzungen erfüllt sein: <enum> <item> ISDN-Hardwareunterstützung <item> syncPPP-Unterstützung im Kernel <item> Das zu verwendende Device muß angelegt sein (<tt/isdnctrl addif/). </enum> Die syncPPP-Unterstützung des Kernels überprüft der <tt/ipppd/ leider über eine etwas unglückliche Methode: Es muß ein Device <tt/ippp0/ vorhanden sein. Außerdem kann man das Device nicht beliebig benennen, es muß mit <tt/ippp/ beginnen. Deshalb sollte man sich unbedingt merken, als Devicenamen immer <tt/ippp0/ zu verwenden. <nidx>/etc/ppp/ioptions</nidx> <nidx>ipppd!/etc/ppp/ioptions</nidx> <nidx>ISDN!ipppd!/etc/ppp/ioptions</nidx> <nidx>PPP!/etc/ppp/ioptions</nidx> Der <tt/ipppd/ kann über 2,5 Arten Optionen annehmen: <itemize> <item> Kommandozeilenparameter <item> das Optionsfile <tt>/etc/ppp/ioptions</tt> </itemize> Die 2,5te Methode ist die Angabe eines Optionsfiles als Kommandozeilenparameter (<tt/-file/). In Anlehnung an den <tt/pppd/ empfehle ich folgende Struktur: <itemize> <item> Globale Optionen für alle <tt/ipppd/s sollten in <tt>/etc/ppp/ioptions</tt> gesetzt werden. <item> Für Devicespezifische Optionen, wie z.B. für <tt/ippp0/, sollte eine spezielle Datei wie <tt>/etc/ppp/options.ippp0</tt> verwendet werden. <item> Der <tt/ipppd/ wird so gestartet: <tscreen><verb> ipppd pidfile /var/run/ipppd.ippp0.pid \ file /etc/ppp/options.ippp0 & </verb></tscreen> </itemize> Folgendes sollte man noch über den <tt/ipppd/ wissen: <itemize> <item> Es werden zum Teil andere Optionen als beim <tt/pppd/ benutzt; zu den Unterschieden siehe <tt/man ipppd/. <item> Die Optionen und Paßwörter werden nur beim Start neu eingelesen. Beim Testen sollte man also immer nachschauen, ob noch <tt/ipppd/s laufen und diese neu starten. <item> Es können verschiedene <tt/ipppd/ auf ein Device reagieren, daher <tt/pppbind/. <item> Die Datei <tt>/etc/ppp/ioptions</tt> muß existieren. </itemize> Folgende Optionen haben sich für die verschiedensten ISPs als stabil erwiesen: <label id="DE-ISDN-HOWTO-optionsippp0"> <tscreen><verb> # /etc/ppp/options.ippp0 # # für isdn4linux/syncPPP und dynamische IP-Nummern # # # Klaus Franken, kfr@suse.de # Version: 27.08.97 (5.1) # # Diese Datei wird von YaST von /etc/ppp/ioptions.YaST # nach options.<device> kopiert. # die Device(s) # für mehr als ein Device versuche folgendes: # /dev/ippp0 /dev/ippp1 ... /dev/ippp0 # die IP-Adresse: <lokal>:<remote> # einfach "0.0.0.0:" oder nichts für dyn. IP #0.0.0.0: # der eigene Benutzername user suse # der eigene Systemname (nur für CHAP!) # name my_system_name # IP-Adressen vom Partner akzeptieren # dynamische IP-Nummern verwenden ipcp-accept-local ipcp-accept-remote noipdefault # versuche, die IP-Adresse vom Interface zu ermitteln # nur mit statischer IP-Adresse verwenden #useifip # alle Header-Komprimierungen abschalten -vj -vjccomp -ac -pc -bsdcomp # manchmal wird dies benötigt: #noccp # max receive unit mru 1524 # max transmit unit mtu 1500 # Wenn es sich bei dem Rechner um einen Server handelt, # können sie durch Entfernen des Kommentarzeichens bei # einem der folgenden Einträge eine Authentifizierung # erzwingen. Wenn der Rechner jedoch als Client ver- # wendet wird, würde das eine erfolgreiche Verbindung # verhindern (Meldung: "peer refused to authenticate"). # # "+pap" / "+chap" NUR AKTIVIEREN, WENN DIES EIN # SERVER IST!!! #+pap #+chap # Wenn es Problem mit dem Handshaking gibt (keine # Antwort auf das erste lcp-Paket), sollte versucht # werden, den Wiederholungszyklus zu verringern. # Der Standard sind drei Sekunden, versuche z.B. # zwei Sekunden: # lcp-restart 2 </verb></tscreen> <sect2> Authentifizierung beim ipppd <label id="DE-ISDN-HOWTO-ipppdAuth"> <nidx>ipppd!Authentifizierung</nidx> <nidx>ISDN!ipppd!Authentifizierung</nidx> <nidx>ipppd!PAP</nidx> <nidx>ipppd!CHAP</nidx> <nidx>ISDN!ipppd!PAP</nidx> <nidx>ISDN!ipppd!CHAP</nidx> <nidx>PPP!CHAP</nidx> <nidx>PPP!PAP</nidx> Der <tt/ipppd/ verhält sich bei der Benutzerauthentifizierung exakt genauso wie der <tt/pppd/. Daher erfolgt hier nur ein kurzer Abriß. Es stehen zwei Methoden zur Verfügung: PAP und CHAP. Meistens wird PAP angeboten; über CHAP kann man im <htmlurl url="DE-PPP-HOWTO.html" name="PPP HOWTO"> nachlesen. Die Benutzerdaten werden an zwei Stellen konfiguriert; als erstes wird dem <tt/ipppd/ durch das Schlüsselwort <tt>user</tt> mitgeteilt, welche UserID dem gegnerischen PPP-Daemon angeboten werden soll. <nidx>/etc/ppp/pap-secrets</nidx> <nidx>ipppd!/etc/ppp/pap-secrets</nidx> <nidx>ISDN!ipppd!/etc/ppp/pap-secrets</nidx> <nidx>PPP!/etc/ppp/pap-secrets</nidx> Als nächstes wird das Paßwort selbst als Klartext in der Datei <tt>/etc/ppp/pap-secrets</tt> abgelegt. Diese Datei darf nur für root lesbar sein. Also passe unbedingt die Rechte an: <tscreen><verb>chmod 600 /etc/ppp/pap-secrets</verb></tscreen> Für jeden verwendeten User wird eine Zeile eingetragen; z.B. sei der Benutzername <tt>suse</tt> und das Paßwort <tt>linux</tt>: <tscreen><verb> # client server pw iplist "suse" * "linux" </verb></tscreen> Dies ist die einzige Stelle, an der das Paßwort definiert ist. In der Datei <tt>/etc/ppp/pap-secrets</tt> können mehrere User/Paßwörter definiert sein, über die Option <tt>user</tt> wird jeweils die richtige Zeile ausgewählt, um das Paßwort zu ermitteln. Der Benutzername muß nicht im System bekannt sein, zumindest besteht zwischen dem PAP- oder CHAP-Benutzernamen und dem Systembenutzer kein Zusammenhang. Nachdem der <tt/ipppd/ gestartet ist und eventuell eine Route darüber definiert ist, wird bei Bedarf automatisch ein Wählvorgang ausgelöst. Manuell kann man dies so auslösen: <tscreen>isdnctrl dial ippp0</tscreen> Meldungen werden über syslog nach <tt>/var/log/messages</tt> geschrieben. <sect2> Welche Daten muß ich über den Zugang kennen? <label id="DE-ISDN-HOWTO-ipppdPars"> Folgende Daten sollte man kennen, die meisten sollte der ISP zur Verfügung stellen. <descrip> <tag/Protokoll/ Es sollte syncPPP sein. <tag/Telefonnummer des ISP/ Natürlich benötigt man die Telefonnummer des Providers. <tag/meine MSN/ Mit welcher meiner Telefonnummern möchte/muß ich wählen, siehe dazu Abschnitt <ref id="DE-ISDN-HOWTO-msnWelche" name="Was ist meine MSN?">. <tag/IP-Nummern/ Wenn man feste IP-Nummern hat, gibt der ISP zumindest die persönlichen an. Die IP-Nummer auf der anderen Seite der PtP-Verbindung, also die des ISPs, kennt man deswegen noch nicht unbedingt. In einem solchen Fall gibt man wie bei dynamischen IP-Nummern <em/irgendeine/ IP-Nummer vor und läßt eine Verbindung herstellen, damit man die wirkliche IP-Nummer sieht, die man dann fest einträgt. Bei dynamischen IP-Nummern trägt man <em/irgendwelche/ Nummern ein; siehe Abschnitt <ref id="DE-ISDN-HOWTO-dynIP" name="Probleme mit dynamischen IP-Nummern">. <tag/Typ der Authentifizierung/ PAP oder CHAP <tag/Username, Paßwort/ Natürlich muß man den Benutzernamen und das passende Paßwort auf dem PPP-Server kennen. <tag/Nameserver/ Die IP-Nummer des zu verwendenden Nameservers sollte man vom ISP mitgeteilt bekommen. Ansonsten siehe <tscreen><htmlurl url="http://www.suse.de/Support/sdb/nonameserver.html" name="http://www.suse.de/Support/sdb/nonameserver.html"> </tscreen> </descrip> Mit folgenden weiteren Parametern kann man die ISDN-Verbindung steuern: <descrip> <tag/Idle-Time/ Nach wie vielen Sekunden Inaktivität soll aufgelegt werden. Will man dieses Feature abstellen, kann man die Zeit auf »0« stellen. Diese Zeitangabe ist jedoch nicht exakt. <tag/Maximale Wählversuche/ Wie oft soll gewählt werden, wenn der Gegner nicht abnimmt? Diese Anzahl gilt nicht, wenn es Hardwareprobleme gibt; zieht man z.B. das ISDN-Kabel, wird unendlich oft probiert. Diese Anzahl gilt nicht, wenn die Wählverbindung zustande kam, aber die PPP-Verbindung nicht aufgebaut werden konnte. Ist z.B. das Paßwort falsch eingetragen, wird immer wieder eine Verbindung aufgebaut, solange Pakete verschickt werden. <tag/eingehende Telefonnummern/ In diesem Fall soll keiner die Verbindung von außen aufbauen dürfen, deshalb sollte man keine eingehende Telefonnummer angeben und die Option <tt/secure/ bzw. <em/Nur angegebene Nummern erlaubt/ aktivieren. <tag/Callback/ Mehr zum Thema Callback findet sich in <tscreen><htmlurl url="file:/usr/doc/packages/doc/rc.config.i4l.add" name="/usr/doc/packages/doc/rc.config.i4l.add"></tscreen> </descrip> <sect2> PPP bei SuSE einrichten <label id="DE-ISDN-HOWTO-pppSuSE"> <nidx>ipppd!Konfiguration</nidx> <nidx>ISDN!ipppd!Konfiguration</nidx> Die Konfiguration bis auf's Routing wird in der Datei <tt>/etc/rc.config</tt> eingetragen, dies kann manuell oder über YaST geschehen. <sect3> Konfiguration mit YaST Um PPP über YaST zu konfigurieren, geht man so vor: <itemize> <item> Menüpunkt <em/Administration des Systems/, <em/Netzwerk konfigurieren/ und <em/Netzwerk Grundkonfiguration/ auswählen. <item> Es erscheint eine Maske der konfigurierten Netzdevices. Hier wähle man ein freies aus, sofern es nicht schon <tt/ippp0/ gibt. Mit <tt/F5/ wählt man den Netzwerktyp aus, hier also <em/ISDN SyncPP/. <item> Mit <tt/F6/ vergibt man die IP-Nummern, siehe Abschnitt <ref id="DE-ISDN-HOWTO-ipDynWelche" name="Welche IP-Nummer setze ich denn eigentlich?">, und kann auch direkt das Default-Gateway angeben, siehe Abschnitt <ref id="DE-ISDN-HOWTO-routing" name="Routing">. <item> Mit <tt/F8/ werden nun die ISDN-relevanten Daten eingetragen. Nachdem man das Device aktiviert hat, kann man es in der ISDN-Maske direkt hochfahren mit: <em/Starten/. </itemize> Damit sind die <tt/rc.config/-Variablen, die PPP-Optionen, die Paßwortdatei und das Routing angepaßt. <sect3> Manuelle Konfiguration Durch folgende Variablen in <tt>/etc/rc.config</tt> wird eine syncPPP-Verbindung gesteuert, hier als echtes Beispiel (mit <tt/_0/): <tscreen><verb> IPADDR_2="1.1.1.1" NETDEV_2="ippp0" IFCONFIG_2="1.1.1.1 pointopoint 193.102.150.13 up" I4L_IDLETIME_2="60" I4L_DIALMAX_2="5" I4L_LOCALMSN_2="7417559" I4L_REMOTE_OUT_2="52145922" I4L_REMOTE_IN_2="" I4L_ENCAP_2="syncppp" I4L_SECURE_2="on" </verb></tscreen> Die Bedeutung der Felder ist oben angegeben; in der <tt>/etc/rc.config</tt> sind auch vor den Feldern entsprechende Kommentare. Es können beliebig viele Netzdevices definiert werden, auch wenn standardmäßig nur vier angegeben sind, die jeweils durch eine Extension wie z.B. <tt/_2/ gekennzeichnet werden. Dabei müssen nicht alle aktiv sein. Welche aktiviert werden sollen, wird in der Variablen <tt/NETCONFIG/ festgelegt; sollen z.B. <tt/_0/ und <tt/_2/ aktiv sein, setzt man: <tt/NETCONFIG="_0 _2"/. Als nächstes muß der <tt/ipppd/ konfiguriert werden. Hierzu erstelle man eine Datei <tt>/etc/ppp/options.ippp0</tt> (siehe Abschnitt <ref id="DE-ISDN-HOWTO-optionsippp0" name="PPP-Optionen">); am besten in dem Du die Datei <tt>/etc/ppp/ioptions.YaST</tt> kopierst. In der Optionendatei muß der Benutzername gesetzt werden und überprüft werden, ob das Device stimmt. Dann trägst Du das Paßwort passend zum Benutzernamen in <tt>/etc/ppp/pap-secrets</tt> ein. Das manuelle Starten ist in Abschnitt <ref id="DE-ISDN-HOWTO-ipppdStart" name="ipppd starten"> beschrieben. <sect1> Probleme beim Verbindungsaufbau, Troubleshooting. <label id="DE-ISDN-HOWTO-syncPPPtrouble"> <nidx>ipppd!Probleme</nidx> <nidx>ISDN!ipppd!Probleme</nidx> Bei Problemen sollte man folgende Checkliste durchlaufen: <enum> <item> Wurde der <tt/ipppd/ überhaupt gestartet? Kontrolliere mit <tscreen>ps ax | grep ipppd</tscreen> ob einer läuft bzw. wieviele laufen. Kontrolliere in <tt>/var/log/messages</tt> die Startmeldungen, z.B.: <tscreen><verb> syslog: info: no CHAP secret entry for this user! ipppd[536]: Found 1 devices: /dev/ippp0, ipppd[540]: ipppd i2.2.9 (isdn4linux version of pppd by MH) started ipppd[540]: init_unit: 0 ipppd[540]: Connect[0]: /dev/ippp0, fd: 8 </verb></tscreen> <item> Stimmen die Benutzerdaten? Der <tt/ipppd/ prüft schon beim Start, mit welchem Usernamen gearbeitet wird (<tt/user suse/). Zu diesem Namen wird das entprechende Paßwort gelesen. Klappt das nicht, wird eine Meldung ausgegeben, z.B.: <tscreen><verb> Apr 9 20:32:17 glen syslog: info: no PAP secret entry for this user! </verb></tscreen> In diesem Fall wird eine Einwahl mittels PAP nicht funktionieren, die 12 Pfennige kann man sich also sparen. Ursache ist meist ein Tippfehler beim Benutzernamen oder falsche Permisssions der <tt/pap-secrets/. Analoges gilt für CHAP. <item> Wird überhaupt eine Verbindung aufgebaut? Sobald die Gegenstelle abnimmt und damit Kosten entstehen, erscheint eine <tt>connect</tt>-Meldung. Wird keine Verbindung aufgebaut, gibt es vermutlich eine <tt/cause/-Meldung, siehe Abschnitt <ref id="DE-ISDN-HOWTO-cause" name="Cause Meldungen">. Erscheinen nur <tt/dialing/-Meldungen, aber sonst nichts, liegt es an der Hardware oder am Hardware-Modul, siehe die Abschnitte <ref id="DE-ISDN-HOWTO-hwTesten" name="Hardware testen"> und <ref id="DE-ISDN-HOWTO-installation" name="Installation">. <item> Klappt die Einwahl? Bei erfolgreicher Einwahl erscheinen Meldungen über die IP-Nummern, z.B.: <tscreen><verb> ipppd[540]: local IP address 149.228.142.59 ipppd[540]: remote IP address 193.102.150.13 </verb></tscreen> Sieht man diese Meldungen, dann Glückwunsch! Der Gegner wird ab jetzt zum Partner. <item> <tt>select: Bad file number</tt> Direkt nach der Ausgabe der IP-Nummern erscheint: <tscreen><verb> ipppd[353]: select: Bad file number ipppd[353]: Couldn't restore device fd flags: Bad file number ipppd[353]: Exit. </verb></tscreen> Was hat es damit auf sich? Zunächst einmal, die Verbindung ist trotz allem aufgebaut. Die Ursache ist folgende: der <tt/ipppd/ startet beim Connect bzw. Disconnect das Skript <tt>/etc/ppp/ip-up</tt> bzw. <tt/ip-down/. Aufgrund eines kleinen Fehlers im offiziellen <tt/ipppd/, der in der CVS-Version und ab SuSE 5.2 behoben ist, ist die Überprüfung auf Ausführbarkeit fehlerhaft, woraufhin trotzdem versucht wird, das Skript zu starten. Nach der Fehlermeldung passiert genau nichts. Allerdings sollte die Meldung trotzdem beachtet werden, denn da wir dynamische IP-Nummern benutzen, muß das Routing angepaßt werden, was genau über diese Skripte geschehen soll, die hier nicht vorhanden sind. <nidx>ipppd!Debugging</nidx> <nidx>ISDN!ipppd!Debugging</nidx> <item> Die Einwahl klappt nicht. Wenn die Einwahl nicht klappt, sieht man in <tt>/var/log/messages</tt> meist nur, daß die Gegenstelle aufgelegt hat. Um den Grund für das Problem zu ermitteln, braucht man mehr Meldungen vom LCP. Dazu trägt man in <tt>/etc/ppp/ioptions</tt> folgendes ein <tscreen><verb> # Definiere "debug", um möglichst viele Informationen # in /var/log/messages zu erhalten. debug # Definiere "+pwlog", um auch Paßworter in # /var/log/messages zu speichern #+pwlog </verb></tscreen> und startet den <tt/ipppd/ neu. Durch <tt/debug/ werden die LCP-Messages ausgegeben, durch <tt/+pwlog/ kann man sich zusätzlich das verschickte Paßwort angeben lassen - letzteres wird nur empfohlen, wenn ansonsten alles richtig scheint, denn wenn jemand fremdes Zugriff auf <tt>/var/log/messages</tt> bekäme, hätte man ein echtes Problem. Häufige Ursachen für Probleme sind: <itemize> <item> Username/Paßwort falsch: In diesem Fall wird etwas in dieser Art protokolliert: <tscreen><verb> ipppd[10314]: sent [0][PAP AuthReq id=0x1 user="kfr" password="falsch"] ipppd[10314]: rcvd [0][PAP AuthNak id=0x1msg=""] ipppd[10314]: Remote message: ipppd[10314]: PAP authentication failed </verb></tscreen> Richtig sollte es so aussehen: <tscreen><verb> ipppd[7840]: sent [0][PAP AuthReq id=0x1 user="kfr" password="isdnworkshop"] ipppd[7840]: rcvd [0][PAP AuthAck id=0x1msg=""] ipppd[7840]: Remote message: ipppd[7840]: bundle, he: 0 we: 0 </verb></tscreen> <item> LCP-Messages werden nicht beantwortet: Normalerweise werden LCP-Messages gesendet und empfangen, um das Handshaking durchzuführen (send, rcvd): <tscreen><verb> ipppd[10314]: sent [0][LCP ConfReq id=0x1 <mru 1524> <magic0x93ade903>] ipppd[10314]: rcvd [0][LCP ConfReq id=0x1 <mru 1524> <auth pap> <MPdiscr: 0x3 [ 00 c0 7b 70 d5 fa ]>] </verb></tscreen> Wenn die Gegenseite nicht antwortet, kann es sein, daß sie nicht schnell genug hochkommt (<tt/lcp-restart/ erhöhen) oder kein passender PPP-Daemon dort läuft. Ist dies nicht nur ein temporäres Problem, ist entweder die Nummer falsch, oder der ISP bietet tatsächlich kein syncPPP an. Im letzteren Fall muß man asyncPPP fahren, siehe: <tscreen><htmlurl url="http://www.suse.de/Support/sdb/ppp_async.html" name="http://www.suse.de/Support/sdb/ppp_async.html"> </tscreen> <item> Noch während der LCP-Messages legt die Gegenstelle auf. Hierbei sollte man am Protokoll erkennen, welche Optionen angefordert oder abgewiesen werden. Danach bleibt einem nur der mühsame Weg, diese Optionen zu setzen/deaktivieren, siehe Beispiel-Optionsfile und <tt/man ipppd/. <item> <tt/peer refused to authenticate/ Man hat selbst <tt/+pap/ oder <tt/+chap/ angegeben. Ein häufiges Mißverständnis: Diese Optionen geben an, daß man selber der Authentifizierungs-Server sein möchte, nicht, daß man PAP oder CHAP benutzen möchte; letzteres geschieht nur implizit durch die Angabe von <tt/user/, <tt/name/ und den Eintragungen in <tt/pap-secrets/ bzw. <tt/chap-secrets/. </itemize> <item>Die Einwahl klappt, weitere Tests: <itemize> <item> Zunächst vergleiche man die Ausgabe des <tt/ipppd/ mit der Ausgabe von <tt/ifconfig/. Die IP-Nummern müssen übereinstimmen und gegenüber der Grundeinstellung verändert sein. <item> Ist das Routing richtig gesetzt? Prüfe <tt/route -n/, siehe Abschnitt <ref id="DE-ISDN-HOWTO-routing" name="Routing">. Es muß eine Hostroute für den PtP-Partner gesetzt sein. <item> Versuche die Gegenstelle anzupingen, z.B. <tt/ping 193.102.150.13/. <item> Warte, bis die Verbindung automatisch abbricht und prüfe die Routingtabelle erneut. <item>Beobachte, ob wieder automatisch gewählt wird. </itemize> </enum> <sect1> Übung: syncPPP-Verbindung herstellen <label id="DE-ISDN-HOWTO-uebungPPP"> Ziel dieser Übung ist, ein PPP-Verbindung aufzubauen und zu testen (kein Routing). <enum> <item> Stelle eine Verbindung zu einem syncPPP-Server her. Wenn Du keinen anderen kennst, benutze den SuSE ISDN-Testrechner mit folgenden Daten: <itemize> <item> Protokoll: syncPPP <item> Telefon: +49 911 3206726 <item> Username: suse <item> Paßwort: linux <item> IP-Nummer Server: 192.168.0.1 <item> IP-Nummer Client: 192.168.0.99 </itemize> <item> Gehe die Checkliste durch und führe die dortigen Tests aus, siehe Abschnitt <ref id="DE-ISDN-HOWTO-syncPPPtrouble" name="syncPPP Troubleshooting">. <item> Prüfe die IP-Nummer(n) des Servers; wenn diese fest sind, ändere die Konfiguration entsprechend. </enum> <sect> Probleme mit dynamischen IP-Nummern <label id="DE-ISDN-HOWTO-dynIP"> <nidx>IP!dynamische Adresse</nidx> <nidx>ISDN!dynamische IP Nummern</nidx> Was sind dynamische IP-Nummern? IP-Nummern sind knapp und daher teuer. Die Provider versuchen deshalb, IP-Nummern einzusparen, indem sie sich nur so viele IP-Nummern zuweisen lassen, wie sich Kunden gleichzeitig bei Ihnen einwählen können. Die Anzahl der potenziellen Rechner, die sich einwählen könnten, ist aber höher; daher kann nicht mehr für jeden Rechner eine IP-Nummer fest zugeordnet werden. Der Trick besteht also darin, daß auf eine feste Zuordnung Rechner - IP-Nummer verzichtet wird und stattdessen bei jedem Verbindungsaufbau aus einem freien Pool eine ausgewählt wird, die dem Client mitgeteilt wird. Diese Technik wird nur beim PPP-Protokoll benutzt, nicht jedoch bei rawip. Diese Methode ist prima, wenn man nur eine Arbeitsstation hat und Session-orientiert arbeitet: Verbindung aufbauen, surfen, surfen, Mails austauschen, surfen und schließlich Verbindung abbauen. Will man nur ein klein wenig mehr (transparenten Internetzugriff), stellt sich schnell heraus, daß das Internetkonzept und dynamische IP-Nummern nicht zusammenpassen. Folgende Punkte sind für einen transparenten Internetzugriff wünschenswert: <enum> <item> <nidx>ISDN!Dial-on-Demand</nidx> <nidx>Dial-on-Demand</nidx> Dial-on-demand: es wird nicht manuell entschieden, daß eine Verbindung auf- oder abgebaut werden soll. Wer soll das in einem größeren Netz auch machen? Die Wählleitung wird automatisch aufgebaut, sobald Pakete vorhanden sind, die nicht im lokalen Netz zugestellt werden können. <item> Automatischer Verbindungsabbau, wenn eine gewisse Zeit keine Pakete über die Leitung gehen. <item> Pausen verursachen keine Kosten, wenn keine Daten über die Leitung gehen. Liest man z.B. eine etwas längere Web-Seite, braucht die Wählleitung nicht aufgebaut zu bleiben. <item> Verhindern, daß vergessen wird aufzulegen. Es blinkt und klackt ja nicht mehr bei ISDN :). </enum> Dieses läßt sich mit ISDN wunderbar lösen, vor allem deshalb, weil der Verbindungsaufbau im Gegensatz zu einem Modem sehr schnell geht. Tatsächlich dauert er nur wenige Sekunden. Folgende Punkte sind bei dynamischen IP-Nummern nicht realisierbar: <enum> <item> Server-Funktionalität: die IP-Nummer des Rechners ist für einen anderen Rechner im Internet nicht bestimmbar. Außerdem wird der Provider vermutlich nicht selbst eine Wählverbindung aufbauen wollen und können - zumindest nicht bei diesen kostengünstigen Verträgen. <item> Mails können nicht direkt zum eigentlichen Mailserver durchgestellt werden - denn an welche IP-Nummer sollten sie geschickt werden - sondern sie müssen bei einem Provider abgelegt werden, von dem sie vom IZG abgeholt werden. <item> Das <em/Offene-Sockets-Problem/: Halten einer logischen Verbindung über die Verbindungsunterbrechnung hinaus ist nicht möglich. Loggt man sich beispielsweise per Telnet bei seiner Arbeitsstelle ein, wird nach einer gewissen Zeit der Inaktivität aufgelegt. Drückt man nun eine Taste, wird die Verbindung automatisch wiederhergestellt, aber man bekommt eine andere IP-Nummer zugewiesen. Die Socket-Verbindung zwischen dem eigenen Rechner und dem Arbeitgeber ist damit ungültig geworden, da für einen Socket u.a. Quell- und Ziel-IP-Nummern wichtig sind. Die gleiche Problematik stellt sich bei WWW oder FTP-Verbindungen, die unterbrochen werden. </enum> Sehr wohl aber ist man genauso wie sonst auch nicht gegen Angriffe aus dem Internet geschützt. Ein Hacker kann nur nicht voraussagen, welchen Rechner er angreift; er sucht sich halt nur zufällig eine IP-Nummer aus oder belauscht eine Verbindung und kann den Rechner angreifen. Der Vorteil liegt allerdings darin, daß der Hacker weniger Zeit hat, da die Verbindung abgebaut und mit einer neuen IP-Nummer aufgebaut wird, wobei zwischen den beiden IP-Nummern erstmal kein Zusammenhang zu erkennen ist. Als wirksamer Schutz reicht dies aber nicht aus. <nidx>ISDN!Offene Sockets Problem</nidx> Aus dem <em/Offene-Sockets-Problem/ ergeben sich zwei Punkte, die bei einem IZG mit dynamischen IP-Nummern beachtet werden müssen: <enum> <item> Anfragen laufen in's Leere: Ein Web-Browser hat ein Socket zum Web- oder Proxy-Server offen, nach dem Reconnect ist dieser ungültig, aber der Browser hat keine Möglichkeit, dies zu erkennen. Abhilfe schafft es hier, auf <em/Abbruch/ und <em/Reload/ zu drücken. <item> Die Sockets bleiben auch nach Beendigung des Client-Programms offen, es werden immer wieder Pakete darüber geschickt, bis ein Timeout von etwa 20 Minuten abläuft. In dieser Zeit wird <em/ständig eine Verbindung aufgebaut/ bzw. bleibt bestehen. </enum> Abhilfe schafft für dieses Probem, daß man dem Client nicht erlaubt, direkt in das Internet eine Verbindung aufzubauen (über Masquerading), sondern nur über Proxies, siehe Abschnitt <ref id="DE-ISDN-HOWTO-squid" name="Squid">. Aber auch diese Methode ist nicht zuverlässig. <sect1> Der RST-Provoking Mode <label id="DE-ISDN-HOWTO-rstPatch"> <nidx>ISDN!RST-Provoking Mode</nidx> Wirkliche Abhilfe schafft nur die Aktivierung des <em/RST-Provoking Mode/. Dabei wird bei dem Paket die Quell-IP-Nummer gegen die jetzt aktuelle dynamische IP-Nummer ausgetauscht, was bewirkt, daß beide Seiten diesen Socket schließen. Dieser Modus ist leider noch nicht in den offiziellen Kernel gekommen. Den Patch von Erik Corry findet man hier: <tscreen><htmlurl url="http://www.image.dk/˜ehcorry/linux/" name="http://www.image.dk/˜ehcorry/linux/"></tscreen> Er ist für Kernel der Version bis 2.0.33 passend, ab Version 2.0.34 wird er vermutlich im Standardkernel sein. Im Standardkernel von SuSE Linux 5.2 und im Quellpaket <tt/lx_suse/ ist dieser Patch schon enthalten. Zur Aktivierung gibt man dieses Kommando ein: <tscreen><verb> echo 7 > /proc/sys/net/ipv4/ip_dynaddr </verb></tscreen> Für den Quiet-Mode würde man statt dessen <tt/5/ verwenden. Bei Erfolg sieht man in <tt>/var/log/messages</tt> Meldungen der folgenden Art: <tscreen><verb> ip_rewrite_addrs(): shifting saddr from 1.1.1.1 to 149.228.142.50 (state 2) </verb></tscreen> Um den Mode bei SuSE zu aktivieren, trägt man in <tt>/sbin/init.d/i4l_hardware</tt> vor dem Start des <tt/isdnlog/ folgende Zeilen ein: <tscreen><verb> test -z "$I4L_DYNIP" || echo 7 > /proc/sys/net/ipv4/ip_dynaddr </verb></tscreen>  Außerdem muß die Datei <tt>/etc/rc.config</tt> so geändert werden: <tscreen><verb> I4L_DYNIP="yes" </verb></tscreen> <sect1> Welche IP-Nummer setze ich denn eigentlich? <label id="DE-ISDN-HOWTO-ipDynWelche"> Der Provider stellt nur dynamische IP-Nummern zur Verfügung, während der Konfiguration von i4l werde ich aber nach IP-Nummern gefragt - welche IP-Nummer soll ich denn da angeben? i4l arbeitet mit einer transparenten Netzanbindung, d.h. logisch gesehen ist die Verbindung immer aktiv, auch wenn noch gar nicht gewählt wurde und keine dynamischen IP-Nummern ermittelt werden konnten. Um dieses Pseudo-Netzwerk zu konfigurieren, müssen aber zwangsläufig IP-Nummern angegeben werden. Es empfiehlt sich daher, eine Pseudo-IP-Nummer zu benutzen, z.B. dieselbe, die man auch für seine Ethernetanbindung benutzt. Das ist möglich, da die PPP-Verbindung als <tt/pointopoint/-Verbindung (beim <tt/ifconfig/) konfiguriert wurde. Dies ist ein spezieller Modus, durch den der Kernel weiß, daß hier nur eine Verbindung zwischen zwei Punkten stattfindet. Warum Point-To-Point (PtP) als <bf/pointopoint/ angegeben wird, weiß ich auch nicht. Um keinen Konflikt mit offiziellen IP-Nummern zu provozieren, sollte man eine aus dem privaten Bereich wählen, z.B. 192.168.1.1. Falls man bei T-Online angeschlossen ist oder dies plant: Benutze nicht 192.168.0.*. Darüber werden zum Teil interne Dienste wie CEPT abgehandelt. <sect> Routing <label id="DE-ISDN-HOWTO-routing"> <nidx>ISDN!Routing</nidx> <nidx>Routing</nidx> <nidx>Netzwerk!Routing</nidx>  <sect1> Was ist Routing? <label id="DE-ISDN-HOWTO-routingWas"> In einem lokalen Netzwerk ist das Leben einfach: wenn ein TCP/IP-Paket zu einem anderen Rechner gesendet werden soll, wird dieses auf dem Ethernet verschickt. Ist der Rechner an das Internet oder an ein größeres Netzwerk (WAN) angeschlossen, ist die Aufgabe schon etwas schwieriger, denn wenn der Ziel-Rechner bzw. die Ziel-IP-Nummer nicht im lokalen Ethernet erreichbar ist, so muß dem Kernel gesagt werden, daß alle nicht lokal zustellbaren Pakete freundlicherweise von einem Gatewayrechner weitergeleitet werden. Komplizierter ist es, wenn der betreffende Rechner selbst ein Gatewayrechner ist und mehrere Netzdevices wie Ethernetkarten, Modems, ISDN-Karten etc. zur Verfügung hat und jeweils über diese Devices unterschiedliche Rechner/Netze erreichbar sind. Das ist die Aufgabe vom Routing: <quote> Für jede IP-Nummer muß definiert werden, auf welchem Weg (Route) diese erreicht werden kann. </quote> Man unterscheidet folgende Typen:  <descrip> <tag/Netzrouten/ Hier wird angeben, wie ein komplettes Netz erreichbar ist. Als <em/Beispiel 1/ wollen wir von einem lokalen Ethernet ausgehen, wobei das Netz 192.168.1.0 mit der Netmask 255.255.255.0 über das Device <tt/eth0/ erreichbar ist. <tag/Hostrouten/ Man definiert, wie ein einzelner Rechner erreichbar ist. So ist der Rechner 192.168.0.1 in <em/Beispiel 2/ mittels einer syncPPP Verbindung über das Device <tt/ippp0/ erreichbar. <tag/Default-Route/ <nidx>Default Route</nidx> <nidx>Netzwerk!Default Route</nidx> Im Internet gibt es recht viele IP-Nummern - es ist daher mühsam und langweilig, für alle einzelnen IP-Nummern oder Netze einzelne Routing-Einträge zu machen. Daher gibt es die Möglichkeit, zu sagen, daß alle IP-Nummern, für die keine spezielle Regel vorhanden ist, an den Rechner mit der IP-Nummer 192.168.0.1 geschickt werden sollen. Dieses ist <em/Beispiel 3/. Wobei beachtet werden sollte, daß es im allgemeinen keinen Sinn macht, mehr als eine Default-Route anzugeben. </descrip> <sect1> Wie konfiguriert man das Routing? <label id="DE-ISDN-HOWTO-routingWie"> Die Routingeinträge werden dem Kernel zur Laufzeit mit dem Kommando <tt/route/ mitgeteilt und wieder entzogen. <sect2>SuSE Methode <nidx>/etc/route.conf</nidx> <nidx>/sbin/init.d/route</nidx> <nidx>Routing!/etc/route.conf</nidx> <nidx>Routing!/sbin/init.d/route</nidx> <nidx>Netzwerk!Routing!/etc/route.conf</nidx> <nidx>Netzwerk!Routing!/sbin/init.d/route</nidx> Bei SuSE können die Routingeinträge fest in die Datei <tt>/etc/route.conf</tt> eingetragen werden, die beim Booten oder durch einen Runlevelwechsel vom Skript <tt>/sbin/init.d/route</tt> ausgewertet wird. Die Einträge für die obigen Beispiele sehen so aus: <tscreen><verb> # Beispiel 1: 192.168.1.0 0.0.0.0 255.255.255.0 eth0 # Beispiel 2: 192.168.0.1 0.0.0.0 255.255.255.255 ippp0 # Beispiel 3: default 192.168.0.1 </verb></tscreen> Die <em/1. Spalte/ gibt das Ziel an, also das Netz, die IP-Nummer, oder das Schlüsselwort <tt/default/. In der <em/3. Spalte/ steht, falls notwendig, die zugehörige Netmask. Die <em/2. Spalte/ legt den Gatewayrechner fest, an den die Anfragen geschickt werden sollen. In der <em/4. Spalte/ steht das zu verwendene Device. Hier sieht man auch in der 3. Zeile, daß bei Verwendung eines Gatewayrechners die Angabe des Devices nicht nötig ist, da sie selbständig ermittelt wird. Allerdings muß in diesem Beispiel die Hostroute auf 192.168.0.1 definiert sein, bevor man sie zum Setzen der Defaultroute nutzen kann. Die Reihenfolge ist wichtig. Um die Routingtabelle manuell zu setzen oder zu löschen, gibt man folgendes ein: <tscreen><verb> /sbin/init.d/route start /sbin/init.d/route stop </verb></tscreen> <sect2>Manuelle Methode <nidx>Routing!route</nidx> <nidx>Netzwerk!Routing!route</nidx> Natürlich kann man die einzelnen Routing-Einträge auch manuell mit dem <tt/route/ Befehl setzen: <tscreen><verb> # Beispiel 1: route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0 # Beispiel 2: route add -host 192.168.0.1 dev ippp0 # Beispiel 3: route add default gw 192.168.0.1 </verb></tscreen> Weitere Informationen zu <tt/route/ finden sich in <tt/man route/. <sect2>Löschen von Routing-Einträgen Routing-Einträge können zum einem direkt gelöscht werden, sie werden aber auch automatisch gelöscht, wenn das zugrundeliegende Netzdevice gelöscht oder umkonfiguriert wird. Dies hat in diesem Zusammenhang einen unerwünschten Nebeneffekt. Der <tt/ipppd/ baut die Verbindung auf und bekommt eine neue IP-Nummer vom Server zugewiesen, wobei selbständig eine neue Hostroute auf die IP-Nummer des Gegners eingerichtet wird. Allerdings wird eine eventuell vorhandene Defaultroute über dieses Device gelöscht. Durch die PPP-Option <tt/defaultroute/ könnte man sich automatisch wieder eine Defaultroute anlegen lassen. Allerdings ist diese Methode nicht sehr flexibel, vielleicht will man ja doch keine Defaultroute, und man hätte hiermit keine Möglichkeit zu steuern, wie sich beim Verbindungsabbau verhalten werden soll. Daher wird beim Verbindungauf- und abbau jeweils ein Skript gestartet, siehe Abschnitt <ref id="DE-ISDN-HOWTO-ipup" name="Kontrollieren der Routingtabelle beim Verbindungsauf- und abbau">. <sect1>Kontrollieren der Routingtabelle beim Verbindungsauf- und abbau <label id="DE-ISDN-HOWTO-ipup"> <sect2>Die Skripte ip-up/ip-down <nidx>ipppd!/etc/ppp/ip-up</nidx> <nidx>ipppd!/etc/ppp/ip-down</nidx> <nidx>/etc/ppp/ip-up</nidx> <nidx>/etc/ppp/ip-down</nidx> <nidx>ISDN!ipppd!/etc/ppp/ip-up</nidx> <nidx>ISDN!ipppd!/etc/ppp/ip-down</nidx> <nidx>PPP!/etc/ppp/ip-up</nidx> <nidx>PPP!/etc/ppp/ip-down</nidx> Der <tt/ipppd/ bietet die einfache Möglichkeit, beim Verbindungsaufbau das Skript <tt>/etc/ppp/ip-up</tt> und beim Abbau <tt>/etc/ppp/ip-down</tt> zu starten, wobei jeweils die folgenden Parameter über den neuen Zustand übergeben werden: <itemize> <item> <tt/$1/: Interface <item> <tt/$2/: Device <item> <tt/$3/: Geschwindigkeit (nur aus Kompatibilitätsgründen) <item> <tt/$4/: lokale IP-Nummer <item> <tt/$5/: IP-Nummer des Gegners </itemize> Durch Installation geeigneter Skripte kann also die Default-Route neu gesetzt werden. Die Skripte könnten jeweils so aussehen: <tscreen><verb> #!/bin/sh /sbin/route add default gw $5 </verb></tscreen> Bei SuSE gibt es ein Skript <tt>/etc/ppp/ip-up</tt>, welches für den <em/Hausgebrauch/ ausreicht. Die Routen werden aufgrund der Konfigurationsdateien gesetzt und wieder hergestellt. Weitere Kommandos können vom Administrator eingefügt werden, um z.B. E-Mails zu verschicken. Das Skript <tt/ip-down/ ist ein symbolischer Link auf <tt/ip-up/, so daß man nur eine Datei zu verwalten hat. <sect2>Was machen die Skripte ip-up/ip-down? Es wird geprüft, ob das Interface <tt/ipppx/ ist; sollte also bei Analog-PPP nicht stören. Wer dort etwas eintragen will, sollte die Stelle leicht finden. Wenn das Skript nach dem Verbindungsaufbau als <tt/ip-up/ aufgerufen wird, wird eine Default-Route auf die gerade zugewiesene IP-Nummer gesetzt. Wenn das Skript nach dem Abbau der Verbindung als <tt/ip-down/ aufgerufen wird, dann wird das Interface gelöscht. Das Interface wird wie in <tt>/etc/rc.config</tt> wieder neu angelegt, es wird also wieder auf die ursprünglichen IP-Nummer gesetzt. Nach den Angaben in <tt>/etc/route.conf</tt> werden die Routingeinträge für dieses Device neu eingerichtet. Somit ist dial-on-demand wieder möglich. Ist dort keine Default-Route angegeben, wird auch keine gesetzt. Falls dial-on-demand nicht gewünscht wird, so darf in der Datei <tt>/etc/route.conf</tt> bzw. in YaST keine Default-Route (Default-Gateway) angegeben werden. Dadurch existiert nur während einer Verbindung eine Default-Route; diese wird beim Verbindungsabbau gelöcht und nicht neu angelegt. Die Verbindung kann dann manuell oder durch ein Skript mit dem Kommando <tscreen><verb>isdnctrl dial ippp0</verb></tscreen> aufgebaut werden. Alternativ geht dieses auch durch das manuelle Setzen der Default-Route. Dadurch kann z.B. auch erreicht werden, daß mit verschiedenen Providern gearbeitet wird. In dem Fall muß man ja sowieso entscheiden, welche Verbindung nun hochgefahren werden soll, z.B.: <tscreen><verb>isdnctrl dial ippp17</verb></tscreen> <sect1>Übung: Kontrolliere die IP-Nummer und die Routing-Tabelle <label id="DE-ISDN-HOWTO-uebungRoute"> Folgende Übung sollte jetzt durchlaufen werden: <enum> <item>Überwache, wie in Abschnitt <ref id="DE-ISDN-HOWTO-lessVLM" name="Betrachte messages"> beschrieben, die Datei <tt>/var/log/messages</tt>. <item>Prüfe <tt/ip-up/ und <tt/ip-down/: <tscreen><verb> # ls -la /etc/ppp/ip-* lrwxrwxrwx 1 root root 5 Mar 20 10:16 /etc/ppp/ip-down -> ip-up -rwxr-xr-x 1 root root 1813 Mar 24 23:03 /etc/ppp/ip-up </verb></tscreen> Siehe auch Abschnitt <ref id="DE-ISDN-HOWTO-installation" name="Installation">. <item>Prüfe die IP-Nummern und die Routingtabelle <em/vor/ einer Verbindung <tscreen><verb> # ifconfig ippp0 ippp0 Link encap:Point-Point Protocol inet addr:192.168.0.99 P-t-P:192.168.0.1 Mask:255.0.0.0 UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 TX packets:0 errors:0 dropped:0 overruns:0 </verb></tscreen> <tscreen><verb> # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 2 lo 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 ippp0 </verb></tscreen> <item>Nun sollte man eine Verbindung initiieren. Dazu kann man entweder ein Paket z.B. mit <tt>ping 141.1.1.1</tt> verschicken oder das Wählen direkt mit dem Befehl <tscreen><verb>isdnctrl dial ippp0</verb></tscreen> verlangen. Als Beispiel bekommen wir die IP-Nummer 1.2.3.4 zugewiesen, der Gegner habe die IP-Nummer 5.6.7.8 . <item>Prüfe die IP-Nummer und die Routingtabelle <em/während/ einer Verbindung <tscreen><verb> # ifconfig ippp0 ippp0 Link encap:Point-Point Protocol inet addr:1.2.3.4 P-t-P:5.6.7.8 Mask:255.0.0.0 UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 TX packets:3 errors:0 dropped:0 overruns:0 </verb></tscreen> <tscreen><verb> # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 5.6.7.8 0.0.0.0 255.255.255.255 UH 0 0 0 ippp0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 2 lo 0.0.0.0 5.6.7.8 0.0.0.0 UG 0 0 0 ippp0 </verb></tscreen> <item> Wir gehen in die große weite Welt: Bestimme eine existierende IP-Nummer; die einzige, die ich mir merken kann, ist die des DNS-Server von ECRC: <tscreen><verb>traceroute -n 141.1.1.1</verb></tscreen> Man beachte, daß wir noch keinen DNS-Servive benutzen können, daher <tt/-n/. <item>Jetzt wartet man auf den Timeout, bis aufgelegt wird, und betrachtet die Datei <tt>/var/log/messages</tt>, z.B.: <tscreen><verb> kernel: isdn_net: local hangup ippp0 kernel: ippp0: Chargesum is 0 isdnlog: Apr 03 09:20:49 tei 70 calling Eunet-N with KfrI I Normal call clearing (User) ipppd[135]: Modem hangup ipppd[135]: Connection terminated. ipppd[135]: taking down PHASE_DEAD link 0, linkunit: 0 ipppd[135]: sent [0][LCP TermReq id=0x2 6c 69 6e 6b 20 63 6 c 6f 73 65 64] ipppd[135]: LCP is down ipppd[135]: link 0 closed , linkunit: 0 ipppd[135]: reinit_unit: 0 ipppd[135]: Connect[0]: /dev/ippp0, fd: 6 </verb></tscreen> <item>IP-Nummern und Routing prüfen: sie müssen jetzt wieder genauso gesetzt sein, wie <em/vor/ dem Verbindungsaufbau. </enum> <sect> IP-Nummern-Auflösung (DNS) <label id="DE-ISDN-HOWTO-ipnummern"> <nidx>Netzwerk!Name Resolver</nidx> <nidx>Netzwerk!DNS</nidx> <nidx>Name Resolver!Grundlagen</nidx> <nidx>DNS!Grundlagen</nidx> Bekanntlich werden Rechner im Internet über die IP-Nummern angesprochen. Niemand möchte sich aber die IP-Nummern direkt merken, praktischer ist es, Namen zu verwenden, z.B. <tt/www.franken.de/. Aber nicht nur für die bessere Merkbarkeit sind diese Namen wichtig, sondern sie dienen auch als Variable, deren Inhalt sich verändern kann. Wenn ein wichtiger Server z.B. durch einen Umzug oder Providerwechsel eine neue IP-Nummer bekommt, so wird der Name einfach in die neue IP-Nummer aufgelöst. Genauso wichtig wie die Auflösung von Namen in IP-Nummern, das wird gerne vergessen, ist der umgekehrte Fall, also IP-Nummer in einen Rechnernamen auflösen. Diese umgekehrte Auflösung ist oft diejenige, die durch ungewollte Verbindungen Probleme im lokalen Netzwerk macht, denn viele Services nutzen diese Möglichkeit zur Verifikation bei einer eingehenden Verbindung, denn in den Regeln, die festlegen, wer was machen darf, werden meist Rechnernamen anstatt IP-Nummern verwendet. Über das Netzwerk ist aber zunächst nur die IP-Nummer sichtbar und muß also in einen Namen aufgelöst werden.  Es gibt zwei wichtige Methode zur Namensauflösung, die gleichzeitig benutzt werden können und müssen: <sect1>Feste IP-Nummern-Auflösung über /etc/hosts <label id="DE-ISDN-HOWTO-etcHosts"> <nidx>Name Resolver!/etc/hosts</nidx> <nidx>/etc/hosts</nidx> <nidx>DNS!/etc/hosts</nidx> Alle bekannten IP-Nummern werden fest in einer Datei gespeichert, die der Administrator manuell pflegen oder von anderen Rechnern kopieren muß. In der Datei <tt>/etc/hosts</tt> werden alle Rechnernamen und IP-Nummern fest eingetragen. Existieren z.B. in der Domain <tt/isdnworkshop.de/ die Rechner Asterix (192.168.1.1) und Obelix (192.168.1.2), so sieht die Datei folgendermaßen aus: <tscreen><verb> # IP FQN Kurzname 192.168.1.1 Asterix.isdnworkshop.de Asterix 192.168.1.2 Obelix.isdnworkshop.de Obelix </verb></tscreen> <sect1>Dynamische IP-Nummern-Auflösung mit DNS <label id="DE-ISDN-HOWTO-dns"> Es wird schnell ersichtlich, daß eine feste Auflösung über eine Datei, die ständig aktuell auf jedem Rechner installiert sein muß, im Internet nicht funktionieren würde. Die feste Auflösung kann nur in einem übersichtlichen lokalen Netz benutzt werden. DNS (Domain Name Service) dient ebenfalls zum Auflösen von Rechnernamen in eine IP-Nummer und umgekehrt. Der Unterschied liegt darin, daß es ein Internet-Service ist, den man auf Anforderung abfragen kann. Es gibt sehr viele DNS-Server im Internet, wobei es eine hierarchische Struktur gibt, die sich an den Domainnamen orientiert. Jeder DNS-Server ist für eine Subdomain zuständig. Beim Abfragen »hangelt« man sich von den Root-Servern herunter, bis man den Server gefunden hat, der die Anfrage tatsächlich beantworten kann. Das Einrichten eines DNS-Servers wird an anderer Stelle beschrieben, wie z.B. im <em/DNS HOWTO/. Für unsere Zwecke reicht es, zu wissen, wie der Service aktiviert wird und wo man einstellt, welches der Nameserver ist. <sect1> Konfiguration der Namensauflösung <label id="DE-ISDN-HOWTO-resolv"> Es ist wie gesagt durchaus sinnvoll, beide Methoden der Namensauflösung zu kombinieren. Wichtig ist hier, daß auch ohne Internetverbindung lokal gearbeitet werden kann. Üblicherweise werden die lokalen Rechner oder mindestens der eigene über die <tt>/etc/hosts</tt> aufgelöst. Alle nicht bekannten Anfragen werden dann über den Nameserver beim ISP aufgelöst. Um die Namensauflösung muß sich eine Applikation nicht selber kümmern, sondern dieses wird durch <tt/libc/-Funktionen wie z.B. <tt/gethostbyname()/ erledigt. Diese <tt/libc/-Funktionen gilt es also zu konfigurieren. <sect2>Manuelle Konfiguration <nidx>Name Resolver!/etc/host.conf</nidx> <nidx>DNS!/etc/host.conf</nidx> <nidx>/etc/host.conf</nidx> <nidx>Name Resolver!/etc/resolv.conf</nidx> <nidx>DNS!/etc/resolv.conf</nidx> <nidx>/etc/resolv.conf</nidx> Über die Datei <tt>/etc/host.conf</tt> wird zunächst gesteuert, welche Methoden überhaupt benutzt werden sollen und auch in welcher <em/Reihenfolge/ dies geschehen soll. Folgende <tt>/etc/host.conf</tt> Datei: <tscreen><verb> order hosts bind multi on </verb></tscreen> gibt an, daß zunächst in der <tt>/etc/hosts</tt> gesucht werden soll. Falls dies nicht erfolgreich ist, soll der DNS-Server (<tt/bind/) bemüht werden. Wenn ein Nameserver benutzt werden soll, ist noch eine zweite Datei <tt>/etc/resolv.conf</tt> zu konfigurieren: <tscreen><verb> search isdnworkshop.de suse.de nameserver 192.168.200.7.1 </verb></tscreen> Die zweite Zeile sollte selbsterklärend sein; in der ersten wird eine sogenannte Searchlist angegeben. Diese ist nur dann von Bedeutung, wenn ein Rechnername ohne vollständige Domain aufgelöst werden soll. Wird z.B. nach einem Rechner <tt/Goedel/ gesucht, den der Nameserver nicht kennt, dann wird zunächst <tt/isdnworkshop.de/ angehängt und damit versucht, einen Rechner <tt/Goedel.isdnworkshop.de/ zu finden; ist auch das nicht erfolgreich, wird nach <tt/Goedel.suse.de/ gesucht. Änderungen an diesen beiden Dateien sind sofort wirksam. <sect2> Namensauflösung bei SuSE <label id="DE-ISDN-HOWTO-dnsSuse"> <nidx>Name Resolver!/etc/rc.config</nidx> <nidx>/etc/rc.config</nidx> <nidx>DNS!/etc/rc.config</nidx> Bei der S.u.S.E Distribution müssen die Variablen in <tt>/etc/rc.config</tt> gesetzt werden. Für obiges Beispiel würde das so aussehen: <tscreen><verb> SEARCHLIST="isdnworkshop.de suse.de" NAMESERVER="192.168.200.7.1" </verb></tscreen> <sect1> Probleme mit der Namensauflösung <label id="DE-ISDN-HOWTO-resolvTrouble"> <nidx>ISDN!Probleme!DNS</nidx> <nidx>Name Resolver!Probleme</nidx> <nidx>DNS!Probleme</nidx> Probleme bei der Namensauflösung erkennt man schnell an seiner Telefonrechnung ;-(. Macht ein Benutzer z.B. im lokalen Netz ein Telnet von der IP-Nummer 192.168.1.2 auf den IZG <tt/192.168.1.1/, so prüft der Server vor dem eigentlichen Start des Telnet-Daemons, welche IP-Nummer reinkommt (Stichwort TCP-Wrapper). Da diese Nummer nicht aufgelöst werden kann, wird der Nameserver befragt; dieser befindet sich beim ISP, so daß automatisch eine Verbindung aufgebaut wird. Das Ergebnis ist, daß Telnet nicht nur etwa eine Minute bis zum Login braucht, der DNS-Server kann diese private IP-Nummer nicht auflösen, sondern dieses auch noch 12 Pfennig kostet. Bei Problemen sollte man sich an diese Checkliste halten: <label id="DE-ISDN-HOWTO-resolvCheck"> <enum> <item> Ist die eigene IP-Nummer in der <tt>/etc/hosts</tt> eingetragen? <item> Sind alle Rechner des lokalen Netzwerks in der <tt>/etc/hosts</tt> eingetragen? <item> Ist das Paket <tt/bind/ installiert? <tscreen><verb> $ rpm -q bind bind-4.9.6-5 </verb></tscreen> <item> Kann der Nameserver angesprochen werden? <nidx>Name Resolver!nslookup</nidx> <nidx>DNS!nslookup</nidx> <nidx>nslookup</nidx> <tscreen><verb> $ nslookup www.suse.de Server: Plato.suse.de Address: 192.168.100.1 Name: Turing.suse.de Addresses: 195.125.217.200, 192.168.102.3 Aliases: www.suse.de </verb></tscreen> <item> Einen beliebigen anderen Nameserver kann man direkt testen, z.B.: <tscreen><verb> $ nslookup www.suse.de 141.1.1.1 Server: ecrc.de Address: 141.1.1.1 Non-authoritative answer: Name: Turing.suse.de Address: 195.125.217.200 Aliases: www.suse.de </verb></tscreen> </enum> Eventuell sind auch die nachfolgende Tips hilfreich: <enum> <item> Alle IP-Nummern und Namen des gesamten Subnetzes sollten in die Datei <tt>/etc/hosts</tt> eingetragen werden, auch wenn sie <em/noch/ nicht verwendet werden. Beispiel: <tscreen><verb> 192.168.1.1 Server.isdnworkshop.de Server 192.168.1.2 Client.isdnworkshop.de Client 192.168.1.3 Dummy.isdnworkshop.de Dummy 192.168.1.4 Dummy.isdnworkshop.de Dummy 192.168.1.5 Dummy.isdnworkshop.de Dummy </verb></tscreen> <item> Es kann ein eigener DNS-Proxy-Servers eingerichtet werden. Neben der schnelleren Auflösung werden auch die fehlerhaften Anfragen gecacht, so daß nicht so häufig eine Verbindung aufgebaut wird, siehe Abschnitt <ref id="DE-ISDN-HOWTO-dnsCache" name="DNS-Cache">. </enum> <sect> Dial-on-Demand kontrollieren <label id="DE-ISDN-HOWTO-dodCtrl"> <nidx>Dial-on-Demand</nidx> <nidx>ISDN!Dial-on-Demand</nidx> Während der Konfiguration sollte man unbedingt das System überwachen und feststellen, wann und warum eine Verbindung aufgebaut wird. Ansonsten kann es schnell zu unerwünschten Telefonrechnungen kommen. Man kann sich aber sicher sein, daß niemals grundlos eine Verbindung aufgebaut oder offengehalten wird. Die geschieht immer nur dann, wenn auch tatsächlich Pakete über die Leitung verschickt werden. Es gilt also insbesondere die beteiligten Serverdienste auf dem Rechner zu überprüfen, ob Sie richtig konfiguriert wurden, und ggf. die Ursachen der Verbindung aufzuspüren. <sect1> Verbindungen überwachen <nidx>imon</nidx> <nidx>xisdnload</nidx> <nidx>ISDN!Statusmonitor!imon</nidx> <nidx>ISDN!Statusmonitor!xisdnload</nidx> <nidx>ISDN!Statusmonitor!isdnmon</nidx> <nidx>ISDN!Statusmonitor!isdnmonp</nidx> Es gibt eine Vielzahl von ISDN-Statusmonitoren; der wichtigste ist <tt/imon/. Dieses Konsolenprogramm läßt sich in jeder Umgebung einsetzen, reagiert prompt und verschlingt keine Systemressourcen. Weitere Programme sind: <tt/xisdnload/ (zeigt auch den Durchsatz), <tt/isdnmon/ und <tt/isdnmonp/. Alle Monitore zeigen die Telefonnummer und die Art der Verbindung, also ob es eine ein- oder ausgehende Verbindung ist, an. <sect1> Grund der Verbindung feststellen <label id="DE-ISDN-HOWTO-verbose"> <itemize> <item> Durch den Befehl <tscreen><verb>isdnctrl verbose 3</verb></tscreen> wird das i4l-Subsystem veranlasst, bei jedem Verbindungsaufbau eine Meldung in <tt>/var/log/messages</tt> zu schreiben, anhand derer man erkennen kann, zwischen welchen IP-Nummern und Port-Nummern ein Paket verschickt wird. Dieses Beispiel ist eine Anfrage an den WWW-Server <tt/www.suse.com/ mit dem Alias <tt/goldengate/: <tscreen><verb> Apr 10 21:05:06 glen kernel: OPEN: 1.1.1.1 -> 209.0.51.1 TCP, port: 2224 -> 80 </verb></tscreen> Ein Nachteil ist jedoch, daß man nicht überprüfen kann, warum eine Verbindung nicht abgebaut wird. Weitere Informationen sind im Abschnitt <ref id="DE-ISDN-HOWTO-isdnDial" name="SDB: ungewollte Verbindungen"> zu finden. <item> <nidx>tcpdump</nidx> <nidx>Netzwerk!tcpdump</nidx> <nidx>Paketsniffer</nidx> <nidx>Netzwerk!Paketsniffer</nidx> <tt/tcpdump/ ist ein Paketsniffer, der alle Pakete auf einem Netzdevice mitschneidet. Die Ausgabe des Programmes ist leider nicht sehr menschenfreundlich, aber zumindest die verwendeten IP-Nummern und Port-Nummern werden sichtbar gemacht. Dieses Beispiel ist eine Anfrage an den WWW-Server <tt/www.suse.com/: <tscreen><verb> # tcpdump -i ippp0 tcpdump: listening on ippp0 21:05:39.382188 pec-30.au1.n.uunet.de.2230 > goldengate.suse.com.www: S 1384488919:1384488919(0) win 512 <mss 1460> 21:05:39.642188 goldengate.suse.com.www > pec-30.au1.n.uunet.de.2230: S 3326089293:3326089293(0) ack 1384488920 win 32736 <mss 1460> 21:05:39.642188 pec-30.au1.n.uunet.de.2230 > goldengate.suse.com.www: . ack 1 win 32120 (DF) </verb></tscreen> Nachteilig ist, daß bei Verwendung dynamischer IP-Nummern durch den PPP-Daemon das Interface <tt/ippp0/ neu angelegt wird. <tt/tcpdump/ zeigt nach dem Neuanlegen keine Daten mehr an und muß abgebrochen und neu gestartet werden. </itemize> <sect1> Verbindungen auswerten <label id="DE-ISDN-HOWTO-isdnrep"> <nidx>ISDN!isdnlog</nidx> <nidx>ISDN!isdnrep</nidx> Das Programm <tt/isdnlog/ läuft im Hintergrund und horcht ständig auf dem D-Kanal mit. Alle Aktivitäten werden zum einen in <tt>/var/log/messages</tt> geloggt und zum anderen in die Log-Datei <tt>/var/log/isdn.log</tt> protokolliert. Mit dem Tool <tt/isdnrep/ kann man diese Datei wiederum zu einem späteren Zeitpunkt aufrufen. Es gibt eine Vielzahl von Parametern, hier dir wichtigsten: <itemize> <item> <tt/isdnrep/: alle Verbindungen des heutigen Tages <item> <tt/isdnrep -a/: alle protokollierten Verbindungen <item> <tt>isdnrep -t01/04/98-03/04/98</tt>: alle Verbindungen vom 1. bis 3. April 1998 </itemize> Mehr Infos sind in der Datei <tscreen><htmlurl url="file:/usr/doc/packages/i4l/isdnlog/README" name="/usr/doc/packages/i4l/isdnlog/README"></tscreen> bzw. im Quellpaket zu finden. <sect1> Dial-On-Demand an- und ausstellen <label id="DE-ISDN-HOWTO-dodOnOff"> Das i4l-Subsystem ist, wenn es denn einmal gestartet wurde, nicht dafür vorgesehen, daß Verbindungen nur manuell gestartet werden. Man könnte das Konzept bei i4l also auch so formulieren: wenn es gestartet ist, besteht ständig eine Verbindung, die aber automatisch gekappt wird, wenn nichts passiert. Wer es dennoch manuell machen will, der entferne einfach die Default-Route. In diesen Fall wird nur noch dann eine Verbindung aufgebaut, wenn ein IP-Paket an die direkte Gegenstelle geschickt wird, was i.a. nicht vorkommt, da diese Gegenstelle keine Internetdienste anbietet und daher von keinem Client angesprochen wird. Als endgültigen Schritt kann man auch das komplette Interface (<tt/ippp0/) herunterfahren; dann können grundsätzlich keine Verbindungen aufgebaut werden. <sect1> Tips für das SuSE System <label id="DE-ISDN-HOWTO-dodSuse"> <nidx>ISDN!/sbin/init.d/i4l</nidx> <nidx>/sbin/init.d/i4l</nidx> <nidx>ISDN!Wählen</nidx> <nidx>ISDN!Auflegen</nidx> Man kann die Runlevel-Skripte natürlich auch manuell benutzen: <tscreen><verb> /sbin/init.d/i4l stop </verb></tscreen> Dieses fährt alle ISDN-Netzdevices runter. <tscreen><verb> /sbin/init.d/i4l start /sbin/init.d/route </verb></tscreen> Und dieses legt sie wieder an und setzt die Routen. Wer bei einer syncPPP-Verbindung die Verbindung nur manuell starten möchte, kann eine Eigenschaft des Skriptes <tt>/etc/ppp/ip-up</tt> ab SuSE 5.2 ausnutzen. Dieses legt beim Verbindungsaufbau eine Default-Route auf die neu erkannte PtP-Adresse. Beim Verbindungsabbau wird das Device neu angelegt und die Default-Route gelöscht. Schließlich wird die Datei <tt>/etc/route.conf</tt> durchsucht und die Default-Route, wenn definiert, neu angelegt. Definiert man dort keine Default-Route, so hat man nach Verbindungsabbau eben keine. Gestartet werden kann dann nur mit dem Kommando: <tscreen><verb> isdnctrl dial ippp0 </verb></tscreen> Wer manuell auflegen will, benutzt folgendes: <tscreen><verb> isdnctrl hangup ippp0 </verb></tscreen> <sect1> Wie erlaube ich normalen Benutzern, Dial-On-Demand zu aktivieren? <label id="DE-ISDN-HOWTO-sudo"> Am besten gar nicht, denn das ist Aufgabe des Administrators. Es ist nur ihm vorbehalten, Netzdevices und Routen zu konfigurieren. Versuche nicht, den notwendigen Programmen suid-Attribute zu geben. Erstens ist diese Aufgabe sehr schwer, und zweitens handelt man sich damit ein riesiges Sicherheitsloch ein, denn wenn diese Programme erstmal <em/offen/ sind, lassen sich auch andere unerwünschte Dinge damit tun. Einem einzelnen Skript suid-Attribute zu geben, ist unter Linux ebenfalls verboten. Wer es dennoch unbedingt machen will, der benutze ein Paket wie z.B. <tt/sudo/. Damit lassen sich für einzelne Benutzer bestimmte Kommandos definieren, die diese dann als Benutzer <tt/root/ ausführen dürfen. Hier ein einfaches Beispiel: <enum> <item> Paket <tt/sudo/ installieren. <item> Mit <tt/visudo/ die Konfigurationsdatei editieren, z.B. soll der Benutzer <tt/kfr/ das Programm <tt>/usr/local/bin/dial</tt> ausführen dürfen: <tscreen><verb> # Angabe der privilegierten Benutzer kfr ALL=/usr/local/bin/dial </verb></tscreen> Benutze nur das Kommando <tt/visudo/, um die Konfigurationsdatei <tt>/etc/sudoers</tt> zu verändern. <item> Das Skript <tt/dial/ könnte z.B. so aussehen: <tscreen><verb> #!/bin/sh DEVICE=ippp0 if test $UID -ne 0; then exec sudo $0 $* fi case "$1" in stop) echo stop isdnctrl hangup $DEVICE ;; *) echo dial isdnctrl dial $DEVICE ;; esac </verb></tscreen> Wird es nicht als User <tt/root/ aufgerufen, startet es sich selbst mit <tt/sudo/ neu. Mit <tt/dial/ wird gewählt, mit <tt/dial stop/ wird aufgelegt. <item> <tt/sudo/ fragt beim ersten Start und danach von Zeit zu Zeit das Paßwort des aufrufenden Benutzers ab. <item> Um die Paßwortabfrage zu verhindern, muß das Schlüsselwort <tt/NOPASSWD/ mit angegeben werden, z.B. <tscreen><verb> kfr ALL=NOPASSWD:/usr/local/bin/dial </verb></tscreen> </enum>  <sect> Konfiguration der Internet-Dienste Voraussetzung für diesen Abschnitt des Dokumentes ist, daß die Internet-Verbindung über die Dial-On-Demand Wählverbindung und das Routing bereits funktioniert. Jetzt sollen je nach Bedarf weitere Internetdienste eingerichtet werden. <sect1> DNS-Cache <label id="DE-ISDN-HOWTO-dnsCache"> <nidx>DNS!Cache</nidx> <nidx>Name Resolver!Cache</nidx> Die Hintergrundinformationen zum DNS-Cache sind in Abschnitt <ref id="DE-ISDN-HOWTO-ipnummern" name="IP-Nummern Auflösung"> zu finden. Um einen DNS-Cache einzurichten, geht man so vor: <enum> <item> Paket <tt/bind/ installieren. <item> <nidx>/etc/named.boot</nidx> <nidx>DNS!/etc/named.boot</nidx> <nidx>Name Resolver!/etc/named.boot</nidx> Dann editiere man <tt>/etc/named.boot</tt>: <tscreen><verb> cache . root.cache options query-log forwarders 192.76.144.66 slave </verb></tscreen> Bei <tt/forwarders/ werden ein oder mehrere IP-Nummern der Nameserver eingetragen. Die Option <tt/slave/ steuert das Verhalten, wenn der Nameserver selbst noch keine Antwort hat. Ohne die Option müßte jetzt der eigene Nameserver die Anfrage auflösen, was recht aufwendig sein kann. Mit dieser empfohlenen Option wird dem Forwarder gesagt, daß er die Anfrage auflösen soll. Bei der nächsten Anfrage hat er diese dann im Cache. Zur Diagnose ist zu empfehlen, noch die Zeile <tt/options query-log/ einzufügen; es werden dann über Syslog, also in <tt>/var/log/messages</tt>, alle Anfragen an den Nameserver protokolliert. Dadurch lassen sich einfach die »Übeltäter« im lokalen Netz finden. Beispiel: <tscreen><verb> named[232]: XX /192.168.1.2/www.suse.de/A </verb></tscreen> Der Rechner 192.168.1.2 fragt nach dem A-Record für <tt>www.suse.de</tt>. <item> Wir benutzen uns selbst als Nameserver. Trage als Nameserver die lokale IP-Nummer ein (<tt/192.168.1.1/), siehe Abschnitt <ref id="DE-ISDN-HOWTO-resolv" name="Konfiguration der Namensauflösung">. <item> Nun muß der eigene Nameserver gestartet werden. <itemize> <item> <nidx>DNS!/etc/rc.config</nidx> <nidx>Name Resolver!/etc/rc.config</nidx> <nidx>DNS!/sbin/init.d/named</nidx> <nidx>Name Resolver!/sbin/init.d/named</nidx> <nidx>/sbin/init.d/named</nidx> SuSE Methode: Trage in <tt>/etc/rc.config</tt> folgendes ein: <tscreen><verb> START_NAMED=yes </verb></tscreen> Starte Nameserver durch Reboot oder direkt durch <tt>/sbin/init.d/named start</tt> <item> Manuelle Methode: <tt>/usr/sbin/named</tt> </itemize> <item> Nun sollte getestet werden, ob alles funktioniert: <tscreen><verb>nslookup www.suse.de</verb></tscreen> Als Ergebnis wird eine Verbindung aufgebaut, in <tt/messages/ wird die Anfrage protokolliert und die IP-Nummer wird aufgelöst. Eine Wiederholung der Anfrage, wenn die Verbindung nicht besteht, darf keine Verbindung aufbauen, die Anfrage muß sofort beantwortet werden. </enum> <sect1> Squid <label id="DE-ISDN-HOWTO-squid"> <nidx>Squid</nidx> <nidx>FTP!Proxy</nidx> <nidx>WWW!Proxy</nidx> Squid ist ein WWW- und FTP-Proxy. Der Vorteil eines Proxies liegt nicht nur darin, Anfragen für mehrere Benutzer zu cachen, sondern auch darin, daß die Clientrechner im lokalen Netz nicht unbedingt echten Internetzugriff über Masquerading haben müssen, was die Übersicht und die Sicherheit erhöht. <nidx>Squid!/etc/squid.conf</nidx> <nidx>/etc/squid.conf</nidx> Squid hat eine Vielzahl von Optionen und Features. Die mitgelieferte Beispielkonfiguration in <tt>/etc/squid.conf</tt> ist sehr gut dokumentiert und funktioniert zunächst einmal ohne Änderung. <sect2> Starten von Squid <nidx>Squid!Start</nidx> Bei SuSE wird über die <tt/rc.config/-Variable <tt/START_SQUID/ gesteuert, ob Squid gleich beim Systemstart hochgefahren werden soll (über <tt>/sbin/init.d/squid</tt>). Manuell kann man <tt/squid/ z.B. durch <tscreen><verb> /usr/sbin/squid -sYD >> /var/squid/squid.out 2>&1 &</verb></tscreen> starten. Vor dem ersten Start muß das Cache-Directory initialisiert werden; dies sollte als Benutzer squid geschehen. Als root kann man einfach folgendes aufrufen: <tscreen><verb>su squid -c "/usr/sbin/squid -z"</verb></tscreen> <sect2> Clients anpassen <nidx>Squid!Clients</nidx> Die WWW-Browser müssen konfiguriert werden, damit Sie den Proxy ansprechen. Bei Netscape gibt es die Maske Options/Network Preferences, Proxies/Manual Proxy Configuration. In der Maske gibt man jeweils für FTP und HTTP-Proxy die IP-Nummer des IZG im lokalen Netz ein und als Portnummer <tt/3128/ oder was in <tt>/etc/squid.conf</tt> definiert ist. Zusätzlich sollte man noch im Feld <em/No Proxy for/ eintragen, für welche Domains nicht über den Proxy gegangen, sondern direkt auf den WWW-Server zugegriffen werden soll, z.B.: <tt/localhost isdnworkshop.de/. <sect1> Fetchmail <label id="DE-ISDN-HOWTO-fetchmail"> <nidx>fetchmail</nidx> <nidx>POP3!fetchmail</nidx> <nidx>Mail!fetchmail</nidx> Das Programm <tt/fetchmail/ (Paket <tt/pop/) eignet sich dazu, Mails über das POP3-Protokoll vom Provider abzuholen. Das Abholen kann auch als normaler User durchgeführt werden, wir holen hier die Mails als root ab, dadurch läßt sich der Vorgang besser automatisieren. Nach dem Abholen werden die Mails dem lokalen Sendmail übergeben und zugestellt. Der Mailserver sei <tt/mail.provider.de/. Es gibt zwei Benutzer <em/asterix/ und <em/obelix/, die auf dem lokalen Rechner <em/eva/ und <em/maria/ heissen. Als Paßwörter werden auf dem Mailserver <em/adam/ und <em/josef/ benutzt. <itemize> <item> Lege eine Datei <tt>/root/.fetchmailrc</tt> an: <tscreen><verb> poll mail.provider.de protocol POP3 user asterix password adam is eva poll mail.provider.de protocol POP3 user obelix password josef is maria </verb></tscreen> <item> Zum Test starte: <tscreen><verb> fetchmail -v --keep -a </verb></tscreen> Die Option <tt/-v/ führt zu mehr Ausgaben, die Option <tt/--keep/ sorgt dafür, daß die Mails auf dem Server zunächst nicht gelöscht werden. <item> Wenn das erfolgreich war, trage in <tt>/etc/ppp/ip-up</tt> das Kommando <tscreen><verb> fetchmail -a >> /var/log/fetchmail </verb></tscreen> in den Start-Abschnitt ein. </itemize> Mehr Informationen findet man hier: <tscreen><htmlurl url="http://www.suse.de/Support/sdb/fetchmail.html" name="http://www.suse.de/Support/sdb/fetchmail.html"></tscreen> Übung: Auf dem Server liegen Mails für jede Workstation bereit. Richte <tt/fetchmail/ so ein, daß bei jedem Verbindungsaufbau Mails abgeholt werden. Prüfe die lokale Zustellung. <sect1> Sendmail <label id="DE-ISDN-HOWTO-sendmail"> <nidx>sendmail</nidx> <nidx>Netzwerk!Mail</nidx> <nidx>Mail!sendmail</nidx> Über Sendmail kann man dicke Bücher schreiben, siehe Abschnitt <ref id="DE-ISDN-HOWTO-bookSendmail" name="Sendmail">. Das SuSE Paket <tt/sendmail/ ist für diese Zwecke hier bestens gerüstet. Besonders wichtig ist hier zum einem, daß die Absenderadresse richtig gesetzt wird, denn die lokale Domain könnte ja zur E-Mail-Adresse beim Provider unterschiedlich sein. Zum anderen sollen lokale E-Mails sofort zugestellt werden, Mails, die über die Wählleitung verschickt werden müssen, sollen dagegen in eine Warteschlange gestellt werden, ohne daß eine Verbindung aufgebaut wird. Wie immer gibt es mehrere Wege: <itemize> <item> <nidx>sendmail!/etc/rc.config</nidx> Sendmail über <tt>/etc/rc.config</tt> konfigurieren: <tscreen><verb> FROM_HEADER="klaus.franken.de" SENDMAIL_TYPE="yes" SENDMAIL_SMARTHOST="mail-n.franken.de" SENDMAIL_LOCALHOST="localhost franken.b.eunet.de \ glen.home.suse.de klaus.franken.de" SENDMAIL_RELAY="" SENDMAIL_ARGS="-bd -om" SENDMAIL_EXPENSIVE="yes" SENDMAIL_NOCANONIFY="yes" </verb></tscreen> <item> <nidx>sendmail!m4-Makros</nidx> <nidx>sendmail!/etc/sendmail.cf</nidx> <nidx>/etc/sendmail.cf</nidx> Sendmail über m4-Makro-File konfigurieren: Seit Sendmail Version 8 bietet Sendmail ein Makro-Paket, bei dem die eigentliche Konfigurationsdatei <tt>/etc/sendmail.cf</tt> nicht <em/von Hand/ erstellt werden muß, sondern über eine Meta-Datei generiert wird. Das Verzeichnis der Makros ist je nach Distribution unterschiedlich, üblich ist z.B. <tt>/usr/share/sendmail/m4</tt> oder bei SuSE auch <tt>/etc/mail</tt>. In der Distribution sollten sich Vorlagen befinden. Bei SuSE ist eine gut kommentierte <tt>/etc/mail/linux.mc</tt> dabei. Bevor man diese ändert, sollte man in <tt>/etc/rc.config</tt> mit <tt>SENDMAIL_TYPE="no"</tt> das automatische Generieren abstellen. Man generiert eine neue Konfigurationsdatei mit: <tscreen><verb> m4 linux.mc > /etc/sendmail.cf </verb></tscreen> Weitere Informationen sind in der Datei <tt>/etc/mail/README</tt> zu finden. <item> <nidx>sendmail!/etc/mail/genericstable</nidx> <nidx>/etc/mail/genericstable</nidx> Sendmail Finetuning: Bei ausgehenden E-Mails werden abhängig vom lokalen Benutzernamen die E-Mail-Adressen mit Hilfe der Datei <tt>/etc/mail/genericstable</tt> umgeschrieben: <tscreen><verb> kfr kfr@klaus.franken.de sandra sandra@klaus.franken.de sr sandra@klaus.franken.de </verb></tscreen> </itemize> Nun kann mal folgende Übungen machen: <itemize> <item> Schreibe Dir selbst eine Mail auf dem lokalen Rechner. <item> Schreibe anderen Usern eine Mail auf dem lokalen Rechner. <item> Schreibe eine Mail an <tt>root@server.isdnworkshop.de</tt>. <item> Schreibe eine Mail an andere Benutzer auf <tt/server.isdnworkshop.de/ (ws0, ws1, ...). <item> Prüfe nach, wo Deine Mails sind. <item> Stelle sicher, daß Mails beim Verbindungaufbau gequeued verschickt werden, lokale Mails aber sofort zugestellt werden.  <item> Prüfe die Mailqueue mit <tt>mailq</tt> </itemize> <sect1> News <nidx>News</nidx> <nidx>Netzwerk!News</nidx> <nidx>$NNTPSERVER</nidx> Online News kann man schon jetzt sehr einfach lesen. Als News-Server gibt man den entsprechenden Server des ISPs an. Dazu muß man für die meisten News-Reader die Variable <tt>NNTPSERVER</tt> setzen: <tscreen><verb>export NNTPSERVER='klaus.franken.de'</verb></tscreen> Dies sollte man systemweit in der <tt>/etc/profile</tt> setzen. Wünschenswert ist natürlich, News offline zu lesen und entweder bei Bedarf zu holen bzw. zu verschicken oder dieses per Cron-Job z.B. jede Nacht durchführen zu lassen. Die Installation eines eigenen News-Servers ist recht aufwendig, es bieten sich <em/CNews/ oder <em/INN/ an. Siehe dazu auch das <htmlurl name="News HOWTO" url="DE-News-HOWTO.html">.  Ein eigener News-Server ist aber eigentlich nur dann notwendig, wenn man auf diesem selber Newsgruppen einrichten möchte. Will man das nicht, sind CNews und INN vollkommen überdimensioniert; deshalb möchte ich hier zwei andere Möglichkeiten vorstellen. <nidx>News!Leafnode</nidx> <nidx>News!slrn</nidx> <nidx>Leafnode</nidx> <nidx>slrn</nidx> Zwei Pakete bieten sich an: <em/Leafnode/ und <em/slrn/. Beide sind einfach einzurichten und zu warten und reichen für ein mittleres Newsaufkommen vollkommen aus. <tt/slrn/ ist eigentlich ein eigener textorientierter, sehr flexibler und schneller News-Reader und bietet ein eigenes Programm <tt/slrnpull/, das die News abholt und in ein eigenes Spool-Verzeichnis stellt, auf welches direkt von <tt/slrn/ zugegriffen werden kann. Es existieren allerdings auch einige Einschränkungen: es kann kein anderes News-Programm darauf zugreifen; es kann nicht über Netzwerk auf die News zugegriffen werden, da kein lokaler News-Server läuft. Eventuell geht das jedoch über NFS. Leafnode stellt dagegen einen eigenen News-Server zur Verfügung, braucht aber insgesamt mehr Ressourcen. Der Trick bei Leafnode ist der, daß sich der Server quasi selbst konfiguriert: wird von einem Client auf eine Gruppe zugegriffen, wird diese automatisch abonniert und ist beim nächsten Abgleich vorhanden; wird dagegen längere Zeit nicht mehr auf eine Gruppe zugegriffen, wird diese automatisch gelöscht. Man kann Leafnode also in einem kleineren Netz mit mehreren Lesern trotzdem nahezu unbeaufsichtigt laufen lassen. Beide Programme arbeiten sehr gut in dieser Dial-On-Demand-Umgebung. Zugriffe auf den News-Server beim Provider werden nur auf Wunsch, nie aber automatisch ausgeführt. <sect2> slrn installieren und konfigurieren <nidx>slrn!Installation</nidx> Die getestete Version ist 0.9.5.2 von folgendem Server: <tscreen> <htmlurl url="ftp://space.mit.edu/pub/davis/slrn" name="space.mit.edu:/pub/davis/slrn"></tscreen> Es wird die <tt/slang/-Bibliothek ab Version 1.0.3 benötigt. Bei SuSE 5.2 ist noch die Version 0.99.38 dabei. Zu bekommen ist die Bibliothek unter <tscreen><htmlurl url="ftp://space.mit.edu/pub/davis/slang" name="space.mit.edu:/pub/davis/slang"></tscreen> Beim Kompilieren darf nicht vergessen werden, auch <tt/make slrnpull/ einzugeben. Die Binaries werden z.B. nach <tt>/usr/local/bin</tt> kopiert oder es wird folgendes ausgeführt: <tscreen><verb> install -m 755 -o root -g root src/objs/slrn \ /usr/local/bin install -m 755 -o root -g root src/objs/slrnpull \ /usr/local/bin install -d /usr/doc/packages/slrn -m 755 \ -o root -g root install -m 644 -o root -g root doc/* \ /usr/doc/packages/slrn install -m 644 -o root -g root COPYRIGHT \ /usr/doc/packages/slrn install -m 644 -o root -g root COPYING \ /usr/doc/packages/slrn install -m 644 -o root -g root README \ /usr/doc/packages/slrn install -m 644 -o root -g root changes.txt \ /usr/doc/packages/slrn install -m 644 -o root -g root doc/slrn.1 \ /usr/local/man/man1 install -d /usr/doc/packages/slrn/slrnpull \ -m 755 -o root -g root install -m 644 -o root -g root slrnpull/* \ /usr/doc/packages/slrn/slrnpull </verb></tscreen> Dann wird das Spool-Verzeichnis angelegt und die Config-Datei erstellt: <tscreen><verb> mkdir /var/spool/slrnpull cd /var/spool/slrnpull cp /src/slrn/slrnpull/slrnpull.conf . </verb></tscreen> <nidx>slrn!slrnpull.conf</nidx> In <tt/slrnpull.conf/ könnte z.B. folgendes stehen: <tscreen><verb> default 0 14 de.alt.comm.isdn4linux </verb></tscreen> <nidx>slrn!˜/.slrnrc</nidx> Jetzt muß noch der News-Reader auf diesen Spool-Pfad konfiguriert werden. Dazu fügt man folgendes in <tt>˜/.slrnrc</tt> ein bzw. paßt die Datei entsprechend an: <tscreen><verb> %%% Spool set spool_inn_root "/var/spool/slrnpull" set spool_root "/var/spool/slrnpull/news" set spool_nov_root "/var/spool/slrnpull/news" set use_slrnpull 1 set read_active 1 set server_object "spool" hostname "klaus.franken.de" set username "kfr" </verb></tscreen> Das Abholen und Verschicken eigener News und das Löschen alter Artikel geschieht mit einem einzigen Kommando, das als root ausgeführt wird: <tscreen><verb> slrnpull -d /var/spool/slrnpull -h news.franken.de </verb></tscreen> Beim ersten Mal dauert das natürlich sehr lange und sollte daher manuell ausgeführt werden. Im Betrieb kann man das über einen Croneintrag oder in <tt>/etc/ppp/ip-up</tt> bei jedem Verbindungsaufbau durchführen lassen. Beim manuellen Start gibt <tt/slrnpull/ Meldungen auf der Console aus; wird es im Hintergrund gestartet, loggt es nach <tt>/var/spool/slrnpull/log</tt>. Aber Achtung, diese Datei kann groß werden. <sect2> Leafnode installieren und konfigurieren Leafnode (Version 1.4) gibt es auf <tscreen> <htmlurl url="ftp://ftp.troll.no/pub/freebies/" name="ftp.troll.no:/pub/freebies/"></tscreen> Die mitgelieferten Dateien <tt/README/ und <tt/INSTALL/ beschreiben die Installation sehr gut. <nidx>fetch</nidx> <nidx>texpire</nidx> Im folgenden Beispiel werden die Binaries <tt/leafnode/, <tt/fetch/ und <tt/texpire/ nach <tt>/usr/local/bin</tt> installiert; der Makefile muß dafür angepaßt werden. Zunächst wird der NNTP-Server <tt/leafnode/ in der <tt>/etc/inetd.conf</tt> durch folgende Zeile aktiviert: <tscreen><verb> nntp stream tcp nowait news /usr/sbin/tcpd /usr/local/bin/leafnode </verb></tscreen> Danach muß <tscreen><verb>killall -1 inetd</verb></tscreen> ausgeführt werden. Als nächstes muß ein User und eine Gruppe <tt/news/ angelegt werden, z.B. durch folgenden Eintrag in <tt>/etc/passwd</tt>: <tscreen><verb> news:x:9:13::/var/spool/news:/bin/bash </verb></tscreen> Alle Arbeiten müssen dann als User <tt/news/ ausgeführt werden. Im Verzeichnis <tt>/usr/lib/leafnode</tt> wurde bei der Installation eine Beispiel-Datei angelegt, die man kopieren und anpassen muß: <tscreen><verb> su - news cd /usr/lib/leafnode cp config.example config </verb></tscreen> Die Datei ist kommentiert, hier arbeiten folgende Einträge: <tscreen><verb> server = news.franken.de expire = 20 maxcount = 1000 </verb></tscreen> Jetzt muß man dafür sorgen, daß das Programm <tt/texpire/ regelmässig aufgerufen wird, ansonsten werden alte News nicht wieder gelöscht; hier arbeitet folgender Crontab-Eintrag vom Benutzer root jede Nacht um 5:42 und löscht die alten Artikel: <tscreen><verb> 42 5 * * * su news -c texpire </verb></tscreen> Durch das Kommando <tt/fetch/ oder besser <tt/fetch -v/ wird nun der Newsserver initialisiert, aber es sind keine Gruppen verfügbar. In dem man jetzt einmalig durch einen News-Reader auf diesen Newsserver und auf die interessanten Gruppen zugreift, die natürlich alle mit der Anzahl 0 angezeigt werden, werden die Gruppen abonniert. Beim nächsten Aufruf von <tt/fetch/ werden dann die Artikel geholt. Auch hier kann man <tt/fetch/ via Crontab regelmässig oder durch einen Eintrag in <tt>/etc/ppp/ip-up</tt> aufrufen. Ein Problem ist allerdings, daß man keinen direkten Einfluß darauf hat, welche Gruppen abonniert werden. Es sei denn, daß man vor dem Aufruf von <tt/fetch/ das Verzeichnis <tt>/home/opt/spool/news/interesting.groups</tt> »aufräumt«. Die Ausgabe von <tt/fetch/ sollte beachtet werden; abgelehnte eigene Postings werden nirgends abgespeichert, sondern einfach gelöscht. <sect1> Firewall <label id="DE-ISDN-HOWTO-ipfwadm"> <nidx>Firewall</nidx> <nidx>Netzwerk!Firewall</nidx> <nidx>IP!Firewall</nidx> Firewalls sind ein heikles Thema. Der Autor übernimmt keine Garantie für die Richtigkeit der hier gemachten Angaben. Wer ein wirklich sicheres System benötigt, sollte zumindest das <htmlurl name="Firewall HOWTO" url="DE-Firewall-HOWTO.html"> lesen oder einen Experten dafür beauftragen. Über Firewalls kann man dicke Bücher schreiben, siehe Abschnitt <ref id="DE-ISDN-HOWTO-bookFirewall" name="Firewall">. Die einfachste aber wirkungsvolle Methode ist die Benutzung eines Paketfilters. Diese Methode wird direkt vom Linux-Kernel unterstützt und über das Kommando <tt/ipfwadm/ (IP-FireWall ADMinistration) konfiguriert. <sect2> Was ist ein Paketfilter? Jedes IP-Paket, das vom Kernel behandelt wird, wird nach einer Regelliste untersucht und entweder akzeptiert oder abgelehnt. Es werden drei verschiedene Listen geführt: <enum> <item>Incoming (Schalter <tt/-I/): einkommende Pakete <item>Outgoing (Schalter <tt/-O/): ausgehende Pakete <item>Forwarding (Schalter <tt/-F/): durchgehende Pakete </enum> <sect2> Wie gibt man eine Firewall-Regel an? <nidx>ipfwadm!IP Firewall</nidx> Der <tt/ipfwadm/-Aufruf setzt sich zusammen aus: <descrip> <tag>Wann?</tag> Incoming (<tt/-I/), Outgoing (<tt/-O/) oder Forwarding (<tt/-F/) <tag>Wohin?</tag> Man kann neue Regeln an den Anfang der Liste (<tt/-i/) oder an das Ende der Liste (<tt/-a/) setzen. Die Regeln werden immer von vorne nach hinten interpretiert, bei der ersten passenden Regel wird nicht weitergesucht. <tag>Was tun?</tag> Soll das Paket akzeptiert werden (accept), oder abgewiesen (deny) werden? <tag>Protokoll?</tag> Mögliche Protokolle sind tcp, udp, icmp oder alles (all). <tag>Quell-IP?</tag> Angabe des Source-IP-Nummern-Bereiches (<tt/-S/), z.B. <tt>-S 192.168.42.0/24</tt> <tag>Ziel-IP?</tag> Angabe des Ziel-IP-Nummern Bereiches (<tt/-D/) <tag>Port?</tag> Meist wird direkt hinter der Ziel-IP-Nummer noch der Ziel-Port mit angegeben, dies kann der numerische Wert oder das Alias, wie in <tt>/etc/services</tt> definiert, sein. <tag>Wo?</tag> Mit dem Schalter <tt/-W/ kann die Regel auf ein Netzdevice beschränkt werden. </descrip> Weiterhin gibt es folgende wichtige Optionen: <itemize> <item> <tt/-f/: Setzt das Regelwerk für <tt/-I/, <tt/-O/ oder <tt/-F/ zurück. <item> <tt/-o/: Beim Zutreffen der Regel wird eine Meldung via syslog in <tt>/var/log/messages</tt> geschrieben. <item> <tt/-m/: Masquerading, s.u. <item> <tt/-A/: Accounting, s.u. <item> <tt/-l/ oder <tt/-lne/: Listet die Regeln. </itemize> <sect2> Was für Regeln brauche ich mindestens? Eines der größten Sicherheitslöcher ist das sogenannte <em/Spoofing/. Darunter versteht man, daß ein eigentlich fremder Rechner behauptet, eine IP-Nummer aus dem eigenen, sicheren Netz zu haben. Daher müssen als erstes Regeln definiert werden, die verhindern, daß eigene IP-Nummern aus dem unsicheren Netz hereinkommen können. Als nächstes sollte man alle Zugriffe von außen verbieten und nur bei Bedarf die benötigten Dienste wie Mail oder WWW freischalten. <sect2> Ein einfacher Firewall Das lokale Ethernet ist auf 192.168.42.0 konfiguriert. Wir erwarten IP-Nummern aus dem Bereich 193.110.3.0/24 zugewiesen zu bekommen, wobei der PtP-Partner nicht aus diesem Bereich ist, da ansonsten seine Pakete auch abgewiesen werden würden. <tscreen><verb> # Spoofing verhindern: /sbin/ipfwadm -I -a deny -o -P all -S 192.168.42.0/24 \ -D 192.168.42.0/24 -W ippp0 /sbin/ipfwadm -I -a deny -o -P all -S 192.168.42.0/24 \ -D 193.110.3.0/24 -W ippp0 /sbin/ipfwadm -I -a deny -o -P all -S 193.110.3.0/24 \ -D 192.168.42.0/24 -W ippp0 /sbin/ipfwadm -I -a deny -o -P all -S 193.110.3.0/24 \ -D 193.110.3.0/24 -W ippp0 # Zugriffe von überall auf den Mail-Server (Port 25) # erlauben: /sbin/ipfwadm -I -a accept -P tcp -S 0/0 \ -D 192.168.42.1 25 -W ippp0 # Zugriffe von überall auf den DNS-Server (Port 53) # erlauben: /sbin/ipfwadm -I -a accept -P tcp -S 0/0 \ -D 192.168.42.1 53 -W ippp0 # sonst alles verbieten (getrennt für Protokoll tcp # und udp) /sbin/ipfwadm -I -a deny -o -P tcp -S 0/0 \ -D 192.168.42.0/24 1:1023 -W ippp0 /sbin/ipfwadm -I -a deny -o -P tcp -S 0/0 \ -D 193.110.3.0/24 1:1023 -W ippp0 /sbin/ipfwadm -I -a deny -o -P udp -S 0/0 \ -D 192.168.42.0/24 1:1023 -W ippp0 /sbin/ipfwadm -I -a deny -o -P udp -S 0/0 \ -D 193.110.3.0/24 1:1023 -W ippp0 </verb></tscreen> Bei SuSE läßt sich obiges Beispiel auch in der <tt>/etc/rc.config</tt> einstellen: <tscreen><verb> FW_START="yes" FW_LOCALNETS="192.168.42.0/24 193.110.3.0/24" FW_MAILSERVER="192.168.42.1" FW_DNSSERVER="192.168.42.1" FW_WORLD_DEV="ippp0" FW_LOG_ACCEPT="no" FW_LOG_DENY="yes" FW_TCP_LOCKED_PORTS="1:1023" FW_UDP_LOCKED_PORTS="1:1023" </verb></tscreen> Siehe auch <tt>/usr/doc/packages/firewall</tt>. <sect1> Masquerading <label id="DE-ISDN-HOWTO-ipfwadm-m"> <nidx>Masquerading</nidx> <nidx>Netzwerk!Masquerading</nidx> <nidx>IP!Masquerading</nidx> <nidx>Network Address Translation</nidx> <nidx>ipfwadm!IP Masquerading</nidx> Masquerading, auch <em/Network Address Translation/ genannt, braucht man dann, wenn man ein internes Netz mit privaten IP-Nummern hat, vom ISP aber nur eine offizielle IP-Nummer bekommt und dieses vielleicht sogar dynamisch geschieht. Die IP-Pakete werden beim Rausschicken auf der Internetleitung umgeschrieben und mit der eigenen offiziellen IP-Nummer versehen. Umgekehrt wird eine Tabelle der offenen Verbindungen gehalten, damit einkommende Pakete wieder dem ursprünglichen Absender zugestellt werden können. Hat man sich mit dem Firewall bzw. Paketfilter via <tt/ipfwadm/ vertraut gemacht, ist Masquerading fast trivial, denn es findet an derselben Stelle statt und wird fast genauso konfiguriert, es wird lediglich der Schalter <tt/-m/ dazugegeben. Sollen z.B. Pakete aus dem internen Netzwerk (192.168.42.0/24), die zum Provider (Device <tt/ippp0/) verschickt werden, mit der jeweils gültigen IP-Nummer maskiert werden, geht man so vor: Es wird einer Forwarding-Rule der Schalter <tt/-m/ mitgegeben: <tscreen><verb> /sbin/ipfwadm -F -a accept -P all -S 192.168.42.0/24 \ -D 0/0 -m -W ippp0 </verb></tscreen> <nidx>FTP!Masquerading</nidx> Bei manchen Internet-Diensten wie z.B. FTP wird nicht nur ein Socket geöffnet, sondern auch ein zweiter für die Datenübertragung, die der Server zum Client aufbaut. Da der Client aber selbst aufgrund seiner privaten IP-Nummer nicht erreichbar ist und der Server die Verbindung zum falschen Rechner (IZG) aufbaut, klappt diese Methode ohne weiteres Wissen über die speziellen Eigenheiten des entsprechenden Protokolls nicht. Abhilfe dafür schaffen spezielle Routinen, die auch dafür <em/remaskieren/ können. Diese werden durch Kernel-Module geladen: <tscreen><verb> /sbin/insmod ip_masq_cuseeme /sbin/insmod ip_masq_ftp /sbin/insmod ip_masq_irc /sbin/insmod ip_masq_quake /sbin/insmod ip_masq_raudio /sbin/insmod ip_masq_vdolive </verb></tscreen> Bei SuSE läßt sich obiges Beispiel auch in der <tt>/etc/rc.config</tt> einstellen: <tscreen><verb> MSQ_START="yes" MSQ_NETWORKS="192.168.42.0/24" MSQ_DEV="ippp0" MSQ_MODULES="ip_masq_cuseeme ip_masq_ftp ip_masq_irc \ ip_masq_quake ip_masq_raudio ip_masq_vdolive" </verb></tscreen> Siehe auch <tt>/usr/doc/packages/firewall</tt>. <sect1> Accounting <label id="DE-ISDN-HOWTO-accounting"> Auf das Accounting wollen wir hier nicht weiter eingehen. Informationen hierzu finden sich in der Manual Page von <tt/ipfwadm/ unter dem Stichwort <tt/-A/. <sect1> Samba <label id="DE-ISDN-HOWTO-samba"> <nidx>Samba</nidx> <nidx>ISDN!Probleme!Samba</nidx> Samba ist ein File- und Druckerserver für das unter Windows benutzte SMB-Protokoll. Das Thema gehört also gar nicht hier her? Doch, denn Samba kann in unserem Fall Probleme machen. Beim SMB-Protokoll wird sehr viel mit Broadcasts gearbeitet; die Rechner schicken sich ständig, auch wenn eigentlich keine Aktionen ausgeführt werden, Nachrichten zu. Der Samba-Server wird meist so ausgeliefert, daß dieser alle verwendendbaren Netzdevices benutzt und dorthin Nachrichten schickt, also auch an das <tt/ippp0/-Device. Das führt dann dazu, daß ständig Verbindungen zum Provider aufgebaut werden. Lösen kann man das Problem so: <enum> <item> Starte Samba nur, wenn Du es auch brauchst. <nidx>Samba!/etc/rc.config</nidx> Bei SuSE wird Samba schon aktiviert, wenn das Paket installiert ist. Setze daher in <tt>/etc/rc.config</tt>: <tt>START_SMB=&dquot;no&dquot;</tt>. <item> Wenn Du es brauchst, sage Samba, welche Devices benutzt werden dürfen. <nidx>Samba!/etc/smb.conf</nidx> <nidx>/etc/smb.conf</nidx> In der <tt>/etc/smb.conf</tt> setze z.B. im <tt/global/-Abschnitt: <tscreen><verb>interfaces = 192.168.2.1/24</verb></tscreen> Mehr Infos gibt es hier: <tscreen><htmlurl url="http://www.suse.de/Support/sdb/isdn_samba.html" name="http://www.suse.de/Support/sdb/isdn_samba.html"> </tscreen> </enum>   <sect>Installation <label id="DE-ISDN-HOWTO-installation"> <nidx>ISDN!Installation</nidx> Je nach verwendeter Distribution müssen die Programme und Treiber selbst installiert werden. <sect1>Verwendete Programmversionen Folgende Programmversionen sollten benutzt werden: <itemize> <item> <bf/Kernel/: 2.0.34 <item> <bf/HiSax/: 2.1 (aus 2.0.33/34) bzw. 3.0   <item> <bf/sudo/: 1.5.2 </itemize>  <sect1> Unterschiede Kernel 2.0 und 2.1 Das Routing von Kerneln der Version 2.0 und 2.1 unterscheidet sich: Beim 2.0er Kernel wird, wie oben ausführlich beschrieben, das Routing für ein Netzdevice gelöscht, sobald eine neue IP-Nummer zugewiesen wurde. Beim 2.1er Kernel ist dies anders gelöst. Hier reicht es, wenn das Routing einmalig beim Booten eingestellt wird, die Dateien <tt>/etc/ppp/ip-up</tt> und <tt>/etc/ppp/ip-down</tt> können daher wesentlich einfacher gehalten werden. <sect> Mailinglisten/News <nidx>Mailingliste!ISDN</nidx> <sect1> Welche Mailinglisten gibt es? Zwei Mailinglisten beschäftigen sich ausschließlich mit dem Thema isdn4linux: <descrip> <tag>isdn4linux@hub-wue.franken.de</tag> Dies ist die offizielle Mailing-Liste. Zum Subscriben schicke man eine E-Mail an <tscreen><htmlurl url="mailto:majordomo@hub-wue.franken.de" name="majordomo@hub-wue.franken.de"></tscreen> mit <tscreen><verb>subscribe isdn4linux emailadresse</verb></tscreen> im <em/Body/ der Mail, wobei <tt/emailadresse/ die eigene E-Mail-Adresse ist - bitte sorgfältig prüfen. Das Subject ist egal. Alternativ kann man auch über die Newsgruppe <tscreen> <htmlurl url="news:de.alt.comm.isdn4linux" name="de.alt.comm.isdn4linux"></tscreen> teilnehmen. Über folgenden Server kann man diese Mailingliste durchsuchen: <tscreen><htmlurl url="http://www.dejanews.com" name="http://www.dejanews.com"></tscreen> <tag>suse-isdn@suse.com</tag> Dieses ist die i4l-Mailingliste speziell für die SuSE-Distribution. Zum Subscriben schicke man eine Mail an <tt><htmlurl url="mailto:majordomo@suse.com" name="majordomo@suse.com"></tt> mit <tscreen><verb>subscribe suse-isdn emailadresse</verb></tscreen> im <em/Body/ der Mail, wobei <tt/emailadresse/ die eigene E-Mail-Adresse ist. Auch hier spielt das Subject keine Rolle. Diese und weitere SuSE-Mailinglisten stehen auch über ein WWW-Frontend zum Lesen zur Verfügung: <tscreen> <htmlurl url="http://www.suse.com/Mailinglists/index.html" name="http://www.suse.com/Mailinglists/index.html"></tscreen> </descrip> <sect1> Wie frage ich auf der Mailingliste? Je besser man fragt, desto besser ist auch die Antwort. Schreibe übersichtlich. Niemand liest sich einen ewig langen Text durch, nur um herauszufinden, was überhaupt die Frage ist. Stelle zunächst sicher, daß die Lösung nicht schon beschrieben ist; es ist unfair und Zeitverschwendung, andere zu fragen, wenn man es selbst nachlesen könnte. Siehe Abschnitt <ref id="DE-ISDN-HOWTO-Links" name="Links"> und suche nach einer Lösung. Auf <tscreen><htmlurl url="http://www.dejanews.com/home_ps.shtml" name="http://www.dejanews.com/home_ps.shtml"></tscreen> kannst Du in der Newsgroup <tt/de.alt.comm.isdn4linux/ direkt nach einem Stichwort suchen, um zu sehen, ob Dein Problem eventuell vor kurzem schon diskutiert und gelöst wurde. Gib Deine Distribution und die verwendeten Versionsnummern (z.B. Kernel, HiSax) mit an. Gib auch an, was Du schon probiert hast. Gib exakte Fehlermeldungen, z.B. aus <tt>/var/log/messages</tt>, an. Niemand kann und will raten. Mit selbst bereits falsch interpretierten Meldungen kann niemand etwas anfangen. <sect1> Wie helfe ich auf der Mailingliste? Möglichst viel und gut :-). <sect>Links <label id="DE-ISDN-HOWTO-Links"> <sect1> WWW und FTP <descrip> <tag>Homepage des ISDN HOWTO</tag> <tt><htmlurl url="http://www.franken.de/users/klaus/DE-ISDN-HOWTO/" name="http://www.franken.de/users/klaus/DE-ISDN-HOWTO/"></tt> <tag>Die englische Version (noch in Arbeit) des ISDN HOWTO</tag> <tt><htmlurl url="http://www.nordkom.netsurf.de/Scott.Hanson/EN-i4l.html" name="http://www.nordkom.netsurf.de/Scott.Hanson/EN-i4l.html" ></tt> <tag>Deutsches Linux HOWTO Projekt</tag> <tt><htmlurl url="http://www.tu-harburg.de/dlhp/" name="http://www.tu-harburg.de/dlhp/" ></tt> <tag>SuSE Support-Datenbank</tag> <tt><htmlurl url="http://www.suse.de/Support/sdb" name="http://www.suse.de/Support/sdb"></tt> <tag>Hinweise zu fetchmail</tag> <tt><htmlurl url="http://www.suse.de/Support/sdb/fetchmail.html" name="http://www.suse.de/Support/sdb/fetchmail.html"></tt> <tag><label id="DE-ISDN-HOWTO-isdnDial"> Hinweise zu ungewollten Verbindungsaufbauten</tag> <tt><htmlurl url="http://www.suse.de/Support/sdb/isdn_dial.html" name="http://www.suse.de/Support/sdb/isdn_dial.html"></tt> <tag>Bernd-Hailers Leafsite Dokumentation</tag> <tt><htmlurl url="http://www.lrz-muenchen.de/˜ui161ab/www/isdn/" name="http://www.lrz-muenchen.de/˜ui161ab/www/isdn/"></tt> <tag>Weitere Beispiel-Konfigurationen</tag> <tt><htmlurl url="http://www.rosat.mpe-garching.mpg.de/˜web/ISDN.html" name="http://www.rosat.mpe-garching.mpg.de/˜web/ISDN.html"></tt> <tag>RST-Provoking Patch</tag> <tt><htmlurl url="http://www.image.dk/˜ehcorry/linux/" name="http://www.image.dk/˜ehcorry/linux/"></tt> (siehe auch <ref id="DE-ISDN-HOWTO-rstPatch" name="Der RST-provoking mode">) <tag>Michael Hipps ISDN-Seite (ipppd)</tag> <tt><htmlurl url="http://www.sfs.nphil.uni-tuebingen.de/˜hipp/isdn/" name="http://www.sfs.nphil.uni-tuebingen.de/˜hipp/isdn/"></tt> <tag>Der offizielle FTP-Server</tag> <tt><htmlurl url="ftp://ftp.franken.de/pub/isdn4linux" name="ftp.franken.de:/pub/isdn4linux"></tt> <tag>Die aktuellsten Versionen der Utils und des HiSax-Treibers</tag> <itemize> <item><tt><htmlurl url="ftp://ftp.suse.com/pub/isdn4linux" name="ftp.suse.com:/pub/isdn4linux"></tt> <item><tt><htmlurl url="ftp://ftp.suse.com/pub/isdn4linux/README" name="ftp.suse.com:/pub/isdn4linux/README"></tt> </itemize> Hier wird der CVS-Tree (Entwicklerbaum) tagesaktuell als tgz-File eingepackt. <tag> Das SuSE i4l-Paket und die SuSE-Skripts</tag> <tscreen><htmlurl url="ftp://ftp.suse.com/pub/SuSE-Linux/5.2/suse/n1" name="ftp.suse.com:/pub/SuSE-Linux/5.2/suse/n1"></tscreen> Statt <tt/5.2/ muß die jeweils aktuelle Version einsetzt werden. Interessant sind die Pakete: <tt/i4l.rpm/ (Basispaket): <tscreen><htmlurl url="ftp://ftp.suse.com/pub/SuSE-Linux/5.2/suse/n1/i4l.rpm" name="ftp.suse.com:/pub/SuSE-Linux/5.2/suse/n1/i4l.rpm"></tscreen> <tt/i4ldoc.rpm/ (Dokumentation): <tscreen><htmlurl url="ftp://ftp.suse.com/pub/SuSE-Linux/5.2/suse/doc1/i4ldoc.rpm" name="ftp.suse.com:/pub/SuSE-Linux/5.2/suse/doc1/i4ldoc.rpm"></tscreen> <tt/i4lfirm.rpm/ (Firmware für aktive Karten): <tscreen><htmlurl url="ftp://ftp.suse.com/pub/SuSE-Linux/5.2/suse/n1/i4l.rpm" name="ftp.suse.com:/pub/SuSE-Linux/5.2/suse/n1/i4l.rpm"></tscreen> <tag>AVM-B1 FTP-Server</tag> <tt><htmlurl url="ftp://calle.in-berlin.de/pub/linux/isdn" name="calle.in-berlin.de:/pub/linux/isdn"></tt> <tag>ISDN FAQ</tag> <tt><htmlurl url="http://www.suse.de/doku/i4l-faq/index.html" name="http://www.suse.de/doku/i4l-faq/index.html"></tt> <tag>kISDN</tag> <tt><htmlurl url="http://www.physik.uni-bielefeld.de/˜twesthei/kISDN.htm" name="http://www.physik.uni-bielefeld.de/˜twesthei/kISDN.htm"></tt> <tag>ISA PnP HOWTO</tag> <tt><htmlurl url="http://www.suse.de/Support/sdb/rb_isapnp.html" name="http://www.suse.de/Support/sdb/rb_isapnp.html"></tt> <tag>Telefonanrufe als WinPopUp-Fenster (Win95/NT) melden</tag> <tt><htmlurl url="http://linux0.urz.uni-heidelberg.de/˜mseuffer/datas/" name="http://linux0.urz.uni-heidelberg.de/˜mseuffer/datas/" ></tt> <tag>ISDN-Kabel selber machen</tag> <tt><htmlurl url="http://uriela.in-berlin.de/˜hifi/faqkabel.html#isdn" name="http://uriela.in-berlin.de/˜hifi/faqkabel.html#isdn" ></tt>  </descrip> <sect1> Lokale Dokumentationen Bei SuSE ist die Dokumentation zu ISDN in den Verzeichnissen <tt>/usr/doc/packages/i4l</tt> und <tt>/usr/doc/packages/i4ldoc</tt> (die FAQ, Paket <tt/i4ldoc/) zu finden. Interessant ist auch das Hilfesystem, das mit <tt/hilfe/ gestartet werden kann. Insbesondere die Support-DB unter der URL <tt>http://localhost/support-db/sdb</tt> sollte man sich anschauen. Sind die Kernelquellen installiert, steht im Verzeichnis <tt>/usr/src/linux/Documentation/isdn</tt> sehr viel Nützliches. <sect1> Bücher <itemize>  <item> <bf/Sendmail/: <label id="DE-ISDN-HOWTO-bookSendmail"> (Fledermausbuch), O'Reilly <item> <bf/Einrichten von Internet Firewalls/: <label id="DE-ISDN-HOWTO-bookFirewall">, O'Reilly </itemize> <sect> Credits An diesem HOWTO haben mitgewirkt: <itemize> <item> <bf><htmlurl url="mailto:carsten@buckaroo.prima.de" name="Carsten Schwertfeger"></bf>: Korrekturen </itemize> Bedanken möchte ich ich mich bei: <itemize> <item> <bf><htmlurl url="mailto:keil@temic-ech.spacenet.de" name="Karsten Keil"></bf> für seinen unermüdlichen Einsatz beim HiSax-Treiber <item> <bf><htmlurl url="mailto:fritz@wuemaus.franken.de" name="Fritz Elfert"></bf> für ISDN4linux <item> <bf><htmlurl url="mailto:Michael.Hipp@student.uni-tuebingen.de" name="Michael Hipp"></bf> für den ipppd <item> <bf><htmlurl url="mailto:ec@sign-tronic.dk" name="Erik Corry"></bf> für den RST-Provoking-Patch <item> der <bf/Mailingliste und Newsgruppe/ isdn4linux@hub-wue.franken.de <item> bei <bf/SuSE/ <item> und vielen vielen weiteren Entwicklern. </itemize> </article>