Es wird die oben erwähnte gepatchte "pppd"-Version eingesetzt und
zusätzlich das Callback-Feature verwendet.
Die Anwahl des Windows NT Servers erfolgt nach dem vorausgegangenen Schema.
Um den automatischen Rückruf zu aktivieren, muß dem "pppd" die -variable-
benutzerdefinierte Telefonnummer unter der Windows NT zurückruft mitgeteilt
werden; dies erfolgt mit der Option "cb", die in das Anwahlskript eingebaut
wird:
#!/bin/sh
# Aufbau einer PPP Verbindung
# zu einem Windows NT Server unter Verwendung des CALLBACK-Modus
phone="cb 555111"
/usr/sbin/pppd 38400 connect '/usr/sbin/chat -v -f $HOME/win_nt.chat' \
lock $phone
Um den eingehenden Rückruf korrekt zu übernehmen, muß hierzu ein
entsprechender "mgetty"-Prozess für die Schnittstelle durch Eintrag in die
Datei /etc/inittab definiert werden. Dieser "mgetty"-Prozess wird beim
nächsten Systemstart automatisch aktiviert und übernimmt bei einer
ankommenden PPP-Verbindung den Aufruf des "pppd"-Programmes.
mo:23:respawn:/usr/sbin/mgetty -x 6 -s 38400 ttyS0
Parameterbeschreibung Auszug Datei /etc/inittab :
-s <speed> : setzt die zu verwendende Portgeschwindigkeit
z.B.: 38400 Baud
ttyS0 : definiert die anzusprechende Schnittstelle
( ttyS0 = COM1 )
-x 6 : setzt den debug-Modus; die debug-Informationen werden
in der Datei /tmp/log.mg.<device> abgelegt
(/tmp/log.mg.ttyS0)
In der "mgetty"-Konfigurationsdatei /etc/mgetty+sendfax/mgetty.config wird
unter anderem festgelegt, bei einer ankommenden Verbindung nur den
Modem-Modus zu verwenden:
# ----- port specific section ----- # Here you can put things that are valid only for one line, not the others # USR Sportster Vi 28.8, connected to ttyS0: don't do fax port ttyS0 data-only y rings 2
Parameterbeschreibung Auszug Datei /etc/mgetty+sendfax/mgetty.config :
port ttyS0 : Schnittstellenspezifische Definitionen für
Port ttyS0 ( = COM1 )
data-only y : spezifiziert die Klasse des am angegebenen Port
angeschlossenen Modems:
keine Verwendung des FAX-Modus, nur Daten-Modus
rings <n> : definiert die Anzahl der RING-Meldungen die
abgewartet werden bis 'mgetty' über das Modem abhebt
Schließlich ist dem "mgetty"-Prozess in der Datei
/etc/mgetty+sendfax/login.config noch mitzuteilen, bei einer erkannten
PPP-Anforderung automatisch den "pppd"-Prozess zu starten:
# Automatic PPP startup on receipt of LCP configure request. # mgetty has to be compiled with "-DAUTO_PPP" for this to work. # Warning: Case is significant, AUTOPPP or autoppp won't work! /AutoPPP/ - ppp /usr/sbin/pppd 38400
Parameterbeschreibung Auszug Datei /etc/mgetty+sendfax/mgetty.config :
38400 : setzt die zu verwendende Portgeschwindigkeit
(38400 Baud)
Dieses Verfahren birgt aber bei gleichzeitiger Verwendung des Modems am
Telefonhauptanschluß die Gefahr, daß "mgetty" bei jedem eingehenden
Telefonanruf abhebt. Diese Funktion ist aber nicht erwünscht, denn wer
unterhält sich schon gerne mit einem Modem.
"mgetty" bietet hierfür eine Lösung, "login"-Prozesse zeitweise zu
sperren. Durch Anlegen einer Datei namens /etc/nologin.<device> (hier
/etc/nologin/ttyS0) wird "mgetty" gehindert, einem eingehenden Anruf
selbstständig zu antworten.
Diese Funktion muß natürlich in den entsprechenden Anwahl-/Abwahlskripts,
beim Verbindungsende/-abbruch ("pppd"-Option "disconnect") bzw. beim
Hochlauf des Systemes als Standardeinstellung (in der Datei
/sbin/init.d/serial) definiert werden.
Die "login"-Sperre wird realisiert durch ein simples
touch /etc/nologin.ttyS0; chmod 666 /etc/nologin.ttyS0
Die "login"-Sperre kann wieder aufgehoben werden durch
rm -f /etc/nologin.ttyS0
Ein -unkommentiertes- Protokoll einer erfolgreichen PPP-Verbindungsaufnahme
via CHAP-Authentifizierung mit Rückruf ("User-Defined") durch den Windows
NT Server sieht folgendermaßen aus (der "chat"-Verbindungsaufbau ist nicht
mehr aufgeführt):
pppd: Using interface ppp0
pppd: Connect: ppp0 <--> /dev/ttyS0
pppd: sent [LCP ConfReq id=0x1 <mru 1500> <callback 0x605> \
06 6c ce 1f 62 07 02 08 02 00]
pppd: sent [LCP ConfReq id=0x1 <mru 1500> <callback 0x605> \
06 6c ce 1f 62 07 02 08 02 00]
pppd: rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap msoft> \
<magic 0x6b35> <pcomp> <accomp>]
pppd: sent [LCP ConfAck id=0x0 <asyncmap 0x0> <auth chap msoft> \
<magic 0x6b35> <pcomp> <accomp>]
pppd: rcvd [LCP ConfAck id=0x1 <mru 1500> <callback 0x605> \
06 6c ce 1f 62 07 02 08 02 07]
pppd: cbcp_lowerup
pppd: want: 6
pppd: rcvd [CHAP Challenge id=0x10 <349d61d2af2f5f75>, name = ""]
pppd: sent [CHAP Response id=0x10 <0000000000000000000000000000000 \
000000000000000004ee80271f4ad6170bfb6ffa5a866883f5bdf739e596162db01>, \
name = "my_login"]
pppd: rcvd [CHAP Success id=0x10 ""]
pppd: cbcp_open
pppd: rcvd [CBCP Request id=0x1 < NoCallback> 02 05 00 01 00]
pppd: length: 7
pppd: no callback allowed
pppd: length: 5
pppd: user callback allowed
pppd: cbcp_resp cb_type=6
pppd: cbcp_resp CONF_USER
pppd: sent [CBCP Response id=0x1 < UserDefined delay = 5 number = 555111>] \
35 35 35 31 31 31
pppd: rcvd [CBCP Ack id=0x1 < UserDefined delay = 5 number = 555111>] \
35 35 35 31 31 31
pppd: peer will call: 555111
pppd: sent [LCP TermReq id=0x2]
pppd: rcvd [LCP TermAck id=0x2]
pppd: Connection terminated.
pppd: Exit.
Interessant ist hierbei die Reaktion des Clients noch vor dem Request der CHAP-Authentifizierung durch Senden eines "Callback-Requests"
pppd: sent [LCP ConfReq ... <callback 0x605> ... ]
Dieser Request wird prompt beantwortet mit
pppd: rcvd [LCP ConfAck ... <callback 0x605> ... ]
um später nach der CHAP-Authentifizierung dem Windows NT Server die Telefonnummer mitzuteilen
pppd: sent [CBCP Response ... number = 555111>] ...
Diese Mitteilung wird vom Windows NT Server angenommen
pppd: rcvd [CBCP Ack ... number = 555111>] ...
Die bestehende Verbindung wird nun vom Client unterbrochen und auf den
Rückruf gewartet. Erfolgt der Rückruf, wird über den "mgetty"-Prozess das
"pppd"-Modul erneut aufgerufen, wobei nun keine Telefonnummer mitgegeben
werden darf. Der CHAP/PPP-Verbindungsaufbau erfolgt analog dem weiter oben
schon gezeigten Schema (Abschnitt 6.1).
Mit dieser Verfahrensweise sind die anfangs erwähnten Sicherheitsaspekte (MS-CHAP-Authentifizierung und "Callback"-Schema) erfüllt.
Um den unsicheren PAP/PPP-Zugang wieder zu unterbinden, kann nun auf dem Windows NT Server im Windows NT-Remote Access Service unter "Network Configuration" bei den "Encryption settings" der Punkt "Require Microsoft encrypted authentication" aktiviert werden, der nur noch CHAP/PPP-Verbindungen via MS-CHAP-Authentifizierung zuläßt.
Um den automatischen Rückruf im "Admin-Defined"-Modus zu aktivieren, muß
beim "pppd" die Option "cb" mit einer -beliebigen- Telefonnummer versorgt
werden (siehe Punkt 7.1). Die hier angebebene Nummer dient in diesem Falle
nur dazu, die "Callback"-Option des "pppd" zu aktivieren.
Ein -unkommentiertes- Protokoll einer erfolgreichen PPP-Verbindungsaufnahme
via CHAP-Authentifizierung mit Rückruf ("Admin Defined") durch den Windows
NT Server sieht folgendermaßen aus (der "chat"-Verbindungsaufbau ist nicht
mehr aufgeführt):
pppd: Using interface ppp0
pppd: Connect: ppp0 <--> /dev/ttyS0
pppd: sent [LCP ConfReq id=0x1 <mru 1500> <callback 0x605> \
< 06 0a 3f 4c 0b 07 02 08 02 00>]
pppd: sent [LCP ConfReq id=0x1 <mru 1500> <callback 0x605> \
< 06 0a 3f 4c 0b 07 02 08 02 00>]
pppd: rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap msoft> \
<magic 0x81f> <pcomp> <accomp>]
pppd: sent [LCP ConfAck id=0x0 <asyncmap 0x0> <auth chap msoft> \
<magic 0x81f> <pcomp> <accomp>]
pppd: rcvd [LCP ConfAck id=0x1 <mru 1500> <callback 0x605> \
< 06 0a 3f 4c 0b 07 02 08 02 07>]
pppd: cbcp_lowerup
pppd: want: 14
pppd: rcvd [CHAP Challenge id=0x4 <9c0cceb72ffbbd37>, name = ""]
pppd: sent [CHAP Response id=0x4 <000000000000000000000000000000000000000000 \
0000386515129f151f5b2dca1092bd45b11bf0d25a2bbe7dc26801>, \
name = "my_login"]
pppd: rcvd [CHAP Success id=0x4 ""]
pppd: cbcp_open
pppd: rcvd [CBCP Request id=0x1 < AdminDefined delay = 0>]
pppd: length: 3
pppd: user admin defined allowed
pppd: cbcp_resp cb_type=8
pppd: cbcp_resp CONF_ADMIN
pppd: sent [CBCP Response id=0x1 < AdminDefined delay = 5 number = >]
pppd: rcvd [CBCP Ack id=0x1 < AdminDefined delay = 5 number = >]
pppd: sent [LCP TermReq id=0x2]
pppd: rcvd [LCP TermAck id=0x2]
pppd: Connection terminated.
pppd: Exit.
Interessant ist hierbei die Reaktion des Clients noch vor dem Request der CHAP-Authentifizierung durch Senden eines "Callback-Requests"
pppd: sent [LCP ConfReq ... <callback 0x605> ... ]
Dieser Request wird prompt beantwortet mit
pppd: rcvd [LCP ConfAck ... <callback 0x605> ... ]
um später nach der CHAP-Authentifizierung dem Windows NT Server die Antwort auf die "Admin-Defined" Callback-Vorgabe
pppd: rcvd [CBCP Request id=0x1 < AdminDefined delay = 0>]
mitzuteilen
pppd: sent [CBCP Response ... number = >] ...
Diese Mitteilung wird vom Windows NT Server angenommen
pppd: rcvd [CBCP Ack ... number = >] ...
Die bestehende Verbindung wird nun vom Client unterbrochen und auf den
Rückruf gewartet. Erfolgt der Rückruf, wird über den "mgetty"-Prozess das
"pppd"-Modul erneut aufgerufen, wobei nun keine Telefonnummer mitgegeben
werden darf. Der CHAP/PPP-Verbindungsaufbau erfolgt analog dem weiter oben
schon gezeigten Schema (Abschnitt 6.1).
Desweiteren gelten auch für diese Variante die unter Abschnitt 7.3 genannten Aussagen.
Die Transaktionen des "mgetty"-Prozesses können durch
tail -f /tmp/log_mg.ttyS0
beim Verbindungsaufbau am Bildschirm mitprotokolliert werden.
Nachfolgend ein -unkommentiertes- Protokoll einer erfolgreichen
PPP-Verbindungsaufnahme über den "mgetty"-Prozess via
CHAP-Authentifizierung mit Rückruf durch den Windows NT Server.
yS0 mgetty: experimental test release 0.99-May31
yS0 reading configuration data for port 'ttyS0'
yS0 check for lockfiles
yS0 checklock: stat failed, no file
yS0 locking the line
yS0 makelock(ttyS0) called
yS0 do_makelock: lock='/var/lock/LCK..ttyS0'
yS0 lock made
yS0 lowering DTR to reset Modem
yS0 tss: set speed to 38400 (017)
yS0 tio_set_flow_control( HARD )
yS0 waiting for line to clear (VTIME), read: [0d][0a]NO CARRIER[0d][0a]
yS0 send: \d\d\d+++\d\d\d[0d]\dATQ0V1H0[0d]
yS0 waiting for ``OK''
yS0 got: +++[0d]
yS0 CND: +++[0a]RING[0d]
yS0 CND: RING[0a][0d]ATQ0V1H0[0d]
yS0 CND: ATQ0V1H0[0d][0a]OK ** found **
yS0 send: ATS0=0Q0&D3&C1[0d]
yS0 waiting for ``OK''
yS0 got: [0d]
yS0 CND: OK[0a]ATS0=0Q0&D3&C1[0d]
yS0 CND: ATS0=0Q0&D3&C1[0d][0a]OK ** found **
yS0 waiting for line to clear (VTIME), read: [0d][0a]
yS0 removing lock file
yS0 waiting...
yS0 select returned 1
yS0 checking lockfiles, locking the line
yS0 makelock(ttyS0) called
yS0 do_makelock: lock='/var/lock/LCK..ttyS0'
yS0 lock made
yS0 waiting for ``RING''
yS0 got: [0d]
yS0 CND: OK[0a]RING ** found **
yS0 send: ATA[0d]
yS0 waiting for ``CONNECT''
yS0 got: [0d]
yS0 CND: RING[0a]ATA[0d]
yS0 CND: ATA[0d][0a]CONNECT ** found **
yS0 send:
yS0 waiting for `` ''
yS0 got: 28800/ARQ/V34/LAPM[0d]
yS0 CND: CONNECT 28800/ARQ/V34/LAPM
yS0 CND: found: 28800/ARQ/V34/LAPM[0a] ** found **
yS0 waiting for line to clear (VTIME), read:
yS0 looking for utmp entry... (my PID: 2412)
yS0 utmp + wtmp entry made
yS0 tio_set_flow_control( HARD )
yS0 getlogname, read:~[ff][03]
yS0 getlogname, read:[c0]!
yS0 input finished with '\r', setting ICRNL ONLCR
yS0 login: use login config file /etc/mgetty+sendfax/login.config
yS0 match: user='/AutoPPP/', key='/FIDO/'
yS0 match: user='/AutoPPP/', key=''
yS0 match: user='/AutoPPP/', key='/AutoPPP/'*** hit!
yS0 login: utmp entry: ppp
yS0 looking for utmp entry... (my PID: 2412)
yS0 utmp + wtmp entry made
yS0 calling login: cmd='/usr/sbin/pppd', argv[]='pppd 38400 ' \
08/28 19:23:14 ##### data dev=ttyS0, pid=2412, caller=none, \
conn='28800/ARQ/V34/LAPM', name='', cmd='/usr/sbin/pppd', \
user='/AutoPPP/'
...
... ... Aufruf von pppd nach erfolgtem Rückruf
... ... und Warten auf Verbindungsende
...
yS0 check for lockfiles
yS0 checklock: no active process has lock, will remove
yS0 locking the line
yS0 makelock(ttyS0) called
yS0 do_makelock: lock='/var/lock/LCK..ttyS0'
yS0 lock made
yS0 lowering DTR to reset Modem
yS0 tss: set speed to 38400 (017)
yS0 tio_set_flow_control( HARD )
yS0 waiting for line to clear (VTIME), read: [0a][0a]NO CARRIER \
[0a][0a][0a][0a][0a][0a]NO CARRIER[0a][0a]...... \
[0a]NO CARRIER[0a][0a][0a][0a][0a][0a][0a][0a]
yS0 clean_line: only 500 of 3124 bytes logged
yS0 send: \d\d\d+++\d\d\d[0d]\dATQ0V1H0[0d]
yS0 waiting for ``OK''
yS0 got: +++[0d]
yS0 CND: +++ATQ0V1H0[0d]
yS0 CND: ATQ0V1H0[0d][0a]OK ** found **
yS0 send: ATS0=0Q0&D3&C1[0d]
yS0 waiting for ``OK''
yS0 got: [0d]
yS0 CND: OK[0a]ATS0=0Q0&D3&C1[0d]
yS0 CND: ATS0=0Q0&D3&C1[0d][0a]OK ** found **
yS0 waiting for line to clear (VTIME), read: [0d][0a]
yS0 removing lock file
yS0 waiting...