WWW-Version des -Artikels aus Heft 4/95, S. 192ff.
Für den Überblick: iX-TRACT
Die Web-Version dieses Artikels ist gegenüber der in
iX veröffentlichten Fassung
angepaßt - und wird laufend aktualisiert.
Stand: 12. April 1995
Größer als erwartet war das Interesse an dem in iX 12/94 beschriebenen ISDN/IP-Router auf DOS-Basis [1]. Bei Redaktionsschluß gab es zu diesem Thema eine rege Diskussion in der News-Gruppe de.comm.isdn. Der seinerzeit verwendete Testrechner, ein alter 286-PC mit 8 MHz, dient inzwischen im Dauerbetrieb als ISDN/IP-Gateway. Die Situation ist vergleichbar einem Router in einer Firma, die zum einen über ihren IP-Provider Anschluß zum Internet hat und zum anderen einem bestimmten Personenkreis (Kunden, Mitarbeiter) Zugang zum firmeneigenen Netz, aber nicht zum Internet geben will. In einem solchen Fall muß der Router IP-Pakete filtern können.
Die in [1] beschriebene Lösung basierte auf PCROUTE als Routing-Software. PCROUTE kann aber kein `packet filtering'. Alle anderen Software-Pakete, die es können, kosten Geld (IPSWITCH beispielsweise, siehe auch den Artikel `Sehr verbunden' in iX 4/95 ab Seite 39). Aus diesem Grund entschied ich mich für KA9Q als Routingsoftware.
Ziemlich bescheiden nimmt sich die übrige Hardware des Routers aus: neben einem Ethernet-Board vom Typ Western Digital WD8003E steckt eine Teles-kompatible Creatix.S0 im Rechner.
Die Crux an KA9Q ist, daß es viele verschiedene Versionen gibt. Ursprünglich von dem Packet-Radio-Amateur Phil Karn (karn@chi-cago.qualcomm.com) entwickelt, haben viele Anwender eigene Erweiterungen dazugestrickt und auf irgendwelchen FTP-Servern abgelegt.
Es existieren jedoch auch einige `gepflegte' Versionen: net-216, in der Obhut des britischen PPP-Providers Demon Internet Services (DIS), und `CWRU/BIOC NOS' nos11c-a von Ashok Aiyar (ashok@biochemistry.bioc.cwru.edu) an der Case Western Reserve University in Cleveland, Ohio. Beide Versionen bieten neben für den Router-Betrieb unwichtigen Funktionen das begehrte `packet filtering'; die Bedienung ist nahezu identisch. Daneben existieren eine noch stärker Packet-Radio-betonte Variante namens JNOS (das kein Packet Filtering bietet), unterhalten von James Dugal (jpd@usl.edu) und TextWin, ebenfalls von DIS. TextWin bietet außer der normalen KA9Q-Funktionalität eine ASCII-Fensteroberfläche.
CWRU/BIOC NOS ist als Server-Betriebssystem konzipiert [4] und benötigt zum Betrieb einen 386-Prozessor; es ist in der per FTP erhältlichen Variante für 386-Instruktionen compiliert, um etwas Performance zu gewinnen. Auf meinem 286 kann ich daher nur die DIS-Version anwenden. Diese ist per FTP erhältlich auf ftp://ftp.demon.co.uk/pub/ibmpc/, gespiegelt auf ftp://ftp.ix.de/pub/ix/msdos/net/DIS/.
Leider habe ich keine einzige vollständige Beschreibung oder Kommandoreferenz der brauchbaren KA9Q-Versionen auftreiben können; das CWRU-Dokument beschreibt in erster Linie das Aufsetzen eines Gopher-Servers (biochemistry.bioc.cwru.edu), DIS macht jede Menge Wind und Werbung. Die beste Kombination ist die Dokumentation einer älteren KA9Q-Version von Juni 1991 in Verbindung mit der FAQ zur News-Gruppe comp.protocols.tcp-ip.ibmpc, Teil 1 [3], alle auf ftp://ftp.ix.de/pub/ix/msdos/net/ka9q-doc/.
Im Gegensatz zu PCROUTE ist KA9Q durchgehend in C geschrieben und geht daher weniger effizient mit der CPU-Leistung und dem verfügbaren Speicher um. Das Tool liegt jedoch im Sourcecode vor (Borland C++ 3.1) und läßt sich durch entsprechende #define- und #undef-Zeilen in der Datei config.h individuell konfigurieren und anschließend neu übersetzen. Zusätzlich sind einige Anpassungsarbeiten im Sourcecode nötig, um diverse Definitionen zu entflechten. Für den reinen Router-Betrieb im ISDN sind beispielweise SMTP, NNTP, SLIP, PPP und AX.25 verzichtbar. Sinnvolle Optionen sind HOPCHECK (vergleichbar mit traceroute), TRACE (um IP-Pakete auf Interface-Ebene zu tracen), SERVERS (um den internen FTP-Server zu aktivieren) und FILTER. Alle Optionen sind in config.h erklärt. Eine auf diese Weise übersetztes NET.EXE liegt samt einem README und dem diff zur Originalsource unter ftp://ftp.ix.de/pub/ix/msdos/net/ka9q-router/ka9q-router.tar. Diese Version braucht immerhin 190 KByte weniger Hauptspeicher als ihr Pendant von der Stange.
Wegen des immensen Speicherhungers von KA9Q empfiehlt es sich, den DOS-Adreßbereich A000 bis B7FF mit zusätzlichem Speicher auszustatten. Dazu gibt es mehrere Möglichkeiten. Die früher gebräuchlichen NEAT-Mainboards konnten das ohne weitere Hardware, wenn genau 1 MByte Speicher vorhanden war. Unter DR-DOS und Novell DOS läßt sich mit Hilfe des Speichermanagers HIDOS.SYS ein Teil des Grafikspeichers konfiszieren. Alternativ kann man eine Zusatz-Speicherkarte verwenden, wie sie die c't 1989 entwickelt hat, und den Speicher mit einem Memory-Manager einbinden. Steht ein 386 (auch SX) zur Verfügung, nutzt man besser einen passenden Memory-Manager wie EMM386, das erspart manche Krücke.
Zwei Nachteile hat das Tracing: aus Performancegründen öffnet KA9Q die Trace-Datei(en) bei Programmstart und läßt sie offen. Je nachdem, in welchem Umfang der Verwalter die IP-Pakete protokolliert, wachsen die Dateien sehr schnell ins Unermeßliche. KA9Q schreibt nämlich die Header-Information dekodiert im ASCII-Format auf die Platte, pro IP-Header rund 200 geschwätzige Byte statt deren 40. Nun lassen sie sich zwar per FTP vom angeschlossenen Unix-Host ohne Beeinträchtigung der Trace-Funktion lesen, um beispielsweise ein Accounting von Diensten zu automatisieren, aber nicht auf Länge Null zurücksetzen: DOS kommt dann mit den Filehandles durcheinander, und der Router hört auf zu tracen. Es bleibt nichts anderes übrig, als das regelmäßig manuell durchzuführen und KA9Q anschließend neu zu starten.
Zumindest die DIS-Version hat einen dummen, aber kaum zu umgehenden Fehler: wenn die Platte voll ist, hört KA9Q einfach auf zu arbeiten, weil der entsprechende Trace-Schreibbefehl hängt. Vor jedem Schreiben die verbleibende Plattenkapazität festzustellen, ist zu zeitaufwendig -- man muß mit dem DOS-bedingten Manko leben.
Mit einem Trick läßt sich KA9Q jedoch überreden, den Rechner neu zu booten oder sich selbst zu beenden. Das Programm lauscht am UDP-Port 1234 und bietet selbst die Funktion remote, mit der sich ein entfernter KA9Q-Rechner zurücksetzen läßt. Das Programm ka9q-remote aktiviert dieselbe Funktion von einem angeschlossenen Unix-Host aus. Damit ist es möglich, zu einer betriebsarmen Zeit cron-gesteuert KA9Q neu zu beenden: die Schleife `:loop' in der AUTOEXEC.BAT initialisiert die Trace-Dateien und startet net neu - mit der Option -d /net sucht KA9Q seine Konfigurationsdateien im Verzeichnis C:\NET.
Um dem Systemadministrator den Zugang zum Router per FTP zu ermöglichen, bedarf es einer Datei FTPUSERS im Verzeichnis C:\NET, beispielsweise mit folgendem Inhalt:
isdnadm tralala / 7
Das bedeutet für KA9Q: der Verwalter hat Zugang zum gesamten Dateisystem (`/') mit dem Login `isdnadm' und dem Paßwort `tralala'. Er darf Dateien lesen, schreiben und überschreiben.
isacct, ein Perl-Skript, wertet die Schnittstellen-Tracings nach IP-Diensten und Hostnamen aus. Ein darauf aufbauendes Shell-Skript acct prüft anhand der letzten syslog-Einträge des ISDN-Pakettreibers ISPA [2], ob beide B-Kanäle frei sind und fügt alles zu einer per cron aufzurufenden Funktion zusammen. Die Komprimierung der Logdateien ist nicht unbedingt nötig, spart aber etwas Zeit beim Transfer per FTP. Jedes andere Kompressions-Tool, das auf MS-DOS und Unix zur Verfügung steht, läßt sich ebenso gut nutzen wie pkzip/unzip, zum Beispiel gzip oder lharc. Die Syntax muß gegebenenfalls etwas angepaßt werden. isacct und ka9q-remote sind aus Platzgründen nicht abgedruckt; sie liegen im gleichen FTP-Verzeichnis wie ka9q-remote. SNMP-Funktionalität, wie sie kommerzielle ISDN/IP-Router bieten, steht damit freilich nicht zur Verfügung.
Bisher klaglos funktionierte die zur Creatix-Karte mitgelieferte CAPI-Version 2.86. In der News-Gruppe de.comm.isdn war gelegentlich von Instabilitäten dieser Release zu hören, mit der Empfehlung, die Version 2.41 zu benutzen; das läßt sich aber nach den gemachten Erfahrungen nicht bestätigen.
Die Teles/Creatix-CAPI entstand zu einer Zeit, als EuroISDN noch in den Anfängen steckte, daher basiert sie weitgehend auf dem 1TR6-Standard. Sie läßt sich jedoch mit Hilfe des mitgelieferten Programms MAPCFG.EXE je eine EuroISDN-MSN (Multiple Subscriber Number) pro EAZ unterschieben. Die einstellige 1TR6-EAZ (erweiterte Auswahl-Ziffer) stellt im Prinzip eine Durchwahl zu einem ISDN-Endgerät dar; einer MSN lassen sich dagegen mehrere Endgräte zuordnen, und die Auswahl findet anhand der ISDN-Dienstekennung statt. MAPCFG braucht eine Mapping-Datei (MSN2EAZ im Beispiel-Setup), die die MSN auf je eine EAZ abbildet:
1: 825393* 2: 825928* 3: 825395*
In der ersten Spalte steht die zu belegende EAZ, in der zweiten die zugeordnete MSN ohne Vorwahl. In der Datei AUTOEXEC.BAT ist MAPCFG.EXE mit dem Namen der Mapping-Datei als Parameter aufzurufen. Im Beispiel liegt MSN2EAZ im Wurzelverzeichnis der Platte C:.
Als ISDN/IP-Pakettreiber fungierte bei Redaktionsschluß ISPA 2.41. Inzwischen läuft das System mit der Version 3.1, die unter anderem ein verbessertes Handling der Konfigurationsdateien bietet. Da zwei separate IP-Schnittstellen nötig sind, startet AUTOEXEC.BAT ISPA zweimal: einmal für jedes Interface.
Version 3 des Pakettreibers arbeitet ohne Registrierung nur zehn Minuten als Demo, danach stellt es seinen Betrieb ein. Die Registrierung kostet nach wie vor 30 Mark für Privatnutzer; der Autor Herbert Hanewinkel verschickt daraufhin das notwendige Paßwort, das als erste Kommandozeilenoption einzusetzen ist.
Bei Versuchen stellte sich ein kleiner (verschmerzbarer) Fehler von ISPA 2.4 heraus: ruft man beide ISPA mit der Option `-w' auf [2], geht gar nichts. Auch ISPA 3.0x zeigt diesen Fehler. Anscheinend behindern sich die beiden Programme gegenseitig dabei, Verbindungsinformationen in die rechte obere Bildschirmecke zu schreiben. Die Kommandozeilenoption `-e' zeigt ISPA an, mit welcher (untergeschobenen) EAZ es sich angesprochen fühlen respektive selbst melden soll.
Um die ISDN-Caller-ID nutzen zu können, benötigt ISPA 3.x jeweils eine Mapping-Datei pro Interface (IP2ISDN.1 und IP2ISDN.2). Diese können weitere Optionen enthalten, wie zum Beispiel das mit der Gegenstelle vereinbarte Protokoll. ISPA bietet hiervon eine reichliche Auswahl von HDLC/transparent über X.75 und PPP bis SLIP mit V.110-Bitratenadaption.
Um die wenigen Accounting-Informationen zu nutzen, die ISPA per syslog an einen angeschlossenen Unix-Host schickt, ist es wichtig, daß dessen syslogd per IP erreichbar ist. Auf einigen Linux-Maschinen beispielsweise kursieren noch ältere syslogd, die nicht am UDP-Port 514 lauschen, und dann ist es Essig mit syslog. ISPA schickt Logging-Informationen mit der Facility LOG_LOCAL0 und der Priorität LOG_INFO; wegen der Übersichtlichkeit tut der Verwalter gut daran, seinen syslogd so zu konfigurieren, daß nur diese Kombination in die ISDN-syslog-Dateien gelangt. Das gelingt mit folgendem Eintrag in die Konfigurationsdatei /etc/syslog.conf:
local0.info /var/log/isdnlog
Manche syslogd notieren bei diesem Setup alle Meldungen der Priorität LOG_INFO und höher; häufig bieten diese eine erweiterte Syntax der Form local0.=info, um nur genau den einen Level zu protokollieren.
Gibt es bereits beim Aufbau der eigentlichen ISDN-Verbindung Probleme, hilft unter Umständen die `Debugging CAPI' weiter, deren Benutzung in den Handbüchern von Creatix und Teles nicht erklärt ist. Die CAPI ist dazu mit der Option /t:s0 zu starten (am besten in die AUTOEXEC.BAT eintragen). Fortan sammelt sie die B- und D-Kanal-Datagramme in einem eigens reservierten 64-KByte-Speicherbereich. Das mitgelieferte Tool DTRACE.EXE liest diesen aus und stellt die Datagramme in lesbarer Form dar, allerdings nur als Hex-Dump und ohne Uhrzeit. Immerhin lassen sich darin die Telefonnummern von Anrufern und Angerufenen erkennen, sie sind ASCII-kodiert (eine `1' beispielsweise als `31').
Muß der Anwender an dieser Stelle ins `Eingemachte' gehen, helfen die Empfehlungen Q.920 und folgende der `International Telecommunication Union' (ITU) weiter. Sie sind per Gopher auf info.itu.ch [9] erhältlich; der FTP-Zugang zu info.itu.ch ist in Vorbereitung.
Der PC-Router hat mit der ISDN-Karte
und dem Ethernet-Board drei IP-Schnittstellen, zwischen denen er
routet und filtert. (Abbildung 1)
Anklicken: Bild in Originalgröße (115 KByte)
Auf diese Art und Weise ist ein sauberes Routing sichergestellt; zu jedem Gast führt eine statische Host- oder Netz-Route mit dem jeweiligen Gast-Interface als Gateway (Startdatei AUTOEXEC.NET). Die aufgeführten Hostnamen entnimmt KA9Q der Datei DOMAIN.TXT. RIP (Routing Information Protocol) kann KA9Q zwar, aber das ist weder für den Gastzugang noch den Anschluß zum Provider nötig - letzterer ist sowieso die Default-Route. Soll der Router mit RIP laufen, wäre ein Filtern von RIP-Paketen unbekannter Herkunft sinnvoll (UDP-Port 520).
attach bindet die Pakettreiber als IP-Schnittstellen ein, je eines für die beiden ISPA und eines für den Ethernet-Kartentreiber, der aus dem Fundus der Crynwr-Sammlung [10] stammt. Die ifconfig-Kommandos sehen aus wie unter Unix gewohnt, und route default definiert auch hier die Default-Route. Wegen eines Bugs legt KA9Q Routen zu den zuvor angegebenen Broadcast-Adressen an; diese muß man explizit löschen.
Als `Goodie' holt sich der Router bei jedem Start die Systemzeit von der Linux-Maschine `seneca'. Auf dieser muß dazu der in.timed laufen (neuere inetd-Varianten haben den time-Server eingebaut (`internal')). Allerdings läuft die Router-Uhr dann in UTC (früher: Greenwich Mean Time).
Abschließend ein Tip zum Geldsparen: einer der Vorteile von ISDN ist das `dial-on-demand' beim Zugriff auf einen per ISDN/IP erreichbaren Host. Diese Funktion entzieht sich jedoch völlig der Kontrolle des Benutzers. Selbst wenn man an alles gedacht und sämtliche Ports gegen unbefugte Benutzung gesperrt hat, kann es passieren, daß die Aktivität eines Gasts einen Wählvorgang auslöst. So habe ich beispielsweise einem Gast den Zugang von einem ganzen Class-C-Netz aus ermöglicht. Zu Anfang hatte ich aber nicht alle seine Hosts mit IP-Adresse in der Datei /etc/hosts stehen, was bei jedem Zugriff von einem `unbekannten' Rechner aus zu einer Nameserver-Abfrage führte. Der Nameserver ist im genannten Fall aber nur über ISDN erreichbar, was jedesmal 23 Pfennig kostete.
Um das völlig zu unterbinden, sollte man entweder selbst einen lokalen Nameserver aufsetzen oder, wenn sich das verbietet oder nicht lohnt, alle benötigten Hosts in die /etc/hosts eintragen und den Nameserver-Eintrag in /etc/resolv.conf entfernen. Von Zeit zu Zeit kann der Unix-Rechner Einträge externer Hosts (beispielsweise FTP-Server) per nslookup und einem dazu passenden Skript aktualisieren. (hm)
Verlag Heinz Heise Home Page
© Copyright 1995 by Verlag Heinz Heise GmbH & Co KG
Veröffentlichung und Vervielfältigung nur mit
Genehmigung des Verlags Heinz Heise GmbH & Co KG