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