[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]


Capitolo 127.   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, tanto che 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, sia servente, a fasi alterne.

127.1   Funzionalità del kernel Linux

Per poter utilizzare il protocollo PPP, è necessario che il kernel Linux sia predisposto per farlo (sezione 29.2.12). Naturalmente, lo stesso kernel deve poter gestire la rete (sezione 29.2.9).

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 generic driver version 2.4.1
PPP Deflate Compression module registered
PPP BSD Compression module registered

Se invece si tratta di una funzionalità gestita attraverso un modulo, questa dovrebbe attivarsi automaticamente al momento del bisogno.

127.2   Funzionamento generale del demone per il PPP

I sistemi GNU dispongono generalmente del demone pppd (1) 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. 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.

127.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, pertanto 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, per cui 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

127.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 parola d'ordine) 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 parola d'ordine) 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, attendendo 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 parola d'ordine 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 questo 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.

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

chown root /usr/sbin/pppd

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

127.2.4   Indirizzi IP

Quando il protocollo PPP viene usato per trasportare comunicazioni IP, esiste la possibilità di definire in qualche modo quali indirizzi assegnare alle due parti della comunicazione. In particolare, con IPv4 gli indirizzi possono stati fissati in anticipo, oppure ottenuti dalla controparte; con IPv6, invece, gli indirizzi sono di tipo link-local, dove la parte finale degli ultimi 64 bit può essere determinata in modo casuale, o da indirizzi IPv4 preesistenti, oppure fissata in modo manuale.

127.2.5   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 IPv4, sono importanti /etc/ppp/ip-up e /etc/ppp/ip-down, a cui corrispondono IPv6 gli script /etc/ppp/ipv6-up e /etc/ppp/ipv6-down. Il primo di questi (/etc/ppp/ip[v6]-up) viene avviato subito dopo una connessione e l'instaurazione di un collegamento IP tra le due parti; il secondo (/etc/ppp/ip[v6]-down) 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

Nel caso particolare di IPv6, la coppia di indirizzi locale e remoto, sono di tipo link-local.

Ogni distribuzione GNU 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.

127.3   Avvio e opzioni

La sintassi per l'avvio del demone pppd è 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.

Tipo di opzione Descrizione

dispositivo_di_comunicazione

Tra gli argomenti della riga di comando o tra le opzioni di un file di configurazione, può apparire il percorso assoluto 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 bit per secondo (simbolo «bit/s», espresso volgarmente anche come «bps»). I valori utilizzabili dipendono molto anche dal sistema operativo utilizzato; per quanto riguarda GNU/Linux si tratta di quelli che si possono indicare nella configurazione delle porte seriali.

ind_ipv4_locale:ind_ipv4_remoto

 

ind_ipv4_locale:

 

:ind_ipv4_remoto

Due numeri IPv4, 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 IPv4 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 (che non sono 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, mentre nocrtscts indica l'opposto; mentre una volta -crtscts era il modo corretto per indicare questo.
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.

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

Opzione booleana Descrizione

ipcp-accept-local <-'
`->| ipcp-accept-remote

Queste due opzioni servono ad accettare le indicazioni sugli indirizzi IPv4 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 parole d'ordine 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-parola d'ordine.
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 parola d'ordine) 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 53).

usepeerdns

Consente di ottenere dalla controparte l'indicazione di un massimo di due serventi DNS, i cui indirizzi verranno inseriti nelle variabili di ambiente DNS1 e DNS2 (utilizzabili nello script ip-up), creando anche il file /etc/ppp/resolv.conf, compatibile con il file /etc/resolv.conf normale.

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

ipv6cp-use-ipaddr

Fa in modo di usare l'indirizzo IPv4 per ottenere l'identificatore di interfaccia per l'indirizzo link-local locale.

Opzione con argomento Descrizione

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 per poter usare IPv6 è 1 280, il valore predefinito è 1 500.

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 valore minimo teorico per poter usare IPv6 è 1 280). 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_ipv4

Fissa il valore della maschera di rete per la comunicazione con il nodo remoto attraverso IPv4. 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.

ipv6 identificatore_di_interfaccia_locale,<-'
`->identificatore_di_interfaccia_remoto

 

ipv6 identificatore_di_interfaccia_locale

 

ipv6 ,identificatore_di_interfaccia_remota

Permette di definire esplicitamente l'identificatore di interfaccia locale, remota, o entrambe. Si tratta di un numero di 64 bit da esprimere in forma di stringa come se fosse un indirizzo IPv6; per esempio ::0001:0002.

Opzione di identificazione Descrizione

name nome

Si tratta di un'opzione privilegiata, cioè riservata all'utente root, che 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.

127.4   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; nello stesso modo 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 un campo 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.

127.4.1   Configurazione PAP

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à.(2)

Per lo stesso motivo, se i nomi dal lato 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 è questo 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: 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, ma 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 parole d'ordine. In particolare, come si può intuire, la stringa nulla delimitata con gli apici doppi nella posizione del segreto, rappresenta qualunque parola d'ordine.

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 parola d'ordine di questo.

127.4.2   Configurazione CHAP

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.

127.5   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, oppure ipv6-up e ipv6-down, che dovrebbero essere contenuti nella directory /etc/ppp/.

Tutti gli script che pppd può gestire (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.

Come si può intuire dai nomi di questi script, ip[v6]-up viene avviato da pppd quando la connessione è attiva, mentre ip[v6]-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 (connessioni IPv4) 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

127.5.1   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; quindi, attraverso il comando set, viene aggiunto anche lo stato di tutto l'ambiente.

127.5.2   Gestione dinamica degli indirizzi DNS

Si è accennato all'utilizzo dell'opzione usepeerdns per ottenere automaticamente l'indicazione dei serventi DNS remoti, offerti dal fornitore di accesso a Internet. Per sfruttare questa possibilità, si può intervenire in due modi differenti, a seconda che si gestisca un serventi DNS locale o meno.

pppd crea automaticamente il file /etc/ppp/resolv.conf, contenente una o due direttive del tipo:


nameserver 111.112.113.1
nameserver 111.112.113.2

Se non si dispone di un DNS locale, è sufficiente sostituire il file /etc/resolv.conf con un collegamento simbolico che punti al file /etc/ppp/resolv.conf.

Diversamente, se si dispone anche di un servente DNS locale, oppure ci sono altre direttive che si vogliono preservare, le cose si complicano, perché occorre costruire un file /etc/resolv.conf ogni volta e bisogna poi ripristinarlo alla fine del collegamento PPP. Si può intuire che per questo vadano usati opportunamente gli script ip[v6]-up e ip[v6]-down.

Semplificando molto le cose, /etc/resolv.conf potrebbe sempre essere un collegamento simbolico, che viene modificato al volto, in modo da utilizzare la configurazione normale, oppure il file /etc/ppp/resolv.conf. A titolo di esempio, nello script ip[v6]-up potrebbero essere aggiunte le istruzioni seguenti:


if [ "$USEPEERDNS" ] && [ "$DNS1" ]
then
    rm -f /etc/resolv.conf
    ln -s /etc/ppp/resolv.conf /etc/resolv.conf
fi

Supponendo che il file /etc/resolv.conf.standard contenga le direttive che servono quando non è più disponibile la connessione PPP, lo script ip[v6]-down potrebbero contenere anche le istruzioni seguenti:


rm -f /etc/resolv.conf
ln -s /etc/resolv.conf.standard /etc/resolv.conf

127.5.3   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

127.6   Impostazione della distribuzione GNU/Linux Debian

La distribuzione GNU/Linux Debian organizza la gestione del PPP in modo particolare, allo scopo di non dover modificare direttamente gli script ip-up e ip-down, oltre a fornire una soluzione già pronta per l'attribuzione dinamica degli indirizzi IP dei serventi DNS remoti.

Lo script ip-up esegue in sequenza tutti gli script che trova nella directory /etc/ppp/ip-up.d/, mentre lo script ip-down esegue in sequenza tutti gli script che trova nella directory /etc/ppp/ip-down.d/. Si può intendere che queste due directory non siano standard; tuttavia, con tale meccanismo, si evita che i pacchetti applicativi che devono intervenire in qualche modo nella connessione PPP, possono limitarsi a collocare i loro script in queste directory, senza modificare direttamente ip-up o ip-down.

All'interno di questo meccanismo, si inserisce anche la gestione dinamica degli indirizzi dei serventi DNS remoti. Precisamente ciò avviene per mezzo degli script /etc/ppp/ip-up.d/0dns-up e /etc/ppp/ip-down.d/0dns-down (il nome degli script inizia con uno zero, per garantire che vengano eseguiti prima degli altri, dal momento che si rispetta l'ordine alfabetico). Lo script 0dns-up si limita a controllare che ci siano i presupposti necessari e che sia stato ottenuto almeno un indirizzo IP di un servente DNS remoto; se le cose stanno così, sostituisce il file /etc/resolv.conf in modo appropriato; al termine, lo script 0dns-down ripristina le cose come stavano prima della connessione PPP.

127.7   Riferimenti

Appunti di informatica libera 2003.01.01 --- Copyright © 2000-2003 Daniele Giacomini -- daniele @ swlibero.org

1) PPPd   software libero con licenza speciale

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


Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome introduzione_al_ppp.html

[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]