Zurück Weiter Inhalt

2. Voraussetzungen

2.1 Allgemeines

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.

2.2 PPP mit beliebigem Authentifizierungsschema

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.

2.3 PPP mit MS-CHAP Authentifizierung

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).

2.4 PPP mit `Callback'-Funktion

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;

Patch Datei pppd/options.c und pppd/cbcp.c für "Admin-Defined" Callback-Verfahren

2.5 Verwendung der Rückruf-Funktion (`mgetty')

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.


Zurück Weiter Inhalt