[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


111. Introduzione al PPP

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 cliente e un servente, tuttavia, per quanto riguarda il problema dell'autenticazione, si considera cliente quel nodo che si fa riconoscere, attraverso uno di questi protocolli PAP o CHAP, presso l'altro, che così è il servente. 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 essere reciproca; in tal caso entrambi i nodi che si connettono sono sia cliente che servente a fasi alterne.

111.1 Funzionalità del kernel

Per poter utilizzare il protocollo PPP, è necessario che il kernel sia predisposto per farlo. Naturalmente, lo stesso kernel deve poter gestire la rete.

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.

111.2 Funzionamento generale di pppd

GNU/Linux dispone generalmente del demone `pppd' per la gestione del protocollo PPP. Si è accennato al fatto che il PPP non prevede un cliente e un servente, anche se questi termini si usano per distinguere le parti nella fase di autenticazione, e in tal 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.

111.2.1 Struttura del sistema di configurazione

`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

111.2.2 Struttura del sistema di autenticazione

All'inizio del capitolo 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, pertanto 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»
# cliente	servente	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»
# cliente	servente	segreto		indirizzi IP ammissibili
dinkel		roggen		ciao		*

In questi termini, nell'ambito delle forme di autenticazione usate da `pppd', si parla di cliente per indicare il nodo che deve identificarsi di fronte alla controparte, e di servente 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»
# cliente	servente	segreto		indirizzi IP ammissibili
dinkel		roggen		ciao		*
roggen		dinkel		medusa		*

# Segreti per l'autenticazione CHAP dalla parte del nodo «roggen»
# cliente	servente	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.

111.2.3 Interfacce PPP e funzioni privilegiate

`pppd', quando riesce a instaurare una connessione, definisce dinamicamente un'interfaccia di rete `pppn', dove n è un numero che inizia da zero. 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.

111.2.4 Script di contorno

`pppd' può avviare degli script di contorno, in presenza di circostanze determinate. 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'.

111.3 Maggiori dettagli su 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.

111.3.1 Opzioni principali

È 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 `-' e `+' nel caso di opzioni booleane.

Alcune opzioni booleane

ipcp-accept-local | ipcp-accept-remote

Queste due opzioni servono ad accettare le indicazioni sugli indirizzi IP provenienti dal nodo remoto. Per la precisione, `ipcp-accept-local' fa sì che venga accettato l'indirizzo locale proposto dal nodo remoto stesso, anche se questo era stato stabilito con la configurazione; `ipcp-accept-remote' fa sì che venga accettato l'indirizzo remoto proposto dal nodo remoto anche se era stato stabilito altrimenti.

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 `/etc/ppp/pap-secrets' che consenta loro di essere accettati. Di solito si usa: `* * "" *', che rappresenta qualunque nome per il cliente, qualunque nome per il servente, qualunque segreto (o password) e qualunque indirizzo IP.

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

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.

Alcune opzioni con argomento

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-dns <indirizzo>

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 servente DNS. Questa opzione può apparire due volte, per fornire un massimo di due indirizzi riferiti a serventi DNS.

ms-wins <indirizzo>

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 servente WINS (Windows Internet Name Service). Questa opzione può apparire due volte, per fornire un massimo di due indirizzi riferiti a serventi 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 uno permette la generazione di messaggi di tipo generale; il valore due fa sì che venga emesso il contenuto dei pacchetti ricevuti; il valore quattro fa sì che venga emesso il contenuto dei pacchetti trasmessi. Per ottenere una combinazione di queste cose, basta sommare i numeri relativi.

Alcune opzioni riferite all'identificazione

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 (cliente) corrisponda a tale nome; se invece si deve riconoscere un nodo remoto che si identifica, `pppd' utilizzerà un segreto in cui il secondo campo (servente) 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 `user'.

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

In generale, l'uso delle opzioni `name' e `remotename' dovrebbe essere sensato solo quando l'unico nodo che deve identificarsi è quello locale nei confronti di quello remoto, cioè quando non si pretende anche l'identificazione inversa. Tuttavia, se è possibile risolvere la cosa con l'uso dell'opzione `user', tutto diventa più semplice.

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 cliente. Questa opzione prende il sopravvento su `name', per ciò che riguarda questa situazione particolare.

111.3.2 File per il sistema di autenticazione

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 cliente e servente nel momento dell'autenticazione: chi chiede all'altro di identificarsi è il servente, mentre l'altro è il cliente. Teoricamente, la richiesta di autenticazione può essere reciproca, per cui, a fasi alterne, entrambi i nodi sono sia cliente che servente 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 cliente o un servente 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:

<cliente> <servente> <segreto> <indirizzo-ip-accettabile-del-cliente>...

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 cliente, in quello del servente, 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 cliente 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 `pppd' è diventato impossibile farne a meno.

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.

111.3.2.1 Uso di /etc/ppp/pap-secrets

L'autenticazione PAP prevede che un nodo si identifichi prima di conoscere l'identità della sua controparte. In questo senso, l'indicazione del nome del servente può essere utile solo per distinguere la coppia nome-segreto da inviare. Si osservi l'esempio seguente:

# Segreti per l'autenticazione PAP
# cliente	servente	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 cliente è conosciuto presso il nodo `uno' (servente) 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 servente 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 cliente sono tutti diversi, ovvero si utilizza una sola voce, il nome del nodo remoto (servente) può essere semplicemente sostituito con un asterisco, come nell'esempio seguente:

# Segreti per l'autenticazione PAP
# cliente	servente	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 cliente) quando il nodo remoto lo richiede, perché può essere usato anche per verificare l'identità del nodo remoto, quando è quest'ultimo a presentarsi come cliente.

Dal file `/etc/ppp/pap-secrets' non si riesce a distinguere quando il nodo locale è un cliente e quando è un servente. Ciò dipende dalle opzioni. Se si richiede espressamente un'autenticazione PAP attraverso l'opzione `require-pap', vuol dire che il nodo remoto deve identificarsi, e il suo nome dovrà apparire nel primo campo di una voce del file `/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 cliente o un servente 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 servente, 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-pap', e si deve comunque aggiungere una voce particolare nel file `/etc/ppp/pap-secrets', come mostrato nell'esempio seguente:

# Segreti per l'autenticazione PAP
# cliente	servente	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 (cliente) andrebbero i nomi degli utenti, e nel terzo le password. In particolare, come si può intuire, la stringa nulla delimitata con gli apici doppi 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 (cliente) metterà il nominativo-utente necessario per accedere presso il nodo remoto, e di conseguenza, nel terzo campo metterà la password di questo.

111.3.2.2 Uso di /etc/ppp/chap-secrets

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

111.3.3 Script

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-up' e `ip-down' che dovrebbero essere contenuti nella directory `/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.

111.3.3.1 /etc/ppp/ip-up /etc/ppp/ip-down

Come si può intuire dai nomi di questi script, `ip-up' viene avviato da `pppd' quando la connessione IP è attiva, mentre `ip-down' viene avviato quando questa connessione non è più disponibile.

Oltre alle variabili di ambiente descritte in precedenza, questi ricevono una serie di argomenti, che potrebbero anche essere superflui:

  1. <nome-interfaccia>

    è l'equivalente del contenuto della variabile `IFNAME';

  2. <dispositivo-della-linea>

    è l'equivalente del contenuto della variabile `DEVICE';

  3. <velocità-bps>

    è l'equivalente del contenuto della variabile `SPEED';

  4. <indirizzo-ip-locale>

    è l'equivalente del contenuto della variabile `IPLOCAL';

  5. <indirizzo-ip-remoto>

    è l'equivalente del contenuto della variabile `IPREMOTE';

  6. <opzione-ipparam>

    è il valore dell'opzione `ipparam' se questa viene utilizzata con `pppd'.

L'esempio seguente riguarda uno script `ip-up' 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.

#!/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

111.3.3.2 Verifica dell'ambiente

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.

111.3.4 Configurazione

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

111.4 Riferimenti

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 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 cliente.


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]