[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico] [volume] [parte]
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.
Per poter utilizzare il protocollo PPP, è necessario che il kernel Linux sia predisposto per farlo (sezione 49.2.14). 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 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.
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.
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 deve avere 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 a cui si riferisce.
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.
|
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 deve 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 viene 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.
|
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.
|
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.
|
|
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 descritte in seguito.
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[Invio]
# chmod u+s /usr/sbin/pppd[Invio]
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 vengono descritte nel contesto appropriato.
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.
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:
|
Il sesto argomento, deriva eventualmente dall'uso dell'opzione ipparam di pppd.
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.
È 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.
|
|
|
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 (*).
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.
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:
|
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:
|
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 deve 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:
|
È 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, deve inserire una voce nel proprio file /etc/ppp/pap-secrets, dove nel primo campo (cliente) deve mettere il nominativo-utente necessario per accedere presso la controparte e, di conseguenza, nel terzo campo deve mettere la parola d'ordine di questo utente.
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.
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.
|
La variabile di ambiente USEPEERDNS può essere sfruttata per verificare l'utilizzo o meno di questa funzionalità, per esempio nel modo seguente:
|
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:
nome_interfaccia
è l'equivalente del contenuto della variabile IFNAME;
dispositivo_della_linea
è l'equivalente del contenuto della variabile DEVICE;
velocità_bps
è l'equivalente del contenuto della variabile SPEED;
indirizzo_ip_locale
è l'equivalente del contenuto della variabile IPLOCAL;
indirizzo_ip_remoto
è l'equivalente del contenuto della variabile IPREMOTE;
opzione_ipparam
è il valore dell'opzione ipparam se questa viene utilizzata con pppd.
L'esempio seguente riguarda uno script ip-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.
|
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.
|
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.
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:
|
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 volo, 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:
|
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:
|
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.
|
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, possano 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.
Robert Hart, PPP HOWTO
<http://www.linux.org/docs/ldp/howto/HOWTO-INDEX/howtos.html>
pppd(8)
Appunti di informatica libera 2006.07.01 --- Copyright © 2000-2006 Daniele Giacomini -- <daniele (ad) 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.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico]
