Linux als Server zur Einwahl

Ein Linux Server eignet sich bestens um eine Einwahlverbindung ins lokale Netzwerk anzubieten. Die Voraussetzung für die weitere Beschreibungen ist ein hardwaretechnisch bereits installierter und funktionierender ISDN Adapter. Ich selbst nutze eine AVM B1 ISA Karte, deren Einrichtung sich nicht wesentlich von anderen AVM Karten unterscheidet und bereits im Abschnitt Allgemeines behandelt wurde. Zum Betrieb des Dail-In Servers mit der ISDN Karte muss die ISDN Unterstützung im Kernel aktiviert sein - die hier vorgestellten Lösung basieren auf einmal auf der herkömmlichen ISDN 4 Linux Schnittstelle und anderesseits auf der CAPI Schnittstelle, (wie auch die Fax Lösung). Falls die Einwahl auf der Klienten-Seite über ISDN und analoge Anschlüsse möglich sein soll empfiehlt sich ein Hybrid-Adapter: Die Capi Lösung bietet nur einen analogen Anschluss mit 14.4Kbps an (T.30 modem for fax group 3), die I4L Lösung selbst kann (AFAIR) für Modememulation nur mit aktiven Karten umgehen.

Kernel

Das PP-Protokoll und die ISDN Treiber müssen nicht in den Kernel einkompiliert sein, eine Modulversion reicht aus.Kommen wir wieder zum Eingemachten, den Kernelquellen.Um direkt auch alle gängigen Protokolle, die auf ISDN Kanälen zum Einsatz kommen, werden diese in der Konfiguration aktiviert:

  <M> ISDN support
  [*]   Support synchronous PPP
  [ ]     PPP filtering for ISDN
  [ ]     Use VJ-compression with synchronous PPP
  [ ]     Support generic MP (RFC 1717) 
  <M>     Support BSD compression  
  <M>     Support LZS compression (module only, LZS Patch [1])
    [...]
  <M> PPP (point-to-point protocol) support
  [ ]   PPP multilink support (EXPERIMENTAL)
  [ ]   PPP filtering 
  <M>   PPP support for async serial ports  
  <M>   PPP support for sync tty ports
  <M>   PPP Deflate compression
  <M>   PPP BSD-Compress compression  
  <M>   Microsoft PPP compression/encryption (MPPC/MPPE Patch [2])
  <M>   PPP over Ethernet (EXPERIMENTAL)                                                                           

Um eine Komprimierung [1],[2] zu aktivieren muss eine Kernelerweiterung gepatcht werden, doch dazu mehr im Kapitel ISDN Inhaltsdatenkomprimierung.
Nun sollte man sich für eine Version entscheiden, entweder die I4L oder die Capi Lösung. Ich ziehe die Capi Lösung vor, ab Kernel 2.6 wird es wohl nur noch eine Capi Unterstützung gehen (oder wieder ein Brückenmodul). Wird die I4L Lösung mit ipppd genutzt muss das erwähnte Brückenmodul zwischen dem KernelCAPI und dem AnwendungsISDN geladen und die Moduldatei erweitert werden.

  alias char-major-43 capidrv 
  alias char-major-44 capidrv 
  alias char-major-45 capidrv

  /sbin/depmod -a
  /sbin/modprobe capidrv

Die notwendigen Programme zur Konfiguration einer herkömmlichen ISDN Verbindung im Paket isdn4k-utils zusammengefasst. Es empfielt sich mit den in der Distribution anthaltenen Programmen zu arbeiten, sie beherrschen abenfalls alle gängigen Protokolle, synchrones,asynchrones PPP sowie Raw-IP.

Welches Protokoll zum Einsatz kommt ist letztlich egal, Klient und Server müssen nur dieselbe Sprache sprechen, zum praktischen Einsatz kommt eines der PP-Protokolle in Frage. Asynchrones PPP verwendet X.75 als Low-Level Protokoll und entspricht dem herkömmlichen PPP über analoge Vrebindungen. Synchrones PPP verwendet HDLC-Framing ist ist das Protokoll der Wahl bei Windowsklienten, für diesen Modus gibt es unter Linux einen speziellen PPP-Daemon namens ipppd. Raw-IP setzt auch auf HDLC, hat aber keine weiteren Protokollschichten. Dies ermögliche einen schnellen Verbindungsaufbau, bietet aber nur eine Möglichkeit der Authentifizierung, die Identität der Anrufers kann nur an der übermittelten Rufnummer erkannt werden.

Das zentrale Werkzeug zur Konfigurationder Verbindungenist isdnctrl, mit seiner Hilfe werden die notwendigen Devices erzeugt und deren Eigenschaften festgelegt, sprich IP-Adresse und Telephonnummer. Per Konversation beziehen sich Namen, die mit isdn beginnen auf Schnittstellen für Raw-IP,während der Vorsatz ippp einen Betrieb mit synchronem Point-to-Point Protokoll signalisiert.

        /sbin/isdnctrl addif ippp0
        /sbin/isdnctrl eaz ippp0 1985
        /sbin/isdnctrl huptimeout ippp0 120 
        /sbin/isdnctrl l2_prot ippp0 hdlc 
        /sbin/isdnctrl l3_prot ippp0 trans 
        /sbin/isdnctrl encap ippp0 syncppp 
        ifconfig ippp0 192.168.5.10 

Der Server für synchrones PPP ipppd arbeitet etwas anders als das 'Modem' pppd und bezieht seine Konfiguration aus /etc/ppp/ioptions. Dort werden auch IP-Adressen,Kompression, DNS etc. für die Verbindung eingestellt.

  /dev/ippp0
  # debug
  # lzs 1:4
  192.168.5.10:192.168.5.101
  netmask 255.255.255.0
  noipdefault
  -defaultroute
  mru 1524
  mtu 1500
  dns-adr 192.168.5.26
  dns-adr 192.168.5.90
  proxyarp
  +pap
  -chap
  -pc
  -vj
  -vjccomp

Ein PPP-Client wickelt seinen gesamten Verkehr über die PPP-Verbindung ab, da der PPP-Server aber gerade zwischen PPP- und Ethernetverbindung vermitteln soll muss die Option defaulroute durch ein vorangestelltes - abgeschaltet werden.Neben diesen Einstellungen muss der Prozess noch wissen, wem Zugang gewährt werden soll. Zur Passwortauthentifizierung wird hier PAP (Password Authentication Protokoll) eingesetzt. Die Benutzer/Passwortpaare liegt der Server aus der Datei /etc/ppp/pap-secrets, jede Zeile enthält einen Benutzernamen, einen Servernamen, das Kennwort und eine Liste von IP-Nummern. Wichtig ist hier zu wissen das zwischen Groß/Kleinschreibung unterschieden wird (Windows ANwender sind dies nicht gewöhnt :-).

  #client     server      secet    IP
  username      *         my_pass  192.168.5.10

Den Servernamen in der zweiten Spalte benutzt nur ein Linux-Klient (die Datei wird für eingehende und ausgehende Verbindungen gebraucht). Weil die dritte Spalte das Kennwort im Klartext enthält sind für die secret-Dateien besondere Sicherheitsvorkehrungen zu treffen: Aissschließlich der Benutzer root hat Schreib-Leserechte!
Die IP-Adresse wurde der Schnittstelle zugeordnet, so teilt ein Stern in der vierten Spalte mit das jede Adresse zulässig ist.

Nun ist noch der Serverprozess zu starten und schon kann sich der Benutzer username mit dem Kennwort my_pass einwählen

  /sbin/ipppd /dev/ippp0

das sieht dann so aus

  ipppd[32008]: Local number: 1985, Remote number: , Type: incoming
  ipppd[32008]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 7
  ipppd[32008]: Check_passwd called with user=XXXXX
  ipppd[32008]: MPPP negotiation, He: No We: No
  ipppd[32008]: CCP enabled! Trying CCP. 
  ipppd[32008]: CCP: got ccp-unit 0 for link 0 (protocol: 0x80fd)
  ipppd[32008]: ccp_resetci! 
  ipppd[32008]: Compressor Stac Electronics LZS loaded! [1]
  ipppd[32008]: ccp_resetci! 
  ipppd[32008]: Compressor Stac Electronics LZS loaded! [1]
  ipppd[32008]: local  IP address 192.168.5.10
  ipppd[32008]: remote IP address 192.168.5.101
  ipppd[32008]: ppp not replacing existing default route to eth0[192.168.5.88]

PPP Daemon

Die CAPI Variante braucht keine extra abgewandelte PPP Daemon Version (deshalb auch Common API). Die gängige PPP-Software kann hier eingesetzt werden. Um die eigentliche Verbindung kümmert sich das Programm pppd egal ob der Rechner als Server oder Klient arbeitet. Derzeit wird die Version 2.4.1 des ppp-Paketes mit den Distributionen mitgeliefert, aktuell ist die Version 2.4.2. Der neuen Version kommt zugute das die Kompressionsart MCCP/MCCE eingepflegt wurde, die von neueren Windows unterstützt wird. ppp entnimmt seine Parameter zunächst der Datei /etc/ppp/options, da dieser aber durch das CAPI Modul erweitert wird können die Einstellungen auch direkt in einer Datei landen, dies teilt man dem Prozess per file mit. Die hier aufgeführten Direktiven stammen also aus dem capi4k-plugin (man capiplugin) oder direkt vom PPP (man pppd).

  nodefaultroute
  192.168.5.10:192.168.5.101
  ms-dns 192.168.5.26
  ms-dns 192.168.5.90
  ms-wins 192.168.5.26
  noipx
  proxyarp
  sync
  plugin capiplugin.so
  msn 1985
  protocol hdlc

Die Konfigurationsdateien sehen sich sehr ähnlich, hier sind zusätzlich noch die CAPI Erweiterungen eingetragen die bei I4L durch isdnctrl gesetzt werden müssen. Zum Test kann der PPP-Daemon von Hand gestartet werden:

  /sbin/pppd file /etc/ppp/peers/dialin
 
  Plugin capiplugin.so loaded.
  capiplugin: $Revision: 1.33 $
  capiconn:  1.8 

  pppd[24458]: pppd 2.4.2 started by wwilhelm, uid 0
  pppd[24458]: capiplugin: phase serialconn.
  pppd[24458]: capiplugin: waiting for incoming call ...
  kernel: capidrv-1: incoming call 1964,7,0,1985
  pppd[24458]: capiplugin: incoming call: "1964" -> "1985" incoming (0x2)
  kernel: kcapi: appl 3 ncci 0x10101 up
  pppd[24458]: capiplugin: connected: "1964" -> "1985" incoming
  pppd[24458]: capiplugin: using /dev/capi/0: "1964" -> "1985" incoming
  pppd[24458]: Using interface ppp0
  pppd[24458]: Connect: ppp0 <--> /dev/capi/0
  pppd[24458]: capiplugin: phase establish (was serialconn).
  pppd[24458]: capiplugin: phase authenticate (was establish).
  pppd[24458]: capiplugin: phase network (was authenticate).
  pppd[24458]: kernel does not support PPP filtering
  pppd[24458]: MPPC compression enabled                                        [1]
  pppd[24458]: Cannot determine ethernet address for proxy ARP
  pppd[24458]: local  IP address 192.168.5.10
  pppd[24458]: remote IP address 192.168.5.101
  pppd[24458]: capiplugin: phase running (was network).
  pppd[24458]: capiplugin: phase network (was running).
  pppd[24458]: capiplugin: phase establish (was network).

[1] siehe ISDN Datenkompression

somit ist die digitale Einwahl auch über die CAPI Schnittstelle realisiert :-)

Dialin Server als Router für das interne LAN

Bieten die Klienten im LAN des Einwahlservers selbst Dienste an kannst Du es ermöglichen, diese auch von Deinem Einwahlklienten zu nutzen.
ACHTUNG!
Sofern die zugewiesenen IP Adressen des Einwahlpartners und der lokalen Netzwerkschnittstelle im gleichen Subnetz liegen routet der Rechner wahrscheinlich bereits Pakete zwischen den internen Netzwerkschnittstellen. Hier sollte diese Funktionalität genau überpfüft werden, es wird immerhin das dahinterliegende LAN freigegeben. Dies zeigt Dir

  sysctl net.ipv4.ip_forward

an. Ein Wert von 1 bedeutet IP Packet Forwarding, 0 schaltet dieses Verhalten ab. Die Option kann in der Datei /etc/sysctl.conf gesetzt werden, damit diese Einstellung auch nach einem Neustart beibehalten wird. Soll der Rechner als Router dienen kann der Wert auch direkt per

  sysctl -w net.ipv4.ip_forward=1 oder
  echo "1" > /proc/sys/net.ipv4.ip_forward

eingestellt werden. Nun hat der Wert proxyarp in der Konfigurationsdatei auch einen Sinn, der Einwahlrechner speichert die MAC-Adresse des entfernten Partners in seiner ARP-Tabelle damit die Server im LAN den Einwahlklienten ansprechen können

Wurden unterschiedliche IP Adressen des lokalen Netzwerkes sowie des Einwahlklienten vergeben (das ürfe das häufigste Fall sein) muss der Kernel die Pakete maskieren.

• IP Forwarding aktivieren: echo 1 > /[proc]/sys/net/ipv4/ip_forward
• Maskierung aktivieren: /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Kompression

Wieso nicht mehr aus der DFÜ-Verbindung herausholen? Provider wie Klientenbetriebssysteme unterstützen die ISDN-Inhaltsdatenkomprimierung. Damit werden die Datenpakete komprimiert bevor sie über die DFÜ-Verbindung versendet werden. Wie bereits bei Modemverbindungen bekannt lassen sich damit je nach Art der übertragenen Daten, Datenübertragungsraten erzielen die über den normalen 8 kbps Limit liegen. Der Prozessor übernimmt dann die De/Kompression,mit gestiegener CPU-Performanz ist dies leicht zu bewerkstelligen.

Leider treffen im Laufe der Zeit unterschiedliche Implementierungen in Server/Klient/OS auf, da ist es mit dem Durchblick nicht weit her. Zur Zeit beherrscht Linux die Stac/LZS Komprimierung nach RFC 1974 und das MPPC nach RFC 2118. Was auch immer MS-Stac ist, ich stufe es hier mal als Marketingmittel ein, es ist keine offizielle Bezeichnung, wohl aber isst damit MPPC gemeint :-)

Windows NT und Nachfolger unterstützen ausschließlich MPPC (RFC 2118), Win9x und ME aber STAC/LZS (RFC 1974).
Also nochmal zusammengefasst:

STAC RFC 1974 Win9x, ME
MPPC RFC 2118 Win NT, 2000, XP

Die meisten deutschen ISPs machen momentan RFC 1974. WinNTx-User haben also ohne Zusatzprogramme (z.B. Fritz!Web) nichts davon, dass Ihr OS das ?fortschrittlichere? Kompressionsverfahren unterstützt. Ein Zusatzprogramm mit Unterstützung mehrerer Kompressionsarten muß komplett den PPP-Stack selbst implementieren, kann also nicht auf das DFÜ-Netzwerk aufsetzen. Das macht z.B. Fritz!Web, welches auf fast jedem Capi 2.0 fähigen ISDN-Controller läuft.
Die Arten der Kompression, die ich bei diversen Server/Klienten zum Laufen gebrahct habe hier mal im Überblick:

Ein Versuch das LZS Modul im PPP Capi Server zu laden gab zwar einen Verbindungsaufbau, aber die IP Adressen konnten nicht zugewiesen werden.

Der ipppd muss natürlich Kompression anbieten (lzs 1:4 Direktive). Bei allen halbwegs aktuellen Versionen sollte das der Fall sein, sonst die isdn4k-utils aktualisieren. Für die LZS/Stac Komprimierung wird ein Kernelmodul benötigt, also wieder ans Eingemachte und den Kernel patchen. Frank Elsner ist so freundlich und stelle direkt fertige diff-Dateien zur Verfügung. Die Option Support LZS compression setzen,kompilieren und das Modul isdn_lzscomp laden. Die Optionen werden in /etc/modules.conf eingetragen oder direkt per Kommandozeile übergeben:

  /sbin/insmod isdn_lzscomp comp=8 debug=1

  options isdn_lzscomp comp=8 debug=1

  /sbin/depmod -a
  /sbin/modprobe isdn_lzscomp

Der Parameter comp gibt die gewünschte Kompression an (0 bis 9), wobei 0 keine Komprimierung und 9 maximale Komprimierung bedeutet. Je höher die Komprimierung, desto mehr CPU-Last erzeugt das Modul, die Werte 7 oder 8 eignen sich für den Betrieb.
Der Parameter debug gibt den gewünschten Debugginglevel an, zur Testphase kann hier 1 oder 2 stehen, im Betreib benötigt man keine Debugausgaben.

Im KernelLog taucht dann auf:

  PPP Stac/HiFn LZS (De)Compression registered

IPPP

In der Konfiguration des IPPP noch die Direktive

  lzs 1:4

  ipppd[32008]: Compressor Stac Electronics LZS loaded! 

Wichtig:Die Option 1:4 gibt nicht das Komprimierungsverhältnis an!

Jetzt kann ein Einwahlversuch stattfinden (Win9x DFÜ) oder eine Verbindung zum ISP aufbauen.
Wenn dies reibungslos funkionierte und die Kompression aktiviert ist, findet man einen Eintrag im Log:

  ipppd[6536]: [0] LZS (hists 1 check 4) compression enabled

Neben Stac LZS scheint MPPC ein weit verbreiteter Kompromierungsalghorithmus zu sein. Auf der Klientenseite wird MPPC von M$ NT Produkten unterstützt. Leider ist mir kein Weg bekannt dies in die Serverkomponente des ipppd zu implementieren, daher beschränke ich mich hier auf den pppd-Klienten. Die Kernelpatches, den PPPD-Patch und genauere Anweisungen sind auf hier zu finden.

Die Vorgehensweise ist bekannt, Kernel patchen, PPP Daemon patchen, alle Komponenten übersetzen und testen. Bevor man stolpert, hier noch mal Schritt für Schritt. Das Kernelmodul versteckt sich unter Network Device Support

  <M> PPP (point-to-point protocol) support
  [ ]   PPP multilink support (EXPERIMENTAL)
  [ ]   PPP filtering
  <M>   PPP support for async serial ports
  <M>   PPP support for sync tty ports 
  <M>   PPP Deflate compression
  <M>   PPP BSD-Compress compression
  <M>   Microsoft PPP compression/encryption (MPPC/MPPE)
  <M>   PPP over Ethernet (EXPERIMENTAL)

 [*] Cryptographic API
 [ ]   HMAC support
 <M>   NULL algorithms
 <M>   MD4 digest algorithm
 <M>   MD5 digest algorithm
 <M>   SHA1 digest algorithm
 <M>   SHA256 digest algorithm
 <M>   SHA384 and SHA512 digest algorithms
 <M>   DES and Triple DES EDE cipher algorithms
 <M>   Blowfish cipher algorithm
 <M>   Twofish cipher algorithm
 <M>   Serpent cipher algorithm
 <M>   AES cipher algorithms

die Methoden auswählen. Module übersetzen und in der systermweiten /etc/modules.conf bekannt geben:

  echo "alias ppp-compress-18 ppp_mppe_mppc" >>/etc/modules.conf
  /sbin/depmod -a
  /sbin/modprobe ppp_mppe_mppc

Der Ladevorgang wurde im SysLog mit

  MPPE/MPPC encryption/compression module registered

registriert, diese Art der Komprimierung benutzt dann der (gepatchte) PPP per default.