Um eine solche Verbindung herzustellen, sind einige grundlegende Voraussetzungen zu beachten:
Kommt eine solche PPP-Verbindung zustande, sollen über sie folgende Aktivitäten abgewickelt werden können:
Es stellt sich also nun die Frage, ob und auf welche Art und Weise eine solche Verbindung zwischen Linux und Windows NT hergestellt werden kann.
Der "einfachste" Fall (PPP-Zugriff mit beliebigem Authentifizierungsschema) scheint auf den ersten Blick ohne größeren Aufwand realisierbar, da Linux im System die benötigten Module schon bereithält.
Zuerst muß der Windows NT-Systemverwalter überzeugt werden, im Windows NT-Remote Access Service unter "Network Configuration" bei den "Server settings" TCP/IP zu konfigurieren und bei den "Encryption settings" den Punkt "Allow any authentication including clear text" zu aktivieren.
Nachdem diese Hürde genommen ist, muß man sich im klaren sein, daß
Windows NT-RAS beim Einloggen des Clients (Linux-Host) nicht in gewohnter
Weise den "Login:/Password:
"-Algorithmus, sondern zur Authentifizierung
PAP/CHAP benutzt. Ein Blick in die Man-Pages des "pppd
" überzeugt davon,
daß von diesem PAP/CHAP unterstützt wird.
Leider unterstützt die hier verwendete "pppd
"-Version standardmäßig das
MS-CHAP-Protokoll nicht. Ein dem Paket beiliegender Patch (README.mschap80
),
der eine "client-only" Implementation von MS-CHAP ermöglicht, soll dieses
Manko ausgleichen.
MS-CHAP benutzt eine Kombination aus "MD4 hashing" und DES-Verschlüsselung.
Um die MS-CHAP-Erweiterung mit "pppd
" nutzen zu können, wird eine spezielle
DES-Bibliothek benötigt: Eric Youngs DES-Library; zu finden unter
ftp.psy.uq.oz.au:/pub/Crypto/DES/libdes-3.06.tar.gz
.
Nach Erzeugung und Installation dieser Library kann nun nach Einspielung der
erwähnten Patches der "pppd
"-Dämon neu übersetzt werden. Hierbei sind
neben den Anweisungen in der Datei README.mschap80
unter "BUILDING THE PPPD"
(undedingt Option -DUSE_MSCHAP verwenden) auch das Kapitel "INSTALLATION" in
der Datei README.linux
zu beachten: Die aufgeführten Punkte 2 bis 4
(Kernelcompilierung) werden nicht durchgeführt, da der aktuelle
"ppp"-Treiber des "pppd
" schon als ladbares Kernelmodul vorhanden ist
(unter /lib/modules/<kernelversion>/net/ppp.o
).
Das selbe Bild ergibt sich jedoch auch bei der Ausnutzung des
Callback-Features von Windows NT: "pppd
" liefert keinen Hinweis auf
Unterstützung dieser Option.
Glücklicherweise finden sich in den Quellen des "pppd"-Paketes ein paar entsprechende Patches, um beim Aufbau der PPP-Verbindung dem Windows NT Server eine entsprechende Telefonnummer mitzuteilen, unter der dann der Rückruf erfolgt.
Um dieses Callback-Feature zu nutzen, muß nun der dem Paket beiliegende
Patch README.cbcp
eingespielt werden. Leider bezieht sich dieser Patch nicht
auf die der verwendeten Linux Distribution beiliegenden "pppd"-Version
(ppp-2.2.0f), so daß ein automatisches Einspielen nur bedingt möglich ist;
der verbleibende Rest ist per Hand nachzuführen.
Dieser Patch unterstützt jedoch nur das "User-Defined" Callback-Verfahren.
Um zusätzlich das "Admin-Defined" Callback-Verfahren nutzen zu können sind
noch ein paar kleine Erweiterungen in den Dateien pppd/options.c
und
pppd/cbcp.c
durchzuführen:
diff -r --unified=10 options.c.noadmin options.c --- options.c.noadmin Sat Mar 15 16:47:07 1997 +++ options.c Sat Mar 15 16:38:40 1997 @@ -1004,20 +1004,21 @@ static int setcbcp(argv) char **argv; { lcp_wantoptions[0].neg_cbcp = 1; cbcp[0].us_number = (char *) malloc(strlen(*argv) + 1); strcpy(cbcp[0].us_number, *argv); cbcp[0].us_type |= (1 << CB_CONF_USER); + cbcp[0].us_type |= (1 << CB_CONF_ADMIN); return (1); } /* * nopcomp - Disable Protocol field compression negotiation. */ static int nopcomp() { lcp_wantoptions[0].neg_pcompression = 0; diff -r --unified=10 cbcp.c.noadmin cbcp.c --- cbcp.c.noadmin Sat Mar 15 16:50:14 1997 +++ cbcp.c Sat Mar 15 16:34:47 1997 @@ -286,28 +286,30 @@ PUTCHAR(CB_CONF_USER, bufp); len = 3 + 1 + strlen(us->us_number) + 1; PUTCHAR(len , bufp); PUTCHAR(5, bufp); /* delay */ PUTCHAR(1, bufp); BCOPY(us->us_number, bufp, strlen(us->us_number) + 1); cbcp_send(us, CBCP_RESP, buf, len); return; } - if (cb_type & ( 1 << CB_CONF_ADMIN ) ) { - PUTCHAR(CB_CONF_ADMIN, bufp); - len = 3; - PUTCHAR(len , bufp); - PUTCHAR(0, bufp); - cbcp_send(us, CBCP_RESP, buf, len); - return; - } + if (cb_type & ( 1 << CB_CONF_ADMIN ) ) { + syslog(LOG_DEBUG, "cbcp_resp CONF_ADMIN"); + PUTCHAR(CB_CONF_ADMIN, bufp); + len = 3 + 1; + PUTCHAR(len , bufp); + PUTCHAR(5, bufp); /* delay */ + PUTCHAR(0, bufp); + cbcp_send(us, CBCP_RESP, buf, len); + return; + } if (cb_type & ( 1 << CB_CONF_NO ) ) { syslog(LOG_DEBUG, "cbcp_resp CONF_NO"); PUTCHAR(CB_CONF_NO, bufp); len = 3; PUTCHAR(len , bufp); PUTCHAR(0, bufp); cbcp_send(us, CBCP_RESP, buf, len); ipcp_open(us->us_unit); return;
Nur mit dem Einspielen der Patches ist es jedoch nicht getan: Es muß
bedacht werden, daß ein ankommender Rückruf vom System erkannt,
untersucht, ausgewertet und bei erkannter PPP-Anforderung der "pppd
"-Prozess
aktiviert wird.
Die Überwachung eines Kommunikationsports auf Anforderungen für einen
Verbindungsaufbau (von einem Terminal oder einem Modem) wird in der Regel
von sogenannten "getty
"-Prozessen durchgeführt, wobei für jeden
Kommunikationsport, über den ein Login zulässig ist, ein eigener separater
"getty
"-Prozess benötigt wird.
Bei "getty
" handelt es sich um ein Programm das von der Init-Routine (init (1)
)
des Systemes aufgerufen wird. Es ist der zweite Prozess in der Serie
"init-getty-login-shell", mit der ein Benutzer letztlich an ein Unix-System
angeschlossen wird: "getty
" gibt zunächst eine Login-Meldung aus, liest den
Login-Namen des Benutzers und ruft dann das Kommando login(1)
auf, dem der
Benutzername als Parameter übergeben wird. "login
" fordert dann ebenfalls
die Eingabe eines Paßwortes. Beim Lesen des Namens versucht "getty
", das
System an die Geschwindigkeit und den Typ des eingesetzten
Kommunikationspartners anzupassen.
Da jedoch wie erwähnt Windows NT nicht den "Login:/Password:
"-Algorithmus
benutzt, kann dieses Verfahren nicht verwendet werden. Es ist dazu ein
intelligentes "getty
"-Programm notwendig, das die Modem-Kommunikation
beherrscht, einen Anruf erkennt, der das PPP-Protokoll benutzt und das
fähig ist, den "pppd
"-Prozess automatisch zu aktivieren.
Hierzu findet sich in den Linux-Quellen ein Paket namens "mgetty+sendfax
distribution" (kurz "mgetty"), das diese Anforderungen erfüllt. Unter
http://www.leo.org/~doering/mgetty/index.html
liegt die aktuelle (Beta-)Version (mgetty-0.99.x
bzw. mgetty-1.1.x
).
Bei der Neukompilierung ist zu beachten, den PPP-Modus explizit zu
aktivieren (im Makefile
den CFLAGS
die Option -DAUTO_PPP
mitgeben), den Pfad
des verwendeten "mgetty"-Konfigurationsverzeichnisses (Definition
"prefix=/etc
" im Makefile
) zu definieren und den Namen des Lock-Files mit
dem des "pppd" abzustimmen ( Parameter LOCK
in policy.h
bzw. Parameter
LOCK_PREFIX
in sys-linux.c
im "pppd"-Paket).
Über dieses Lock-File synchronisieren die beiden um die serielle
Schnittstelle konkurrierenden Prozesse "mgetty
" und "pppd
" den exklusiven
Zugriff auf dieses Device; aus diesem Grund sollte für den bei diesen
Programmen definierten Devicenamen immer der physikalische Gerätename
angegeben werden (z. B.: ttyS0 für COM1). Das Lock-File liegt im
Verzeichnis /var/lock
und trägt den Namen LCK..<device>
(d. h. für ttyS0
LCK..ttyS0
).
Damit "mgetty
" einen ankommenden Rückruf korrekt übernehmen kann, ist beim
angeschlossenem Modem unbedingt der "AUTOANSWER"-Modus zu deaktivieren (d.h
über den Modembefehl "ATS0&W
" permanent abzuschalten): "mgetty
" verwendet
nicht diesen Modus (Modembefehl z.B. "ATS0=2
"), sondern beantwortet einen
Anruf manuell über die Modemsteuerung per "RING --> ATA -->
CONNECT
"-Erkennung.