PPP sta per Point to Point Protocol; si tratta di un protocollo adatto alle connessioni punto-punto (point-to-point) nel senso che è fatto per mettere in comunicazione solo due punti tra di loro (di solito due elaboratori).
Il PPP è un protocollo piuttosto complesso e ricco di possibilità. Consente la connessione attraverso linee seriali dirette o provviste di modem (ovvero di altri apparecchi simili, come nel caso delle linee ISDN). Può instaurare una connessione anche attraverso un collegamento preesistente, sfruttando il flusso di standard input e standard output.
Generalmente, il PPP viene utilizzato per trasportare altri protocolli, fondamentalmente IP, anche se non si tratta dell'unica possibilità. Questo, tra le altre cose, permette l'assegnazione (statica o dinamica) degli indirizzi IP, consentendo in pratica a una delle due parti di ignorare il proprio fino a che non viene instaurata la connessione.
Il PPP può gestire un sistema di autenticazione, attraverso il quale, una, o entrambe le parti, cercano di ottenere dall'altra delle informazioni necessarie a riconoscerla. A questo proposito possono essere usati due modi di autenticazione: PAP e CHAP. Nella connessione PPP non esiste un client e un server, tuttavia, per quanto riguarda il problema dell'autenticazione, si considera client quel nodo che si fa riconoscere, attraverso uno di questi protocolli PAP o CHAP, presso l'altro, che così è il server. Tuttavia, la richiesta di autenticazione è facoltativa, e si può benissimo instaurare una connessione senza alcuna autenticazione, se nessuna delle due parti ne fa richiesta all'altra. Inoltre, la richiesta di identificazione può anche anche essere reciproca; in tal caso entrambi i nodi che si connettono sono sia client che server a fasi alterne.
Per poter utilizzare il protocollo PPP, è necessario che il kernel sia predisposto per farlo. Naturalmente, lo stesso kernel deve poter gestire la rete.
PPP (point-to-point) support ( 19.2.9) Y
Se il supporto al PPP è stato inserito nella parte principale del kernel, cioè non è stato lasciato in un modulo, si può trovare tra i messaggi di avvio qualcosa come l'esempio mostrato di seguito.
$ dmesg | less[Invio]
PPP: version 2.3.3 (demand dialling) PPP line discipline registered. |
Se invece si tratta di una funzionalità gestita attraverso un modulo, questa dovrebbe attivarsi automaticamente al momento del bisogno.
GNU/Linux dispone generalmente del demone pppd per la gestione del protocollo PPP. Si è accennato al fatto che il PPP non prevede un client e un server, anche se questi termini si usano per distinguere le parti nella fase di autenticazione, e in questo senso questo programma serve sia per attendere una connessione che per iniziarla.
Il demone pppd deve amministrare un sistema piuttosto complesso di file di configurazione e di possibili script di contorno. La maggior parte di questi dovrebbe trovarsi nella directory /etc/ppp/, e tra tutti, il file più importante è /etc/ppp/options, all'interno del quale vanno indicate le opzioni di funzionamento che si vogliono attivare in generale.
pppd può essere configurato completamente attraverso le opzioni della riga di comando. Quanto definito in questo modo prende il sopravvento su qualunque altro tipo di configurazione, e quindi, si utilizza tale metodo solo per variare le impostazioni definite altrimenti.
Il file di configurazione principale è /etc/ppp/options; è il primo a essere letto e, teoricamente, tutti i file di configurazione successivi possono modificare quanto definito al suo interno.
Successivamente, se esiste, viene letto il file ~/.ppprc, che potrebbe essere contenuto nella directory personale dell'utente che avvia il processo. In generale, dato il ruolo che ha il programma pppd, non si usano configurazioni personalizzate degli utenti, e quindi questo file non dovrebbe esistere.
Per ultimo viene letto un file di configurazione il cui nome dipende dal tipo di dispositivo utilizzato per instaurare la connessione. Data la natura del protocollo PPP, il dispositivo in questione corrisponde generalmente a una porta seriale (/dev/ttyS*); così, questo file di configurazione specifico avrà un nome che corrisponde al modello /etc/ppp/options.ttyS*, e il suo scopo è quello di definire dei dettagli che riguardano la connessione attraverso la linea corrispondente.
A titolo di esempio viene anticipato come potrebbe apparire un file di configurazione di questo tipo. Si osservi il fatto che le righe bianche e quelle vuote vengono ignorate, inoltre, il simbolo # indica l'inizio di un commento che si conclude alla fine della riga.
# /etc/ppp/options # Attiva il controllo di flusso hardware (RTS/CTS). crtscts # Vengono utilizzati i file di lock in stile uucp. lock # Utilizza un modem. modem |
Si è accennato al fatto che il PPP può gestire un sistema autonomo di autenticazione. pppd è in grado di utilizzare due tecniche: PAP (Password Authentication Protocol) e CHAP (Challenge Handshake Authentication Protocol).
Questi sistemi si basano sulla conoscenza da parte di entrambi i nodi di alcune informazioni «segrete» (si parla precisamente di secret), che vengono scambiate in qualche modo e verificate prima di attuare la connessione.
È il caso di ribadire che si tratta di procedure opzionali, e che dipende da ognuno dei due nodi stabilire se si pretende che l'altra parte si identifichi prima di consentire la connessione.
Per utilizzare queste forme di autenticazione, occorre stabilire un nome e un segreto (in pratica una password) per il nodo che deve potersi identificare. L'altra parte dovrà disporre di questa informazione per poterla confrontare quando gli viene fornita.
Il protocollo PAP prevede che una parte invii all'altra il proprio nome e il segreto (cioè la password) che verrà utilizzato per consentire o meno la connessione. Il protocollo CHAP prevede invece che una parte, mentre chiede all'altra di identificarsi invii prima il proprio nome, e attenda come risposta il nome dell'altra parte e il segreto relativo da verificare. La differenza fondamentale sta nel fatto che con il PAP, una parte inizia a identificarsi anche senza sapere chi sia la controparte, mentre nel caso del CHAP, l'identificazione viene generata in funzione del nome della controparte.
Questi segreti sono conservati nel file /etc/ppp/pap-secrets per il protocollo PAP, e nel file /etc/ppp/chap-secrets per il protocollo CHAP. Le informazioni contenute in questi file possono servire per identificare se stessi nei confronti dell'altra parte, oppure per verificare l'identità della controparte.
A titolo di esempio, si potrebbe osservare il testo seguente che rappresenta il contenuto del file /etc/ppp/chap-secrets del nodo dinkel.
# Segreti per l'autenticazione CHAP dalla parte del nodo «dinkel» # client server segreto indirizzi IP ammissibili dinkel roggen ciao * |
In tal caso, se il nodo remoto inizia una richiesta CHAP identificandosi con il nome roggen, gli si risponde con il nome dinkel abbinato alla password ciao. Dall'altra parte, il file dei segreti CHAP corrispondente dovrebbe avere lo stesso contenuto.
# Segreti per l'autenticazione CHAP dalla parte del nodo «roggen» # client server segreto indirizzi IP ammissibili dinkel roggen ciao * |
In questi termini, nell'ambito delle forme di autenticazione usate da pppd, si parla di client per indicare il nodo che deve identificarsi di fronte alla controparte, e di server per indicare la parte che richiede all'altra di identificarsi. In questa logica, le voci dei file /etc/ppp/*-secrets restano uguali quando si passa da una parte all'altra.
C'è da aggiungere che l'identità di un nodo non è definita dai file /etc/ppp/*-secrets, ma dalle opzioni che vengono date a pppd, per cui, se il nodo roggen vuole potersi identificare di fronte a dinkel, si può aggiungere la voce relativa nei file rispettivi.
# Segreti per l'autenticazione CHAP dalla parte del nodo «dinkel» # client server segreto indirizzi IP ammissibili dinkel roggen ciao * roggen dinkel medusa * |
# Segreti per l'autenticazione CHAP dalla parte del nodo «roggen» # client server segreto indirizzi IP ammissibili dinkel roggen ciao * roggen dinkel medusa * |
Da quello che si legge in quest'ultimo esempio: dinkel utilizza il segreto ciao per identificarsi nei confronti di roggen; roggen utilizza il segreto medusa per identificarsi nei confronti di dinkel.
La sintassi del file /etc/ppp/pap-secrets è la stessa, con la differenza che sono ammissibili delle semplificazioni che verranno descritte in seguito.
pppd, quando riesce a instaurare una connessione, definisce dinamicamente un'interfaccia di rete pppn, dove n è un numero che inizia da 0. Per questo, e per altri motivi, pppd deve funzionare con i privilegi dell'utente root. In tal senso, la collocazione normale di questo programma è la directory /usr/sbin/.
Può darsi che si voglia concedere l'utilizzo di pppd a utenti comuni; in tal caso si può attivare il bit SUID, tenendo conto dei pericoli potenziali che questa scelta può causare.
# chmod u+s /usr/sbin/pppd
Tuttavia, pppd riesce ugualmente a distinguere se l'utente che lo ha avviato è root (nella documentazione originale si parla di utente privilegiato), oppure se si tratta solo di un utente comune. Ciò serve per impedire l'utilizzo di opzioni delicate agli utenti comuni.
Di solito, questa distinzione si realizza nell'impossibilità da parte degli utenti comuni di utilizzare talune opzioni che annullino l'effetto di altre stabilite nella configurazione generale del file /etc/ppp/options. Questo vincolo non è generalizzato, ma riguarda solo alcune situazioni che verranno descritte nel momento opportuno.
pppd può avviare degli script di contorno, in presenza di determinate circostanze. Questi possono essere diversi, ma in particolare, quando si gestiscono connessioni IP, sono importanti /etc/ppp/ip-up e /etc/ppp/ip-down. Il primo di questi due viene avviato subito dopo una connessione e l'instaurazione di un collegamento IP tra le due parti; il secondo viene eseguito quando questo collegamento viene interrotto. Questi due script ricevono gli argomenti seguenti.
<interfaccia> <dispositivo-linea> <velocità-bps> <indirizzo-ip-locale> <indirizzo-ip-remoto> <opzione-ipparam> |
Ogni distribuzione GNU/Linux potrebbe adattare questi script alle proprie esigenze particolari, in modo da rendere uniforme la gestione della rete. In generale, questi file potrebbero essere vuoti del tutto; il loro contenuto generico è quello seguente:
#!/bin/sh # # This script is called with the following arguments: # Arg Name Example # $1 Interface name ppp0 # $2 The tty ttyS1 # $3 The link speed 38400 # $4 Local IP number 12.34.56.78 # $5 Peer IP number 12.34.56.99 # # # The environment is cleared before executing this script # so the path must be reset # PATH=/usr/sbin:/sbin:/usr/bin:/bin export PATH # last line |
Il sesto argomento, deriva eventualmente dall'uso dell'opzione ipparam di pppd.
Dopo l'introduzione delle sezioni precedenti è il caso di affrontare in modo un po' più dettagliato l'uso di pppd. La sintassi per l'avvio di questo programma è apparentemente molto semplice.
pppd [<opzioni>] |
Queste opzioni possono apparire indifferentemente nella riga di comando, come si vede dalla sintassi, oppure nei vari file di configurazione, tenendo conto che quelle indicate sulla riga di comando hanno il sopravvento su tutto (ammesso che ciò sia consentito all'utente che avvia pppd).
Le opzioni sono di vario tipo, e a seconda di questo possono essere usate in certi modi determinati.
<dispositivo-di-comunicazione>
Tra gli argomenti della riga di comando o tra le opzioni di un file di configurazione, può apparire il percorso completo del file di dispositivo corrispondente alla linea utilizzata. Dato l'uso che si fa solitamente di pppd, si tratta normalmente di qualcosa che rispetta il modello /dev/ttyS*.
Se manca l'indicazione di tale dispositivo, pppd utilizza direttamente quello del terminale attraverso il quale è stato avviato.
<velocità>
Tra gli argomenti della riga di comando o tra le opzioni di un file di configurazione, può apparire un numero puro e semplice, che rappresenta la velocità di comunicazione in bps. I valori utilizzabili dipendono molto anche dal sistema operativo utilizzato, e per quanto riguarda GNU/Linux si tratta di quelli che si possono indicare nella configurazione delle porte seriali.
<indirizzo-IP-locale>:<indirizzo-IP-remoto>
<indirizzo-IP-locale>:
:<indirizzo-IP-remoto>
Due numeri IP, separati da due punti verticali (:), come si vede dai modelli, rappresentano rispettivamente l'indirizzo del nodo locale e quello del nodo remoto. Gli indirizzi possono essere forniti in notazione decimale puntata o in forma di nome. In condizioni normali, il valore predefinito di quello locale è il primo indirizzo IP del sistema. Il valore predefinito dell'indirizzo dell'elaboratore remoto si ottiene dallo stesso nodo remoto se non viene indicato esplicitamente in alcuna opzione. L'indirizzo 0.0.0.0 equivale a fare riferimento espressamente a quello predefinito, sia per la parte locale che per quella remota.
<opzione> <argomento>
Un buon numero di opzioni di pppd prevede l'indicazione di un argomento successivo. Il loro uso dovrebbe essere intuitivo; in particolare, l'argomento potrebbe essere composto da più informazioni, ma si deve trattare sempre di un corpo unico.
<opzione-booleana>
Le opzioni rimanenti hanno significato solo in modo binario, ovvero in modo booleano. L'indicazione di queste parole chiave manifesta l'attivazione della modalità che rappresentano.
Nel passato, l'uso di queste opzioni è stato un po' contorto. Occorre tenere conto di alcune cose: se la parola chiave inizia con no, dovrebbe intendersi che si tratti della disattivazione di qualcosa, secondo il senso che avrebbe leggendola in inglese; inoltre, per un problema di compatibilità con il passato, si può invertire il senso di alcune opzioni booleane facendo precedere la parola chiave relativa dal segno -. Per complicare ulteriormente le cose, alcune opzioni booleane, e non necessariamente le stesse appena descritte, possono avere l'aggiunta del segno + anteriormente, per confermare il senso verbale della parola chiave relativa.
Per esempio, crtscts rappresenta la gestione del controllo di flusso hardware, e nocrtscts indica l'opposto; mentre una volta -crtscts
Nella documentazione originale non si trova una spiegazione del modo con cui si possano utilizzare questi segni aggiuntivi, che sono diventati semplicemente obsoleti e non più documentati. Purtroppo, però, molti esempi di utilizzo di pppd che si trovano ancora in circolazione, fanno riferimento al vecchio modo di utilizzare le sue opzioni.
È già stato introdotto l'uso delle opzioni di pppd, che possono apparire indifferentemente nella riga di comando o nei file di configurazione. Si è già accennato anche al problema dell'uso dei simboli -+ nel caso di opzioni booleane.
ipcp |
Queste due opzioni servono ad accettare le indicazioni sugli indirizzi IP provenienti dal nodo remoto. Per la precisione, ipcp fa sì che venga accettato l'indirizzo locale proposto dal nodo remoto stesso, anche se questo era stato stabilito con la configurazione; -accept-localipcp fa sì che venga accettato l'indirizzo remoto proposto dal nodo remoto anche se era stato stabilito altrimenti.
-accept-remote
auth | noauth |
Con l'opzione auth si richiede espressamente che il nodo remoto si identifichi per consentire la connessione; al contrario, noauth annulla tale necessità. Se l'opzione auth appare nella configurazione generale, cioè nel file /etc/ppp/options, l'uso dell'opzione noauth per annullare tale disposizione, diviene una facoltà privilegiata, cioè concessa solo all'utente root.
crtscts | xonxoff |
nocrtscts |
Con l'opzione crtscts si richiede espressamente di utilizzare un controllo di flusso hardware, ovvero RTS/CTS; con l'opzione xonxoff si richiede l'opposto, cioè di utilizzare un controllo di flusso software, ovvero XON/XOFF.
L'opzione nocrtscts indica semplicemente di disabilitare il controllo di flusso hardware.
defaultroute | nodefaultroute |
L'opzione defaultroute fa sì che pppd, quando la connessione tra i due nodi del collegamento è avvenuta, aggiunga un percorso di instradamento predefinito (default route) utilizzando il nodo remoto come router. Questo percorso di instradamento viene poi rimosso dalla tabella di instradamento di sistema quando la connessione PPP si interrompe.
L'opzione nodefaultroute serve a evitare che questo instradamento predefinito abbia luogo. Per la precisione, se viene utilizzato nella configurazione generale del file /etc/ppp/options, fa sì che l'uso successivo di defaultroute divenga privilegiato, cioè riservato all'utente root.
modem | local |
L'opzione modem fa sì che pppd utilizzi le linee di controllo del modem. Al contrario, local dice a pppd di ignorarle.
login |
Con l'opzione login si istruisce pppd di utilizzare le informazioni di autenticazione gestite dal sistema operativo per gli accessi normali (il login appunto), cioè quelle sugli utenti con le password relative, per verificare l'identità del nodo remoto che si presenta utilizzando il protocollo PAP. In pratica, in questo modo, invece di dover accedere al file /etc/ppp/pap-secrets, la verifica dell'abbinamento nome-segreto, avviene in base al sistema locale utente-password.
Questo meccanismo si usa frequentemente quando la connessione PPP avviene attraverso linea telefonica commutata, e i nodi che possono accedere corrispondono agli utenti previsti nel sistema locale (nel file /etc/passwd).
|
Perché i nodi remoti possano accedere identificandosi come gli utenti del sistema, è comunque necessario che esista una voce nel file |
lock |
Fa sì che pppd crei un file di lock riferito al dispositivo utilizzato per la comunicazione, secondo lo stile UUCP. In pratica, si crea un file secondo il modello /var/lock/LCK..ttyS*. Ciò è utile per segnalare agli altri processi che aderiscono a questa convenzione il fatto che il tale dispositivo è impegnato.
In generale, è utile attivare questa opzione.
passive | silent |
L'opzione passive fa sì che pppd tenti inizialmente di connetersi al nodo remoto e, se non ne riceve alcuna risposta, resti in attesa passiva di una richiesta di connessione dalla controparte. Normalmente questa modalità non è attiva e di conseguenza pppd termina la sua esecuzione quando non riceve risposta.
L'opzione silent, invece, indica a pppd di restare semplicemente in attesa passiva di una richiesta di connessione dalla controparte, senza tentare prima di iniziarla per conto proprio.
debug |
Abilita l'annotazione di informazioni diagnostiche sullo svolgimento della connessione all'interno del registro del sistema. Per la precisione genera messaggi di tipo daemon e di livello debug (si veda eventualmente il capitolo
35).
nodetach |
In condizioni normali, quando pppd deve utilizzare un dispositivo seriale che non corrisponde anche al terminale da cui è stato avviato, questo si mette da solo sullo sfondo. Per evitarlo si può usare l'opzione nodetach.
persist | nopersist |
Con l'opzione persist si richiede a pppd di ristabilire la connessione quando questa termina; al contrario, nopersist indica espressamente di non ritentare la connessione. In generale, il comportamento predefinito di pppd è quello per cui la connessione non viene ristabilita dopo la sua conclusione.
proxyarp | noproxyarp |
Con l'opzione proxyarp si fa in modo di inserire nella tabella ARP di sistema (Address Resolution Protocol) una voce con cui l'indirizzo IP del nodo remoto viene abbinato all'indirizzo Ethernet della prima interfaccia di questo tipo utilizzata nell'elaboratore locale. Questo trucco ha il risultato di fare apparire il nodo remoto della connessione PPP come appartenente alla rete locale dell'interfaccia Ethernet.
Al contrario, noproxyarp impedisce questo, e se utilizzato nella configurazione generale del file /etc/ppp/options, fa in modo che proxyarp divenga un'opzione privilegiata e quindi riservata all'utente root.
require-pap | refuse-pap |
Con l'opzione require-pap si fa in modo che pppd accetti la connessione solo se riceve un'identificazione PAP valida dal nodo remoto; al contrario, l'opzione refuse-pap fa sì che pppd si rifiuti di fornire un'identificazione PAP alla controparte.
require-chap | refuse-chap |
Con l'opzione require-chap si fa in modo che pppd richieda alla controparte l'identificazione CHAP, e di conseguenza, che accetti la connessione solo se ciò che riceve è valido secondo il file /etc/ppp/chap-secrets. L'opzione refuse-chap fa sì che pppd si rifiuti di fornire un'identificazione CHAP alla controparte.
connect <comando> |
Permette di utilizzare il comando, che eventualmente può essere delimitato tra apici (in base alle regole stabilite dalla shell utilizzata), per attivare la comunicazione attraverso la linea seriale. Di solito serve per avviare chat che si occupa della connessione attraverso il modem su una linea commutata.
disconnect <comando> |
Esegue il comando o lo script indicato, subito dopo la fine della connessione. Ciò può essere utile per esempio per inviare al modem un comando di aggancio (hung up) se la connessione fisica con il modem non consente di inviare i segnali di controllo necessari.
mru n |
Fissa il valore dell'MRU (Maximum Receive Unit) a n. pppd richiederà al nodo remoto di utilizzare pacchetti di dimensione non superiore a questo valore. Il valore minimo teorico è 128, il valore predefinito è 1500. Nei collegamenti lenti viene suggerito l'utilizzo di un MRU pari a 296 (ottenuto sommando 40 byte di intestazione TCP a 256 byte di dati).
mtu n |
Fissa il valore dell'MTU (Maximum Transmit Unit) a n, cioè stabilisce la dimensione massima dei pacchetti trasmessi per quanto riguarda le esigenze del nodo locale. Il nodo remoto potrebbe richiedere una dimensione inferiore.
idle <n-secondi> |
maxconnect <n-secondi> |
L'opzione idle permette di stabilire il tempo di inattività oltre il quale la connessione deve essere interrotta. Il collegamento è inattivo quando non transitano pacchetti di dati. In generale, questa opzione non è conveniente assieme a persist.
L'opzione maxconnect permette di fissare un tempo massimo per la connessione.
netmask <maschera-di-rete> |
Fissa il valore della maschera di rete per la comunicazione con il nodo remoto. Il valore viene indicato secondo la notazione decimale puntata.
Generalmente, la maschera di rete per una connessione punto-punto, dovrebbe essere 255.255.255.255, tuttavia, se si utilizza l'opzione proxyarp per fare figurare il nodo remoto come appartenente alla rete locale Ethernet, la maschera di rete deve seguire le particolarità di quella rete.
ms
|
Se pppd viene utilizzato per consentire la connessione da parte di sistemi MS-Windows, questa opzione permette di comunicare loro l'indirizzo IP di un server DNS. Questa opzione può apparire due volte, per fornire un massimo di due indirizzi riferiti a server DNS.
ms
|
Se pppd viene utilizzato per consentire la connessione da parte di sistemi MS-Windows, o in generale SMB, questa opzione permette di comunicare loro l'indirizzo IP di un server WINS (Windows Internet Name Service). Questa opzione può apparire due volte, per fornire un massimo di due indirizzi riferiti a server WINS.
kdebug <n-livello> |
Abilita l'emissione di messaggi diagnostici da parte della gestione del PPP interna al kernel, cosa che si traduce generalmente nell'inserimento di tali messaggi nel registro del sistema. Il valore 1 permette la generazione di messaggi di tipo generale; il valore 2 fa sì che venga emesso il contenuto dei pacchetti ricevuti; il valore 4 fa sì che venga emesso il contenuto dei pacchetti trasmessi. Per ottenere una combinazione di queste cose, basta sommare i numeri relativi.
name <nome> |
Si tratta di un'opzione privilegiata, cioè riservata all'utente root, e permette di stabilire il nome locale utilizzato sia per la propria identificazione che per il riconoscimento di un altro nodo.
In pratica, se pppd deve identificarsi nei confronti di un nodo remoto, utilizzerà un segreto in cui il primo campo (client) corrisponda a tale nome; se invece si deve riconoscere un nodo remoto che si identifica, pppd utilizzerà un segreto in cui il secondo campo (server) corrisponda a questo.
|
È importante tenere presente l'ambiguità di questa opzione. Per identificare il nodo locale nei confronti del nodo remoto, sarebbe meglio utilizzare l'opzione |
remotename <nome> |
Definisce il nome prestabilito del nodo remoto. Questa opzione è ambigua quanto name e va utilizzata con la stessa prudenza. Potrebbe essere utile quando il nodo locale si vuole identificare presso il nodo remoto utilizzando la procedura PAP; in tal caso, dato che il nome del nodo remoto non viene rivelato in anticipo, si ha la possibilità di selezionare una voce particolare dall'elenco contenuto nel file /etc/ppp/pap-secrets, facendo riferimento al secondo campo (server).
|
In generale, l'uso delle opzioni |
usehostname |
Si tratta di un'opzione con il quale si stabilisce che il nome locale corrisponda a quello del nodo. Questa opzione prende il sopravvento e si sostituisce a name.
domain <dominio> |
Nel caso sia attivata l'opzione usehostname, fa sì che il nome locale comprenda anche il dominio indicato. Questo dominio non viene aggiunto a quanto stabilito con l'opzione name.
user <nome> |
Permette di stabilire il nome locale da utilizzare per la propria identificazione nei confronti del nodo remoto. A differenza di name, questa opzione entra in gioco solo quando il nodo locale deve identificarsi, per cui, serve a selezionare una voce dai file dei segreti, facendo riferimento al primo campo, quello del client. Questa opzione prende il sopravvento su name, per ciò che riguarda questa situazione particolare.
Si è già accennato all'uso dei file con cui si configurano i sistemi di autenticazione PAP e CHAP. Il loro formato è identico, anche se le diverse caratteristiche di PAP e CHAP consentono la presenza di voci sostanzialmente differenti.
Questi file di configurazione introducono il concetto di client e server nel momento dell'autenticazione: chi chiede all'altro di identificarsi è il server, mentre l'altro è il client. Teoricamente, la richiesta di autenticazione può essere reciproca, per cui, a fasi alterne, entrambi i nodi sono sia client che server nell'ambito del sistema di autenticazione. Quando si legge un file /etc/ppp/*-secrets occorre sempre fare mente locale a chi sia il nodo che si identifica nei confronti dell'altro, per determinare se il nodo locale è un client o un server in quel momento.
Per quanto riguarda la sintassi di questi file, come succede spesso, le righe vuote e quelle bianche vengono ignorate; così viene ignorato il contenuto dei commenti introdotti dal simbolo # e conclusi dalla fine della riga. Le altre righe, che contengono delle voci significative, sono trattate come record suddivisi in campi attraverso degli spazi lineari (spazi veri e propri o tabulazioni), secondo la sintassi seguente:
<client> <server> <segreto> <indirizzo-ip-accettabile-del-client>... |
Ogni voce dovrebbe avere l'indicazione dei primi quattro campi.
Dal momento che la separazione tra i campi avviene per mezzo di spazi lineari, se uno di questi deve contenere spazi, questi devono essere protetti in qualche modo: si possono usare gli apici doppi per delimitare una stringa, oppure si può utilizzare la barra obliqua inversa (\) davanti a un carattere che si vuole sia trattato semplicemente per il suo valore letterale (vale anche per gli spazi).
Possono essere utilizzati anche dei simboli jolly (dei metacaratteri), che hanno valore diverso a seconda del campo in cui appaiono. In generale però, ci si limita all'uso dell'asterisco (*) nel campo del client, in quello del server, o in quello del primo indirizzo IP ammissibile. L'asterisco corrisponde a qualunque nome, o a qualunque indirizzo, e si può usare solo se il tipo di autenticazione utilizzato lo consente.
Meritano un po' di attenzione il quarto campo e quelli successivi. Questi, eventualmente, servono a elencare una serie di indirizzi IP che possono essere utilizzati dal nodo corrispondente al client con quella connessione particolare; si può utilizzare anche la forma <indirizzo>/<maschera> per rappresentare un gruppo di indirizzi in modo più chiaro. Se non si vogliono porre limitazioni agli indirizzi IP, si deve utilizzare un asterisco (*).
|
In passato non era necessario compilare il quarto campo e quelli successivi se non c'era la necessità di specificare gli indirizzi IP utilizzabili. Con le ultime versioni di |
Come ultima considerazione, occorre tenere presente che quando pppd cerca una corrispondenza nei file dei segreti, se c'è la possibilità di farlo, seleziona la voce più specifica, cioè quella che contiene meno simboli jolly.
-secretsL'autenticazione PAP prevede che un nodo si identifichi prima di conoscere l'identità della sua controparte. In questo senso, l'indicazione del nome del server può essere utile solo per distinguere la coppia nome-segreto da inviare. Si osservi l'esempio seguente:
# Segreti per l'autenticazione PAP # client server segreto indirizzi IP ammissibili tizio uno tazza * caio due capperi * semproni tre serpenti * |
Concentrando l'attenzione al caso in cui sia il nodo locale a doversi identificare presso altri nodi remoti, questo potrebbe essere conosciuto con nomi differenti, a seconda del collegamento che si vuole instaurare. Osservando la prima voce dell'esempio, il nodo locale client è conosciuto presso il nodo uno (server) con il nome tizio, e per quella connessione deve utilizzare il segreto tazza.
Dal momento che il protocollo PAP non prevede di ottenere l'informazione sul nome remoto prima di fornire la propria identità, è necessario istruire pppd su quale voce utilizzare. Se i nomi locali sono tutti diversi, è sufficiente specificare questo dato attraverso l'opzione name, ma forse sarebbe meglio l'opzione user, essendo più specifica; se invece questi nomi possono essere uguali (in alcuni o in tutti i casi), occorre specificare anche l'opzione remotename.
A questo punto, però, dal momento che il nome del server non viene ottenuto attraverso il protocollo PAP, quello indicato nel secondo campo delle voci del file /etc/ppp/pap-secrets può essere un nome di fantasia, scelto solo per comodità.
*1*
Per lo stesso motivo, se i nomi client sono tutti diversi, ovvero si utilizza una sola voce, il nome del nodo remoto (server) può essere semplicemente sostituito con un asterisco, come nell'esempio seguente:
# Segreti per l'autenticazione PAP # client server segreto indirizzi IP ammissibili tizio * tazza * caio * capperi * semproni * serpenti * |
La funzione del file /etc/ppp/pap-secrets non si esaurisce solo nel compito di fornire l'identità del nodo locale (in qualità di client) quando il nodo remoto lo richiede, perché può essere usato anche per verificare l'identità del nodo remoto, quando è quest'ultimo a presentarsi come client.
Dal file /etc/ppp/pap-secrets non si riesce a distinguere quando il nodo locale è un client e quando è un server. Ciò dipende dalle opzioni. Se si richiede espressamente un'autenticazione PAP attraverso l'opzione require, vuol dire che il nodo remoto deve identificarsi, e il suo nome dovrà apparire nel primo campo di una voce del file -pap/etc/ppp/pap-secrets locale. In pratica, le cose non cambiano quando si legge il contenuto di questo file; sono le circostanze (ovvero le opzioni) che danno significato alle sue voci, e ogni volta bisogna mettersi nei panni giusti e pensare che il nodo locale sia un client o un server a seconda della situazione.
È bene ricordare che quando si utilizza l'autenticazione PAP, dal lato del nodo che deve verificare l'identità di altri nodi, cioè dal lato del server, si preferisce spesso fare riferimento agli utenti registrati nel sistema, piuttosto che al contenuto del file /etc/ppp/pap-secrets. Per questo si utilizza l'opzione login, assieme a require, e si deve comunque aggiungere una voce particolare nel file -pap/etc/ppp/pap-secrets, come mostrato nell'esempio seguente:
# Segreti per l'autenticazione PAP # client server segreto indirizzi IP ammissibili * * "" * |
È difficile spiegare le ragioni di questo, ma è così. Diversamente, occorrerebbe ripetere l'indicazione delle utenze nel file /etc/ppp/pap-secrets, dove nel primo campo (client) andrebbero i nomi degli utenti, e nel terzo le password. In particolare, come si può intuire, la stringa nulla delimitata con i doppi apici nella posizione del segreto, rappresenta qualunque password.
L'amministratore del nodo remoto che deve identificarsi, dovrà inserire una voce nel proprio file /etc/ppp/pap-secrets, dove nel primo campo (client) metterà il nominativo-utente necessario per accedere presso il nodo remoto, e di conseguenza, nel terzo campo metterà la password di questo.
-secretsL'autenticazione CHAP prevede che un nodo si identifichi dopo aver conosciuto il nome della controparte. La compilazione del file /etc/ppp/chap-secrets segue le stesse regole del file utilizzato per l'autenticazione PAP, ma in tal caso, diventa meno probabile l'uso del jolly *.
L'autenticazione CHAP viene usata meno frequentemente perché con questa non è possibile fare riferimento agli utenti registrati nel sistema attraverso l'opzione login.
Si è già accennato alla possibilità di affiancare a pppd alcuni script o programmi che possano essere avviati da questo in momenti determinati della fase si connessione e di disconnessione. Quando si utilizza il protocollo PPP per trasportare quello IP, sono particolarmente importanti ip e -upip che dovrebbero essere contenuti nella directory -down/etc/ppp/.
Tutti gli script che pppd può gestire, e non solo quelli descritti qui, sono avviati senza che pppd debba attendere la loro conclusione; inoltre ottengono tutti i privilegi dell'utente root, in modo da permettere loro di eseguire qualunque operazione, soprattutto per ciò che riguarda la configurazione della rete. Tutti i flussi standard (standard input, standard output e standard error) sono ridiretti verso /dev/null. Infine, questi dispongono solo di un numero limitato di variabili di ambiente che vengono descritte di seguito.
DEVICE
Contiene il nome del dispositivo seriale utilizzato.
IFNAME
Contiene il nome dell'interfaccia di rete abbinata alla connessione PPP.
IPLOCAL, IPREMOTE
Queste due variabili contengono rispettivamente l'indirizzo IP locale e quello remoto della connessione.
PEERNAME
Contiene il nome del nodo remoto, ottenuto a seguito di un'autenticazione.
SPEED
Contiene la velocità espressa in bps della linea seriale.
UID
Contiene il numero UID reale dell'utente che ha avviato pppd.
-up /etc/ppp/ip-downCome si può intuire dai nomi di questi script, ip viene avviato da -uppppd quando la connessione IP è attiva, mentre ip viene avviato quando questa connessione non è più disponibile.
-down
Oltre alle variabili di ambiente descritte in precedenza, questi ricevono una serie di argomenti, che potrebbero anche essere superflui:
<nome-interfaccia>
è l'equivalente del contenuto della variabile IFNAME;
<dispositivo-della-linea>
è l'equivalente del contenuto della variabile DEVICE;
<velocità-bps>
è l'equivalente del contenuto della variabile SPEED;
<indirizzo-ip-locale>
è l'equivalente del contenuto della variabile IPLOCAL;
<indirizzo-ip-remoto>
è l'equivalente del contenuto della variabile IPREMOTE;
<opzione-ipparam>
è il valore dell'opzione ipparam se questa viene utilizzata con pppd.
L'esempio seguente riguarda uno script ip con il quale si vuole fare in modo che i messaggi in coda nel sistema locale di posta elettronica vengano inviati non appena la connessione PPP viene instaurata.
-up
#!/bin/bash
#
# /etc/ppp/ip-up
#
# Per facilitare le cose, viene definita la variabile di ambiente
# PATH, così da poter avviare i programmi più facilmente.
#
PATH=/usr/sbin:/sbin:/usr/bin:/bin
export PATH
# Se l'indirizzo IP remoto corrisponde a quello che consente
# l'accesso a Internet, si invia la posta elettronica rimasta in coda.
#
case "$5" in
111.112.113.114)
sendmail -q
;;
*)
esac
|
Alle volte, sembra che le cose non vadano come dovrebbero, in base a quanto si trova nella documentazione. Per esempio, nella descrizione di queste funzionalità all'interno di pppd(8) è specificato che questi script ricevono soltanto le variabili che sono state presentate in queste sezioni. Eppure, ci sono degli esempi di utilizzo di pppd che fanno affidamento su altre risorse. In generale, sarebbe bene fare affidamento soltanto su quanto indicato nei documenti originali, tuttavia, alle volte potrebbe essere utile sapere esattamente qual è l'ambiente che ricevono questi script, e quali sono precisamente gli argomenti che gli vengono passati.
#!/bin/bash /bin/echo $@ >> /tmp/ambiente-ppp set >> /tmp/ambiente-ppp exit 0 |
L'esempio mostra una soluzione semplicissima per ottenere tali informazioni. Può trattarsi di uno qualunque degli script che è in grado di comandare pppd, non solo quelli riferiti alle connessioni IP che sono già stati presentati. Viene accodato al file /tmp/ambiente-ppp il contenuto di tutti gli argomenti ricevuti, e quindi, attraverso il comando set, viene aggiunto anche lo stato di tutto l'ambiente.
Per completare questo capitolo introduttivo al PPP, viene incluso l'esempio del file di configurazione generale standard che viene fornito normalmente assieme a pppd. Questo dovrebbe rendere un po' meglio l'idea di come si utilizzano le opzioni di pppd.
# /etc/ppp/options
# The name of this server. Often, the FQDN is used here.
#name <host>
# Enforce the use of the hostname as the name of the local system for
# authentication purposes (overrides the name option).
usehostname
# If no local IP address is given, pppd will use the first IP address
# that belongs to the local hostname. If "noipdefault" is given, this
# is disabled and the peer will have to supply an IP address.
noipdefault
# With this option, pppd will accept the peer's idea of our local IP
# address, even if the local IP address was specified in an option.
#ipcp-accept-local
# With this option, pppd will accept the peer's idea of its (remote) IP
# address, even if the remote IP address was specified in an option.
#ipcp-accept-remote
# Specify which DNS Servers the incoming Win95 or WinNT Connection should use
# Two Servers can be remotely configured
#ms-dns 192.168.1.1
#ms-dns 192.168.1.2
# Specify which WINS Servers the incoming connection Win95 or WinNT should use
#wins-addr 192.168.1.50
#wins-addr 192.168.1.51
# enable this on a server that already has a permanent default route
#nodefaultroute
# Run the executable or shell command specified after pppd has terminated
# the link. This script could, for example, issue commands to the modem
# to cause it to hang up if hardware modem control signals were not
# available.
# If mgetty is running, it will reset the modem anyway. So there is no need
# to do it here.
#disconnect "chat -- \d+++\d\c OK ath0 OK"
# Increase debugging level (same as -d). The debug output is written
# to syslog LOG_LOCAL2.
debug
# Enable debugging code in the kernel-level PPP driver. The argument n
# is a number which is the sum of the following values: 1 to enable
# general debug messages, 2 to request that the contents of received
# packets be printed, and 4 to request that the contents of transmitted
# packets be printed.
#kdebug n
# Require the peer to authenticate itself before allowing network
# packets to be sent or received.
# Please do not disable this setting. It is expected to be standard in
# future releases of pppd. Use the call option (see manpage) to disable
# authentication for specific peers.
#auth
# authentication can either be pap or chap. As most people only want to
# use pap, you can also disable chap:
#require-pap
#refuse-chap
# Use hardware flow control (i.e. RTS/CTS) to control the flow of data
# on the serial port.
crtscts
# Specifies that pppd should use a UUCP-style lock on the serial device
# to ensure exclusive access to the device.
lock
# Use the modem control lines.
modem
# async character map -- 32-bit hex; each bit is a character
# that needs to be escaped for pppd to receive it. 0x00000001
# represents '\x01', and 0x80000000 represents '\x1f'.
# To allow pppd to work over a rlogin/telnet connection, ou should escape
# XON (^Q), XOFF (^S) and ^]: (The peer should use "escape ff".)
#asyncmap 200a0000
asyncmap 0
# Specifies that certain characters should be escaped on transmission
# (regardless of whether the peer requests them to be escaped with its
# async control character map). The characters to be escaped are
# specified as a list of hex numbers separated by commas. Note that
# almost any character can be specified for the escape option, unlike
# the asyncmap option which only allows control characters to be
# specified. The characters which may not be escaped are those with hex
# values 0x20 - 0x3f or 0x5e.
#escape 11,13,ff
# Set the MRU [Maximum Receive Unit] value to <n> for negotiation. pppd
# will ask the peer to send packets of no more than <n> bytes. The
# minimum MRU value is 128. The default MRU value is 1500. A value of
# 296 is recommended for slow links (40 bytes for TCP/IP header + 256
# bytes of data).
#mru 542
# Set the MTU [Maximum Transmit Unit] value to <n>. Unless the peer
# requests a smaller value via MRU negotiation, pppd will request that
# the kernel networking code send data packets of no more than n bytes
# through the PPP network interface.
#mtu <n>
# Set the interface netmask to <n>, a 32 bit netmask in "decimal dot"
# notation (e.g. 255.255.255.0).
#netmask 255.255.255.0
# Don't fork to become a background process (otherwise pppd will do so
# if a serial device is specified).
nodetach
# Set the assumed name of the remote system for authentication purposes
# to <n>.
#remotename <n>
# Add an entry to this system's ARP [Address Resolution Protocol]
# table with the IP address of the peer and the Ethernet address of this
# system. {proxyarp,noproxyarp}
proxyarp
# Use the system password database for authenticating the peer using
# PAP. Note: mgetty already provides this option. If this is specified
# then dialin from users using a script under Linux to fire up ppp wont work.
#login
# If this option is given, pppd will send an LCP echo-request frame to
# the peer every n seconds. Under Linux, the echo-request is sent when
# no packets have been received from the peer for n seconds. Normally
# the peer should respond to the echo-request by sending an echo-reply.
# This option can be used with the lcp-echo-failure option to detect
# that the peer is no longer connected.
lcp-echo-interval 30
# If this option is given, pppd will presume the peer to be dead if n
# LCP echo-requests are sent without receiving a valid LCP echo-reply.
# If this happens, pppd will terminate the connection. Use of this
# option requires a non-zero value for the lcp-echo-interval parameter.
# This option can be used to enable pppd to terminate after the physical
# connection has been broken (e.g., the modem has hung up) in
# situations where no hardware modem control lines are available.
lcp-echo-failure 4
# Specifies that pppd should disconnect if the link is idle for n seconds.
idle 600
# Disable the IPXCP and IPX protocols.
noipx
|
Robert Hart, PPP HOWTO
pppd(8)
---------------------------
Appunti Linux 1999.09.21 --- Copyright © 1997-1999 Daniele Giacomini -- daniele @ pluto.linux.it
1.) Per qualche motivo, se si utilizza il protocollo di autenticazione PAP per la propria identificazione, e si vuole usare l'opzione remotename, è necessario anche aggiungere l'opzione user, o name, per specificare il nome locale del client.