Figura 200.6. Schema di esempio della distribuzione degli indirizzi IPv4. Per risparmiare numeri IP viene dato lo stesso numero assegnato all'interfaccia eth0 anche alla parte locale dei collegamenti PPP.
|
|
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico] [volume] [parte]
Per concedere un accesso a Internet attraverso una connessione telefonica, così come fa normalmente un fornitore di accesso a Internet, si può predisporre un sistema GNU munito di molte porte seriali e di altrettanti modem in attesa di chiamata. In questo capitolo non vengono presentati i problemi tecnici legati all'installazione di una scheda seriale multipla, dal momento che questi variano da modello a modello, mentre ci si vuole concentrare sulla configurazione di Getty e sull'attivazione del protocollo PPP.
Nel capitolo si fa riferimento a programmi e a concetti già presentati in precedenza, che vengono richiamati per favorire il lettore.
Dovendo gestire le porte seriali, è opportuno preoccuparsi della loro impostazione, che con i sistemi GNU/Linux si ottiene attraverso il programma setserial, già descritto nel capitolo 192. Per questo si realizza solitamente uno script da includere nella procedura di inizializzazione del sistema. Potrebbe trattarsi di /etc/rc.d/rc.serial, o qualcosa di simile. Il suo contenuto potrebbe assomigliare all'esempio che segue:
|
Se si utilizza una scheda seriale multipla, è molto probabile che si debba indicare lo stesso IRQ per tutte le porte, mentre queste si distinguono solo in base agli indirizzi di I/O. Nello stesso modo, potrebbe essere necessario specificare più elementi, come il tipo di UART, e forse delle opzioni spd_* (purché siano tollerate dal kernel).
Una volta configurate le porte, prima di procedere oltre, è necessario fare degli esperimenti collegando un modem e comunicando con questo attraverso un programma per la gestione del terminale, come Minicom. Con qualche comando AT si può verificare se il collegamento tra il modem e l'elaboratore è funzionante, oppure se la porta seriale richiede qualche accorgimento di configurazione ulteriore.
Il pacchetto Getty_ps, precisamente il programma uugetty, non rappresenta la scelta ottima per risolvere il problema dell'accesso da un terminale seriale, attraverso la linea commutata e il modem. Tuttavia, la sua semplicità permette di comprendere meglio ciò che si fa.
uugetty richiede la presenza del file /etc/gettydefs, che serve a definire le caratteristiche elementari dei diversi tipi di linea. Nel caso delle connessioni via modem da linea commutata, sono necessarie in particolare le direttive seguenti:(1)
|
Una volta verificata la presenza di questo file e dopo aver visto che il contenuto è corretto, si possono predisporre i file di configurazione di ogni linea, che generalmente vengono collocati nella directory /etc/default/. L'esempio seguente fa riferimento alla prima porta seriale, /dev/ttyS0, che si concretizza nel file /etc/default/uugetty.ttyS0.
Se si è sicuri che i dispositivi obsoleti per le chiamate in uscita, contrassegnati dai file /etc/cua*, non vengono utilizzati, si può realizzare un solo file di configurazione per tutte le linee seriali gestite, ammesso che si abbiano a disposizione gli stessi modem, o almeno che questi accettino le stesse sequenze di inizializzazione.
|
Infine, occorre inserire la chiamata di uugetty nel file /etc/inittab, con una riga per ogni porta seriale a cui corrisponda un modem gestito effettivamente.
|
È bene ricordare che il numero 115 200 indicato tra gli argomenti, fa riferimento alla voce corrispondente nel file /etc/gettydefs, che precisamente è quella seguente:
|
Se per qualche motivo si ritiene di voler iniziare da una velocità più bassa, basta cambiare questo argomento, per esempio con 57 600, 38 400,...
Quando si utilizza un programma come uugetty per controllare le porte seriali e i modem in attesa di una chiamata, l'utente che accede è sottoposto a una procedura di autenticazione tradizionale (Unix), con la quale si deve inserire un nominativo-utente e una parola d'ordine. In questa situazione, la connessione PPP, per mezzo del programma pppd, viene avviata dopo il riconoscimento dell'utente, nel modo che viene mostrato più avanti in questo capitolo.
Il protocollo PPP, ma pppd in particolare, prevede delle forme di autenticazione autonome che richiedono la conoscenza di altri problemi. Prima di affrontarli, è necessario comprendere bene il funzionamento del sistema tradizionale di autenticazione. Per il momento ci si limita a trattare il PPP come un protocollo senza alcun sistema di autenticazione.
Uno dei problemi che riguardano l'attivazione del PPP è quello della definizione dinamica degli indirizzi IPv4. Di solito si deve fare in modo che per ogni modem disponibile in ricezione venga assegnato lo stesso indirizzo IP remoto, cioè quello abbinato al nodo dell'utente che si connette attraverso il telefono. L'indirizzo IP locale può essere sempre lo stesso, tanto che di solito si tratta anche di uno già utilizzato per un'altra interfaccia di rete, dal momento che non viene definito alcun instradamento sul lato locale della connessione PPP.
A titolo di esempio si può decidere di utilizzare gli indirizzi seguenti:
192.168.11.10 per il dispositivo /etc/ttyS0;
192.168.11.11 per il dispositivo /etc/ttyS1;
ecc.
Dalla parte locale si può decidere di usare sempre l'indirizzo 192.168.11.1. Si osservi la figura 200.6
|
Figura 200.6. Schema di esempio della distribuzione degli indirizzi IPv4. Per risparmiare numeri IP viene dato lo stesso numero assegnato all'interfaccia eth0 anche alla parte locale dei collegamenti PPP.
|
La soluzione del problema dell'assegnazione degli indirizzi IP si risolve con i file di configurazione di pppd distinti in base al dispositivo seriale attraverso cui si intende convogliare il protocollo. Si comincia generalmente dalla configurazione generale del file /etc/ppp/options, che è sempre bene ridurre al minino, in modo da non rischiare interferenze con tutti i modi diversi in cui si pensa di utilizzare pppd. L'esempio seguente è decisamente minimo.
|
Tuttavia, è opportuno anticipare quali opzioni potrebbero essere aggiunte nella riga di comando di pppd per le connessioni senza autenticazione da parte del PPP.
|
Eventualmente si potrebbe decidere di aggiungere la direttiva netmask 255.255.255.255 che è la più appropriata nelle connessioni punto-punto. Tuttavia, in condizioni normali, questa viene determinata automaticamente.
Si osservi la direttiva ms-dns che permette agli utenti che accedono attraverso il sistema operativo MS-Windows di ottenere automaticamente l'indicazione dell'indirizzo IP del servente DNS.
pppd permette di definire una serie di altri file di configurazione che servono a contenere le direttive specifiche per ogni linea di terminale, composti con un nome che rispetti il modello /etc/ppp/options.linea. Per tornare all'esempio presentato, le particolarità della connessione attraverso la prima porta seriale potrebbero essere inserite nel file /etc/ppp/options.ttyS0. In pratica, si tratta di definire solo gli indirizzi IP.
|
L'esempio si riferisce alla prima porta seriale, dove si vuole indicare che l'indirizzo locale è 192.168.11.1, mentre quello all'altro capo della connessione è 192.168.11.10. Volendo sistemare la seconda porta seriale, occorrerebbe creare il file /etc/ppp/options.ttyS1 con il contenuto seguente:
|
Per fare in modo che dopo l'identificazione avvenuta tramite una procedura di accesso tradizionale (login) venga attivato il PPP, occorre abbinare agli utenti una shell speciale: uno script che avvia pppd. Questo script potrebbe essere più o meno complesso, per esempio allo scopo di verificare se l'utente ha diritto di accedere in base alle fasce orarie che gli sono state concesse, o secondo altri criteri. Alla fine, si deve avviare pppd chiudendo il processo che interpretava lo script (il comando exec).
|
L'esempio appena mostrato fa riferimento alla possibilità che l'utilizzo di risorse da parte degli utenti sia controllato da Acua. Se il programma acua_login restituisce un valore diverso da zero, viene eseguito il comando exit (cosa che produce la conclusione della connessione) e l'utente non può accedere.
Supponendo di avere collocato questo script nella directory /usr/bin/ e di averlo chiamato utente_ppp, si deve abbinare tale file agli utenti, in qualità di shell. Così, nel file /etc/passwd può apparire qualcosa come nell'esempio seguente:
|
Naturalmente, per evitare conflitti con i controlli del sistema di autenticazione, è necessario aggiungere tale shell nell'elenco del file /etc/shells.
|
|
È importante tenere presente che in questo modo, il programma pppd deve poter essere avviato dagli utenti comuni; di conseguenza, è necessario attivare il bit SUID e fare in modo che appartenga all'utente root. |
# chmod u+s /usr/sbin/pppd[Invio]
# chown root /usr/sbin/pppd[Invio]
Il bello della connessione PPP è che il programma pppd provvede da solo a definire le interfacce di rete ppp* e a inserire gli instradamenti corretti. Quindi, se la configurazione di pppd è fatta correttamente, non occorre pensare ad altro.
Il problema rimane semmai nella gestione dell'inoltro dei pacchetti verso le altre interfacce, specialmente verso quella che permette di raggiungere la rete esterna. In pratica, nel caso di un sistema GNU/Linux occorre che il kernel del sistema sia disponibile al funzionamento come router e che il file virtuale /proc/sys/net/ipv4/ip_forward contenga il valore 1.
# echo 1 > /proc/sys/net/ipv4/ip_forward[Invio]
Secondo quanto mostrato fino a questo punto, gli utenti che accedono al servizio PPP attraverso la linea commutata non hanno alcun modo di utilizzare i comandi del sistema operativo. Questa è una cosa positiva: sarebbe difficile dormire sonni tranquilli trovandosi a gestire un centinaio di utenti che se vogliono possono allenarsi a fare i pirati nel proprio elaboratore. Tuttavia, ci sono alcune cose che sarebbe bene tali utenti potessero fare; per esempio: cambiare la parola d'ordine e controllare l'utilizzo delle risorse che gli competono.
Lo script seguente ricalca quello già visto nella sezione precedente, con la differenza che è scritto in Perl e che prima di attivare il PPP presenta un menù di opzioni, dove basta un ritorno a carrello aggiuntivo perché il servizio si avvii, ammesso che l'accesso provenga da una linea seriale.
|
Nello stesso modo in cui viene avviato passwd, o acua, si potrebbe avviare una shell vera e propria, ma questo è meglio evitarlo se non si conoscono perfettamente le conseguenze.
Se si vuole fare in modo che sia il PPP a prendersi cura dell'identificazione di chi accede, bisogna fare un piccolo sforzo per comprendere che non c'è più il sostegno della procedura normale di autenticazione. Cioè non c'è più il sistema Getty + login + shell.
Di solito si utilizza pppd con l'opzione login per fare in modo che riconosca gli utenti registrati nel sistema, senza dover creare appositamente il file /etc/ppp/pap-secrets (anche se comunque è necessario che questo contenga almeno una voce particolare con cui si accettano tutti i clienti con qualunque segreto).
Il demone pppd deve anche essere in grado di annotare gli accessi nel sistema dei file /var/run/utmp e /var/log/wtmp.(2)
Anche se si utilizza un sistema di autenticazione attraverso il PPP, è necessario un altro programma che controlli il modem. Questo è generalmente mgetty (Mgetty+Sendfax), che in più riesce a gestire simultaneamente anche il sistema tradizionale di autenticazione: se si accorge che il cliente che accede si presenta subito con il protocollo PPP, avvia pppd, altrimenti presenta la richiesta di autenticazione tramite una procedura di accesso tradizionale.
Utilizzando un sistema Unix è improbabile che si voglia gestire un'autenticazione diversa da PAP, dal momento che pppd è in grado di sfruttare le informazioni sugli utenti registrati nel sistema (il file /etc/passwd) solo con tale protocollo. Comunque, il file /etc/ppp/pap-secrets deve contenere una voce generica, come nell'esempio seguente:
|
Per quanto riguarda il contenuto del file /etc/ppp/options, vale quanto già suggerito in precedenza: indicare solo l'indispensabile. Infatti, se si usa Mgetty+Sendfax per consentire sia un'autenticazione tradizionale, sia quella del PPP, è necessario evitare l'uso di opzioni che possono essere incompatibili con una o con l'altra modalità.
|
Per quanto riguarda le altre opzioni necessarie per questo tipo di connessione, occorre tenere presente che l'autenticazione del nodo remoto diventa obbligatoria (auth), inoltre si deve usare il sistema PAP (require-pap) con l'opzione login.
|
Per quanto riguarda il problema dell'assegnazione degli indirizzi IP dinamici, vale la stessa configurazione dei file /etc/ppp/options.ttyS* già descritti per l'uso con il PPP senza autenticazione.
Mgetty+Sendfax è già stato introdotto in più parti di questo documento. Se il cliente si presenta senza tentare una connessione PPP, mgetty richiede un'autenticazione manuale nel modo solito, avviando alla fine la shell dell'utente come è già stato visto nel caso di uugetty.
Come nel caso di uugetty il problema maggiore è quello di definire una sequenza di comandi per inizializzare correttamente il modem, possibilmente trovando quella che si adatta alla maggior parte dei modelli disponibili. Tuttavia, a questo proposito, l'eseguibile mgetty permette di utilizzare anche la riga di comando, facilitando ancora di più la cosa all'amministratore.
Per abilitare l'avvio automatico del PPP occorre intervenire nel file /etc/mgetty+sendfax/login.config con un record simile a quello seguente (che viene spezzato per motivi tipografici, ma nella realtà deve utilizzare una sola riga).
|
mgetty può registrare l'avvio di pppd nei file /var/run/utmp e /var/log/wtmp. Dal momento che, quando si avvia per rispondere a una chiamata, i privilegi del processo sono quelli dell'utente root, considerando anche che mgetty non può sapere chi sia l'utente, se l'autenticazione la fa il PPP si può aggiungere quel nome, a_ppp, nel terzo campo di questo record. Questo nome serve per segnalare la presenza di un accesso avvenuto in tal modo attraverso programmi come w, who o finger. Se pppd è in grado di fare questa registrazione per conto suo, utilizzando il nominativo acquisito con il protocollo di autenticazione PAP, allora si può sostituire a_ppp con un trattino, -, per evitare che mgetty provveda in questo modo.
Quando si concede di accedere attraverso il PPP, con l'autenticazione PAP che si basa sugli utenti del sistema, i clienti possono presentarsi con l'identità di qualunque utente che abbia una parola d'ordine valida. A volte, questa non è la situazione che si desidera; spesso si usano dei trucchetti basati semplicemente sul tipo di shell che viene assegnata a un utente, per limitarne o impedirne l'accesso.
A fianco di questo problema, si aggiunge la possibile necessità di controllare l'utilizzo delle risorse da parte di questi clienti, cioè degli utenti che sfruttano la connessione PPP. L'unica possibilità offerta da pppd è quella di predisporre lo script /etc/ppp/ip-up, che tuttavia ha lo svantaggio di essere avviato semplicemente, senza che pppd attenda la sua conclusione per continuare a mantenere la connessione. Qui viene presentato uno script in Perl in grado di verificare che l'utente (il cliente) disponga della shell prevista (precisamente quella che gli permetterebbe una connessione PPP dopo un'autenticazione tradizionale), mettendo quindi il processo sotto il controllo di Acua. Se per qualche motivo l'utente deve essere estromesso, viene inviato un segnale di interruzione al processo corrispondente a pppd.
|
Appunti di informatica libera 2006.07.01 --- Copyright © 2000-2006 Daniele Giacomini -- <daniele (ad) swlibero·org>
1) Alcune direttive sono spezzate in due righe per motivi tipografici.
2) Da quanto si legge nella documentazione di pppd, questo è predisposto per annotare esclusivamente le connessioni autenticate attraverso il protocollo PAP con l'opzione login, precisamente nel file /var/log/wtmp. Purtroppo sono esistite alcune versioni che utilizzando le librerie PAM non funzionavano correttamente.
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome consentire_l_x0027_accesso_a_internet_attraverso_una_linea_c.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico]
