|
|
In questa prima pagina ci occuperemo puramente della parte teorica circa il funzionamento di pppd. E' molto interessante capirne il funzionamento, ma se non avete voglia o tempo potete passare direttamente alla pagina 2, dove tratteremo puramente la configurazione di una connessione Dial-UP.
|
|
PPP è il protocollo Punto-Punto (Peer-to-Peer) e può essere usato sia per connettersi a Internet (funzioni client) o a altri computer tramite linea seriale/telefonica, sia per accettare connessioni via modem (funzioni server). In questo tutorial tratteremo le funzioni client per configurare una connessione ad Internet tramite un ISP. Questa distinzione è dovuta al modo in cui dono create le connessioni. Come funziona una connessione PPP? Essenzialmente si basa su uno scambio di dati tra i due punti (host). Questi dati vengono scambiati sottoforma di pacchetti. Ogni pacchetto contiene sia la parte puramente di dati sia una serie di informazioni per l'instradamento corretto del pacchetto e sui protocolli usati. Il protocollo PPP si basa su due componenti: una componennte a livello Kernel e una componente a livello software. La prima componente assolve la maggior parte del lavoro creando, dividendo e codificando i pacchetti in transito amministrando il framing dei pacchetti e i vari livelli. La seconda componente implementa una serie di protocolli (un insieme di regole) tra cui LCP, IPCP, PAP, CHAP per stabilire la connessione e l'autenticazione all'host remoto (ISP nel nostro caso) e setta le interfaccie di rete (vedere "ifconfig"). Questa componente comprende le applicazioni PPPD e altre utility che vedremo in seguito. Analizziamo bene le singoli componenti per capire come avviene una connessione:
Kernel
La componente del kernel consiste in porzioni di codice che svolgono quello detto sopra. In particolare questo codice si occupa di assemblare/disassemblare i frame PPP, controlla i pacchetti, li redirige e li instrada. Praticamente i pacchetti in transito passano prima per la linea seriale (modem), poi vanno direttamente al kernel e infine vengono passati a PPPD, il demone che gestisce la connessione. I pacchetti IP quindi vanno direttamente al kernel, per essere tradotti. Così una volta che pppd ha stabilito la connessione, va a "dormire" passando il testimone al kernel, fino a quando non si vuole chiuedere la connessione. Le parti del kernel che implementano il supporto a PPP possono essere compilare sia come moduli sia come built-in (inclusi nel kernel). Se hai PPP già installato come built-in puoi passare direttamente all'installazione degli applicativi. Se invece li hai compilati come moduli, controlla che siano installati i seguenti (di solito in /lib/modules/versione-kernel/drivers/net"):
- ppp-generic.o = abilita il supporto al protocollo PPP. Indispensabile.
- ppp-async.o = gestisce le connessioni asincrone.
- ppp-deflate.o = gestisce la compressione dei pacchetti
Questi pacchetti sono richiesti.
Vediamo ora la componente software.
Software
Questa componente si può scaricare da Internet dato che è il pacchetto software di nome ppp-x.x.xxx dove le x rappresentano le varie versioni. Questo pacchetto comprende il demone che si occupa di stabilite le connessioni ("pppd") e delle altre utility. Per stabilire la connessione pppd sfrutta la linea seriale. E' composto da due parti: un LCP (Extensible Link control Protocol) -per amministrare il collegamento e l'autenticazione- e una famiglia di Network Control Protocol per stabilire e configurare i protocolli di rete diversi. Una volta lanciato, pppd non sa come dialogare con il modem e cosa dire al sistema remoto in fase di connessione. Per questo, per stabilire il collegamento, si appoggia su programmi esterni come "chat", quello di default usato da pppd. "chat" non fa altro che inviare al modem delle stringhe e aspettarsene delle altre. Questo significa dialogare con il modem. Per esempio chat apre la line seriale, invia il numero da comporre al modem, una volta composto il modem gli dice che è OK e che è connesso. A questo punto torna in funzione pppd. E' molto semplice. Vediamo un riassunto di una connssione:
La connessione
Lancio pppd con le opzioni per la connessione. PPPD si avvia e chiama il programma CHAT. CHAT apre la connessione con il modem, compone il numero e aspetta che il modem sia connesso. Una volta stabilito il collegamento telefonico, il modem dice a Chat che è connesso. Chat, dato che ha assolto il suo compito, si chiude e passa la "palla" a PPPD. PPPD a questo punto gestisce l'autenticazione con username e password (questo dipende dalle impostazioni dell'ISP). A connessione avvenuta PPPD setta la nuova interfaccia di rete (ppp0) e va a dormire. Tutto a questo punto passa per il kernel. Pacchetti in transito e il resto vengono amministrati dal kernel. Voglio adesso interrompere la connessione. Dò il comando per sconnettersi. PPPD si risveglia e interrope il collegamento. PPPD toglie l'interfaccia di rete ppp0 avvertendo il kernel della disconnessione. Questo è tutto.
|
|
PPPD è in grado di fornire un elevato grado di sicurezza, sia sul client sia sul server. Per mettere a punto questa sicurezza si basa su tutta una serie di restrizioni su delle opzioni che un utente non privilegiato può usare. Molte delle opzioni di PPD possono essere usate solo da utenti privilegiati (root), in particolare quelle che permettono configurazioni potenzialmente dannose. Queste opzioni sono accettate solo nei files che sono sotto il controllo dell'utente root, o solo nel caso che pppd sia stato lanciato da root. Un utente qualunque, quindi, non può farle funzionare facendo girare pppd come setuid-root (s), sia dalla linea di comando, sia se sono specificate nel file dell'utente ~/.ppprc, ma funzioneranno solo se queste opzioni sono specificate nel file di configurazione generale di ppp (che può essere modificato solo da root) in /etc/ppp/options o nel file della connessione (vedremo questi files nella pagina seguente) in /etc/ppp/peers/nomeconnessione (anche questo solo modificabile da root). Può quindi questo essere un modo per potere settare opzioni privilegiate anche per gli altri utenti.
Un problema concreto collegato alla sicurezza e alle opzioni privilegiate riguarda l'apertura del device, ovvero quando pppd fà partire il modem. PPPD può aprirlo sia usando l'user id (UID) dell'utente normale che lo ha chiamato, sia l'UID dell'utente root (0), in base a dove è stato specificato il nome del device da usare. Nel caso che il nome del device sia stato scritto in una sorgente privilegiata (come /etc/ppp/options o /etc/ppp/peers/nomeconnessione), pppd userà tutti i privilegi di root alla sua apertura. In questo modo, l'utente root, creando il file appropriato in /etc/ppp/peers/, può permettere ad un utente qualsiasi di stabilire una connessione ppp per mezzo di quel device; device al quale non avrebbero avuto accesso. Negli altri casi (ad esempio dato da linea di comando o specificato in ~/.ppprc), pppd invocherà il device usando l'UID dell'utente, e ciò può, in base a molte altre impostazioni, provocare problemi del tipo "Not allowed".
|
|
L'autenticazione è quel processo nel quale un host convince un altro host circa la sua identià. Questo comporta uno scambio di dati, che di solito si tratta di inviare una coppia username e password da parte del primo host, e della verifica della presenza di questi dati nel database del secondo host. Di metodi per l'autenticazione ce ne sono vari. PPPD attualmente ne implementa 2 che sono il metodo PAP (Password Authenticating Protocol) e il CHAP (Challenge Handshake Authentication Protocol). Il metodo PAP comporta il client a inviare al server una coppia di username e password spedite in formato testo normale non crittato. Il metodo CHAP invece comporta il server a spedire al client una "sfida" (il pacchetto della "sfida" comprende il nome del server). Il client deve rispondere a questa "sfida" con una risposta che include il suo nome più un valore che sarebbe una specie di password. Questo metodo funziona un po' come un indovinello: il server fà l'indovinello e il client deve rispondere correttamente per fare vedere che conosce la risposta.
Il protocollo PPP permette a tutti e due gli host di autenticarsi. In questo caso però ci saranno più scambi di dati con un rallentamento della connessione e la possibile implementazione di più metodi e più segreti. Di default PPPD non richiede l'autenticazione da parte del server, ma dà la propria se richiesta. In ogni caso, pppd non si autenticherà nel caso non ci siano direttive per farlo.
Ci viene spontaneo chiederci: dove le mettiamo le nostre password e username? PPD custodisce le passwords in files che sono in /etc/ppp/pap-secrets per l'autenticazione PAP e in /etc/ppp/chap-secrets per l'autenticazione CHAP. I due files hanno lo stesso formato. Questi files possono contentere segreti sia per l'autenticazione di pppd al server, sia per l'autenticazione opposta. Ogni linea in file di questi contiene un solo segreto (che sarebbe la password). Ogni password può essere usata solo per determinate connessioni a determinati servers. Per questo motivo, ogni riga contiene almeno 3 campi: il nome del client, il nome del server e la password. Oltre a questo si possono aggiungere una lista di indirizzi IP che il client specificato può usare per la connessione al server specificato.
Ogni campo è identificato da una sola parola e le parole sono separate tra di loro da spazi o TAB. Quando il campo della password è preceduto da @, allora pppd supporrà che quello che segue è il nome del file in cui andare a leggere la password (molto sicuro). Quando nel campo del client c'è un *, allora vorrà dire che quella riga con quel segreto sarà usata per tutti i server. Qualsiasi altra parola saranno gli indirizzi IP da usare.
Come abbiamo detto un file segreto può contenere sia password per autenticare altri host, sia per autenticare sé stesso agli altri host. Nel primo caso (non di default visto che non richiede l'autenticazione) pppd cercherà la password nella riga il cui primo campo è il nome dell'host remoto, il secondo campo è il nome del sistema locale. Il nome del sistema locale è compost dall'hostname più il nome di dominio, se impostato. nel secondo caso pppd per prima cosa cerca il nome con il quale si identificherà al sistema remoto (lo username). Questo è specificato come opzione "user=" quando viene chiamato. Se non è settato, è usato il nome dell'host locale + dominio (se settato). Poi pppd cerca una riga nel file segreto il cui primo campo è lo username specificato (o il nome del localhost), il secondo campo è il nome dell'host remoto. Se si usa l'autenticazione CHAP il nome dell'host remoto è inviato dallo stesso e non si ha bisogno di specificarlo. Se invece usiamo PAP, questo può essere definito tramite il suo IP con l'opzione "remotename" (e quindi in formato numerico). Se pppd non trova un formato numerico, allora suppone che s ia il nome del file in /etc/ppp/peers con il quale è stato chiamato (molto comodo). Quando si procede all'autenticazione con PAP, la password inviata è prima comparata con quella del file segreto del server. Poi, se le password non sono uguali, questa viene crittata usando la funzione crypt() e controllata ancora. In questo modo le password possono essere salvate nel formato crittato se si desidera. Se viene passata a pppd l'opzione "papcrypt", il primo controllo non crittato è omesso, passando direttamente a quello crittato (più sicuro).
Durante la connessione, se è richiesta l'autenticazione dal server ma questo non riesce a darla a pppd, allora quest'ultimo terminerà il collegamento. Per questo nella maggior parte dei casi si usa l'opzione "noauth", che appunto non richiede l'autenticazione dal server.
|
|
Quando la negoziazione IPCP (Internet Protocol Control Protocol, suppongo) è completata con successo e la connessione è stato stabilita, ppd informa il kernel circa l'IP locale e remoto per l'interfaccio ppp. Questo è sufficiente per aprire una via ai pacchetti in transiti, che altrimenti non saprebbero dove andare, permettendo quindi lo scambio dei pacchetti tra i due punti. La comunicazione con altre macchine richiede gneralmente più modifiche alla tabella di routing. Alcune volte, come nel caso che l'unico collegamento ad internet sia attraverso l'interfaccio ppp, si può volere impostare una route di default per i pacchetti. L'opzione "defaultroute" di pppd causa pppd a creare questa route di default quando IPCP si inizializza, e la elimina quando il collegamento è terminato.
|
|
PPPD, come molti altri programmi, gestiscono gli errori in forma numerica. Ciò significa che quando si verifica un errore PPPD ritorna al log o al monitor un numero intero. Ci sono vari valori e per avere più informazioni vi rimando alla pagina di manuale di pppd ("man pppd"). Ecco gli errori:
0 = Tutto è avvenuto con successo.
1 = Un errore fatale tipo una chiamata di sistema fallita o una mancanza di memoria virtuale
2 = Errore nelle opzioni, tipo due opzioni contrarie specificate.
3 = pppd non è stato chmoddato a setuid-root (chmod u+s pppd) e l'utente che sta chiamando pppd non è root. Errore molto comune che vedremo in dettaglio nella pagina pratica.
4 = il kernel non supporta PPP. Altro errore frequente. Assicuratevi di avere installato tutti i moduli necessari.
5 = PPPD è stato terminato dopo una chiamata di sistema di tipo SIGINT, SIGTERM o SIGHUP (chiamate per terminare processi).
6 = la porta seriale non può essere loccata (usando l'opzione "lock"). Non si può quindi garantire un accesso esclusivo al device.
7 = la porta seriale non può essere aperta. Riguardatevi la parte sulla sicurezza.
8 = errore generico: lo script di connessione è fallito.
9 = il comando specificato come argomento al pty non può essere eseguito.
10 = la negoziazione ppp è fallita. Non ha potuto raggiungere il punto dove almeno un protocollo di rete (ad esempio IP) stava girando.
11 = Il server non è riuscito ad autenticarsi (o si è rifiutato). Per evitare questi problemi usate l'opzione "noauth".
12 = La connessione è avvenuta con successo, ma si è disconnesso perchè la connessione era completamente bloccata (idle)
13 = La connessione è avvenuta con successo, ma si è disconnesso perchè il limite massimo di tempo di connessione è stato raggiunto.
14 = Callback è stato negoziato e una chiamata dovrebbe arrivare a breve (?)
15 = Il collegamento è stato terminato perchè il server non rispondeva alle richiesto di tipo "echo".
16 = Il collegamento si è interrotto perchè il modem ha riattaccato.
17 = La negoziazione PPP è fallita perchè è stato riscontrato un loopback sulla linea seriale.
18 = Lo script di init è fallito (non ha dato 0 come ritorno).
19 = PPPD non è riuscito ad autenticarsi al server.
|
|
Probabilmente il pacchetto ppp è già incluso nella distribuzione, ma se vogliamo installare una nuova versione (o se non è incluso) ecco cosa dobbiamo fare per installare il pacchetto. Se il pacchetto è in .rpm o .deb allora usiamo i programmi per la gestione di questi pacchetti. Se invece sono in .tar.gz diamo:
$tar zxvf ppp-xxx.tar.gz
$cd ppp-xxx
$./configure
$make
#make install
L'ultimo comando deve essere dato come root. Non ci dovrebbero essere problemi nella configurazione e compilazione, ma se se ne dovessero riscontrare qualcuno potete leggere le pagine di README o INSTALL presenti nella directory. Il comando make install installerà gli applicativi che sono:
- pppd = il demone
- chat = usato per dialogare
- pppstats = mostra le statistiche sui pacchetti entrati/usciti
- pppdump
- le pagine di manuale (man)
- crea la directory /etc/ppp e ci mette dentro i file di configurazione di ppp di default.
|
|
Per stabilire una connessione si usa il demone pppd (come detto sopra). pppd ha questa sintassi:
pppd [tty_name] [speed] [options]
Dove tty_name è il device al quale è connesso il modem, speed è la velocità del modem e options sono le varie opzioni che prende. pppd può stabilire una connessione sia direttamente da linea di comando (scomodo perchè ogni volta dovremmo dare lo stesso lungo comando) sia da file di configurazione. Per vedere come funziona, vediamo prima un piccolo esempio di come stabilisce la connessione:
pppd connect 'chat -v "" AT OK ATDT0197750000 CONNECT' /dev/ttyS0 57600 crtscts debug defaultroute
e questo è solo un piccolo comando per una connessione base, ma illustra bene come si avvia pppd. Per prima cosa legge le opzioni che lo hanno chiamato (crtscts, debug e defaultroute), poi la periferica alla quale è connessa il modem (/dev/ttyS0), la velocità del modem (57600) e poi lancia il comando chat (connect 'chat -v "" .....'). All'interno degli apici sono comprese tutte le stringhe che chat invia e si aspetta dal modem. Vediamo ora come avviene la connessione tramite file di configurazione.
|
|
I files di configurazione di ppp si trovano di solito in /etc/ppp. Vediamo quali sono quelli di base:
- options = contiene tutte le opzioni che verranno passate a pppd. Questo file è quello primario. Ogni connessione stabilita tramite files di configurazione avrà queste opzioni.
- peers/ = questa directory contiene i files con l opzioni relative ad ogni connessione. Se ho due connessioni, una inwind e l'altra tin, avrò due files, chiamata con un nome a scelta, ma consiglio "inwind" e "tin". Se si imposta una connessione con questi files chiunque potrà effettuare questa connessione dial-up. Le opzioni contenute in questo file vengono dopo quelle di sistema contenute in "options". Quindi se due opzioni sono discordi, verranno prese quelle di sistema.
- chat-nomeconnessione = questo file contiene tutte le stringhe del comando chat. Ogni connessione può avere una propria sequenza diversa. In questo caso è consigliato salvare due files diversi con nomi chat-inwind e chat-tin (esempio sopra).
- pap-secrets = contiene le coppie username-password di ogni connessione. In questo file si fa corrispondere una coppia user-password ad un file di connessione contenuto in peers/. Questo file prende il nome dal metodo di autenticazione maggiormente usato (quello PAP). Ci può anche essere il file chap-secrets... Ma in Italia è sicuramente pap (nella maggioranza delle connessioni).
- ip-up = contiene una serie di comandi da eseguire quando la connessione è stabilita. Si può ad esempio specificare di attivare fetchmail per scaricare la posta una volta connessi.
- ip-down = analogamente a sopra, ma in questo caso quando la connessione è terminata. Si può fare per fare terminare fetchmail.
- ipv6-up/ipv6-down = uguali a quelli sopra, ma con protocollo TCPIPv6. Non lo tratteremo in questo tutorial, useremo l'IPv4.
- pppn.pid = contiene il PID (process ID) di pppd. Nella maggior parte dei casi, tuttavia, questo file è contenuto in /var/run/ insieme agli altri processi.
Come si lancia pppd usando i files di configurazione? Nel modo più semplice:
pppd call inwind
Come potete notare invece di "connect" c'è la dicitura "call" che indica: "chiama lo script di connessione /etc/ppp/peers/inwind". "call" quindi legge la directory peers/ e fa partire il file specificato. Una volta dato questo comando, per prima cosa pppd legge il file options per settare le impostazioni di sistema, poi esegue "call inwind" e và a leggere il file peers/inwind. Dentro questo files ci sono le opzioni di connessione relative solo a quella connessione e il nome utente a cui pppd andrà a fare corrispondere la password del file pap-secrects. Alla fine del file viene chiamato il programma CHAT. CHAT viene chiamato dicendogli di eseguire le stringhe contenute nel file /etc/ppp/chat-inwind. Quindi viene eseguito chat e le stringhe contenute in chat-inwind. Il modem si attiva, compone il numero, stabilisce il collegamente. Chat dice a pppd che il collegamente è stabilito e pppd avvia l'autenticazione. Ricerca quindi nel file pap-secrects lo username corrispondente a quello spcificato nel file peers/inwind e controlla che sia relativo a quella connessione. Legge la password e ci autentica. Quindi va a dormire e il resto lo sapete. Vediamo ora di configurare i singoli files:
/etc/ppp/options
In questo files probabilmente avrete già tutte le opzioni possibili di ppp inserite; alcune commentate altre no. Di qeusto file consiglio di commentare tutte le voci, in modo che se vogliamo inserire un'altra connessione in peers/ le cui opzioni vanno in conflitto con questo file, non dovremo sbatterci per modificarlo. Inseriamo quindi il simbolo # davanti alle voci. Questo file deve avere permessi 644 ed essere posseduto da root. Passiamo al file chiamato per secondo:
/etc/ppp/peers/inwind
Se questo file o directory non esiste non esitate a crearli. Ovviamente al posto di "inwind" inserirete il nome del vostro provider. In questo file inseriremo le opzioni di pppd, la chiamata a CHAT e lo username.
Vediamo un esempio di file peer/ standard funzionante:
# Questo file gestisce la connessione all'ISP inwind.
# Questo file è il primo chiamato da pppd (se dato con pppd call inwind) e contiene le opzioni di pppd. Alla fine chiama
# "chat" specificando un file contentente tutte le stringhe usate da chat per la connesione.
# il file è in /etc/ppp/chat-inwind.
# Permetto l'accesso esclusivo al device
lock
# Per prima cosa definisco che la connessione avverrà a /dev/modem, link di /dev/ttyS1
/dev/modem
# Imposto il controllo di linea tipo modem
modem
# setto la velocità, anche perchè non so quanto è
115200
# setto quali caratteri spedire come escape.
asyncmap 0
# non richiedo l'autenticazione del server
noauth
# uso il controllo hardware flow
crtscts
# setta una connessione passiva. Ovvero aspetta una risposta dal server invece che disconnetersi
passive
# Noipdefault
noipdefault
# setto questo come defaultroute
defaultroute
# metto in modalità debug
debug
# ad ogni connessione visualizza le opzioni usate (tolto perchè noioso)
#dump
# chiama con l'opzione connect il programma chat. Ad esso sono passate le opzioni -v (verbose),
# -f /etc/ppp/chat-inwind (cioè il nome del file che contiene le istruzioni chat).
connect 'chat -v -f /etc/ppp/chat-inwind'
# invio come username "ipotetico1". Tramite user "ipotetico1"
# definisco sia lo username da inviare per l'autenticazione, sia la riga da cui prelevare la
# password nel file /etc/ppp/pap-secrets per l'autenticazione
name "ipotetico1"
Come potete osservare la sintassi di questo file è molto semplice: tutte le linee commentate (precedute da #) non sono considerate, un opzione per riga. Anche questo file deve avere permessi 644 ed essere posseduto da root. Vediamo cosa significano le opzioni qui specificate e altre maggiormente usate. Per avere una lista completa vi consiglio di leggere il manuale di pppd (man pppd).
/dev/modem
Questa opzione è quella "tty_name" e serve per indicare a pppd il nome del device da usare. Come avrete letto nel commento dell'opzione /dev/modem è in realtà un collegamento simbolico a /dev/ttyS1, ovvero la seconda linea seriale (COM2). Se abbiamo un modem di questo tipo possiamo specificare /dev/modem e creare il link in seguito. In questo modo, se cambierete modem, non avrete bisogno di mettere mano ai file di configurazione, ma solamente ricreare il link al device nuovo.
115200
Questa opzione è "speed" e indica a pppd quale velocità usare per la connessione. Specificando 115200 usiamo la massima velocità supportata. Sempre meglio mettere così. Nel caso il modem sia più lento, il tutto andrà poi alla effettiva velocità del modem. Non poniamo quindi limiti.
asyncmap 0
Questa opzione specifica quali caratteri non possono essere ricevuti sulla linea seriale. PPPD chiederà al server di inviare questi caratteri come una sequenza di escape di 2byte di caratteri. L'argomento è un numero esadecimale a 32bit in cui ogni bit rappresenta un carattere di escape. Il bit 0 (come qui) - 00000001 rappresenta il carattere 0x00.
crtscts
Questa opzione permette di controllare il flusso di dati attraverso la linea seriale. Specifichiamola
defaultroute
Dice al kernel di settare la strada di default dei pacchetti (routing) a questo ISP.
lock
Crea un file di tipo UUCP per assicurare l'accesso esclusivo al device seriale.
passive
Abilita la connessione passiva. Con questa opzione, al collegamento pppd aspetterà passivamente una risposta dal server invece che disconnettersi nel caso che non arrivi (come farebbe senza questa opzione).
debug
Abilita il debugging. Con questa opzione pppd loggherà i contenuti di tutti i pacchetti di controllo inviati o ricevuti in forma leggibile. I pacchetti saranno loggati con Syslog. Si può fare in modo di scrivere tutto in un file configurando bene syslog.
dump
Come avrete visto questa opzione l'avevo inserita ma poi l'ho subito commentata. In ogni caso settando questa opzione verranno visualizzate tutte le altre opzioni di connessione usate all'avvio di pppd in console. Come potete intuire è noioso...
modem
PPPD userà le linee di controllo del modem. Per esempio pppd aspetterà che ci sia segnale di linea. L'opzione contraria è "local" (che ovviamente non implementerà questi controlli).
noauth
PPPD non richiederà l'autenticazione da parte del server. In questo modo si eviterà l'errore 11 e inutili perdite di tempo. L'opzione contraria è "a uth"
noipdefault
Con questa opzione PPPD il peer dovrà specificare l'indirizzo IP locale (fino a quando non sarà inserito automaticamente nel file di configurazione o dato per linea di comando. Si può passare semplicemente specificandolo su una riga a se stante.
name "ipotetico1"
Con name possiamo specificare il nome con cui ci autenticheremo al server. E' la nostra username. E' un'opzione privilegiata ed è quindi necessario che risieda in questo file. PPPD cercherà una riga nel file /etc/ppp/pap-secrets o chap-secrets con questo nome nel primo campo. Inseriamolo tra ""
Vediamo ora l'ultima parte che non abbiamo trattato: la chiamata a chat. Questa parte è forse la più facile. Riportiamo qui sotto la reiga intressata:
connect 'chat -v -f /etc/ppp/chat-inwind'
"connect" è un'opzione di pppd che chiama qualcosa che gli permetta di aprire il device. Questo qualcosa è compreso tra apici ed è il programma chat. Chat è chiamato con le opzioni -v (verbose) e -f, che permette di specificare un file dove sono presenti le stringhe di chat. Questo file è /etc/ppp/chat-inwind. Chiama quindi chat che legge le stringhe da inviare al modem in qusto file. Creiamolo con i comandi "touch" e modifichiamolo...
/etc/ppp/chat-inwind
Come abbiamo già detto chat è un programma che apre la connessione con il modem, compone il numero dell'ISP e poi si chiude passando il testimone a pppd. Per aprire la connessione si basa su una serie di stringhe che invia al modem intervallate da stringhe che si aspetta dal modem. Per usare chat dovete per forza avere un modem compatibile con le stringhe AT. I modem normali vanno di sicuro, ma non so come si comporta un winmodem... In ogni caso vediamo il file chat-inwind abbinato alla configurazione sopra:
# Questo file contiene le istruzioni necessarie per dialogare con il modem per connettersi
# alla Inwind. Sono una serie di istruzioni di CHAT.
# per prima cosa definisco per quali motivi annullerà l'operazione
TIMEOUT 60
ABORT ERROR
ABORT BUSY
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
# comincia a dialogare con il modem.
""
"AT&FH0"
OK
"ATDT0197750000"
TIMEOUT 75
CONNECT
Anche in questo file la sintassi è molto semplice: i commenti sono preceduti da # e si scrive una stringa per riga. Anche questo file deve avere permessi 644 ed essere posseduto da root.
CI sono vari tipi di stringhe:
- Stringhe di ABORT: ne potete vedere 4 nel listato sopra. Le stringhe ABORT sono tutte con la sintassi: "ABORT errore" (senza "") e servono per definire in quali condizioni l'operazione sarà annullata. l'errore non è altro che una stringa inviata dal modem. Con ABORT possiamo quindi definire per quali stringhe inviate dal modem, chat annullerà l'operazione. L'unica difficoltà sta nel fatto di sapere quali stringhe il vostro modem invia. Nella maggior parte dei casi sono BUSY, NO CARRIER, NO DIALTONE o il generico ERROR. Nel primo caso la linea sarà occupata, nel terzo non ci sarà il segnale di linea, nel secondo non c'è comunicazione. Si definiscono all'inizio del programma.
- Stringhe SAY: servono per scrivere qualcosa in terminale attraverso lo standard error. Se tuttavia Chat è stato avviato da pppd, come nel nostro caso, allora tutte queste stringhe saranno scritte nel file /etc/ppp/connect-errors. Potrebbero essere usate per mostrare una progressione nella connessione, ma è inutile se si una pppd.
- Stringhe TIMEOUT: servono per definire un valore in secondi massimo che deve passare tra l'invio di una stringa e la ricezione della risposta. Sorpassato questo limite il programma terminerà. All'inizio del file abbiamo settato TIMEOUT 60 e tra la composizione del numero e la ricezione della stringa CONNECT dal modem un TIMEOUT 75, dato che può richiedere più di un minuto in server affollati o linee lente...
Tutte le altre stringhe che vediamo nel file sono comprese tra virgolette "". Dentro le virgolette si specificano le stringhe da inviare al modem. Dopo una stringa con "", ne abbiamo una senza le virgolette. Queste stringhe sono quelle che ci aspetta dal modem.
Dopo avere definito le stringhe di TIMEOUT iniziale e quelle di ABORT, il programma chat comincia a dialogare. Per prima cosa si aspetta una stringa nulla (""). In questo modo il programma chat non aspetta che il modem sia attivo, pronto o qualcos'altro, velocizzando il tutto. La stringa successiva è "AT&FH0" che è inviata da chat al modem per inizializzarlo e impostare qualcosa, come ad esempio il volume del modem. La stringa base è di solito "ATZ" ma si possono aggiungere delle opzioni, come in questo caso. Per avere una lista delle stringhe supportate dal vostro modem potete cercare le sue caratteristiche o forse nel manuale dio istruzioni (ma non credo). Dopo avere inviato la stringa, chat si aspetta una stringa OK dal modem, per sapere se il modem ha reagito (in caso contrario potrebbe essere spento). Una volta ottenuto l'OK, allora invia una stringa del tipo "ATDT0197750000". la parte "ATDT" serve per comporre un numero con i toni e non a impulsi (come i vecchi modem). la parte numerica che segue è il numero dell'ISP da comporre. A questo punto il modem compone il numero e gli risponderà il server. Una volta che ha risposto, il modem ritorna al programma la stringa CONNECT. Una volta ricevuta questa stringa chat si chiude e si ritorna a pppd, che a questo punto amministrerà l'autenticazione.
Un file chat non è difficile e uno di questo tipo dovrebbe funzionare su tutti i tipi di modem AT. Passiamo ora all'ultima fase: l'autenticazione.
/etc/ppp/pap-secrets o /etc/ppp/chap-secrets
Una volta che pppd si è riattivato per l'autenticazione, riconosce il metodo di autenticazione proposto dal server. Nella stragrande maggioranza dei casi questo è il metodo PAP. Una volta riconosciuto, pppd invia come username quello contenuto nell'opzione "name "ipotetico1"" del file /etc/ppp/peers/inwind. Deve adesso cercare la password. In base al metodo di autenticazione, apre il file /etc/ppp/pap-secrets o /etc/ppp/chap-secrets. Dentro questo file, come abbiamo detto nella prima pagina, sono salvate le password corrispondenti ad ogni "name" e ISP usato. Vediamo il listato di questo file per la nostra configurazione:
# Questo file contiene tutte le autenticazioni per le varie connessioni:
"ipotetico1" inwind "password1"
Anche qui la sintassi è semplice: commenti con # e una riga per ogni password. La riga della password è composta minimo da tre campi (per maggiori informazioni leggete l'approfondimento della prima pagina): il primo campo è il valore di "name ...." usato nel file dell'ISP, il secondo è il nome del file usato per la connessione in /etc/ppp/peers/ e il terzo è la password. Il primo e l'ultimo campo devono essere compresi tra "" la password deve essere salvata in chiaro.
IMPORTANTE!!!!!!!!! Anche se la password è salvata in chiaro, nessuno a parte l'utente root potrà leggerla dato che i file pap-secrets o chap-secrets devono essere salvati con permessi 600 (u+rw), l'owner e il gruppo devono essere root. In questo modo pppd riuscirà comunque a leggere le password perchè pppd è setuid-root, ma nessun utente potrà aprirlo. Tra un campo e l'altro assicuratevi di usare il tasto TAB (non spazi!!!!)
/etc/ppp/resolv.conf
Di solito questo file è in /etc e non in /etc/ppp, ma usando programmi come KPPP si possono venire a creare dei conflitti. Dentro questo file dobbiamo specificare l'indirizzo IP del Name Server del nostro ISP. Il Name Server non è altro che il risolutore dei nomi di dominio (DNS, Domain Name System) a partire dagli indirizzi IP. Infatti, senza configurarlo, una volta connessi, non potremmo accedere a http://www.inwind.it, ma solo attraverso http://125.158.12.32 (IP messo a caso). Per settarlo linkiamo /etc/resol.conf a /etc/ppp/resolv.conf, e creiamo quest'ultimo. Eccom come appare:
nameserver 212.245.255.2
Dopo la dicitura "nameserver" facciamo seguire l'IP del Name Server dell'ISP. Questo indirizzo IP non cambia mai, ovviamente, e lo potete trovare tra le carte dell'iscrizione all'ISP. Ad esempio io l'ho trovato tra i riassunti della registrazione alla Inwind. Se non avete stampato queste carte potete sempre chiedere direttamente al gestore per email o cercare sul sito (di solito c'è scritto da qualche parte). Per gli utenti Wind come me quello riportato sopra è quello esatto.
Questo file deve avere permessi 644, owner root.root. Dopo avere creato il file, preoccupiamoci degli ultimi ritocchi:
/etc/ppp/ip-up
Questo file deve avere permessi 755 ed essere posseduto da root. Come potete notare è quindi un eseguibili che viene lanciato quando la connessione è stata effettuata con successo. Vediamone un esempio:
#!/bin/sh
# Questo file esegue i seguenti comandi quando la connessione PPP è stabilita.
# Per prima cosa scrive a video la dicitura:
echo "" > /dev/tty0
echo "Connessione Stabilita!" > /dev/tty0
echo "Dettagli connessione:" > /dev/tty0
echo "" > /dev/tty0
# visualizza a video i dettagli dell'interfaccia di rete riportati da ifconfig.
ifconfig | grep ppp0 > /dev/tty0
ifconfig | grep P-t-P > /dev/tty0
Come potete vedere la prima riga è la classica con cui comincia ogni Shell script. Dice dove trovare l'interprete di questi comandi, cioè la shell. Quello che segue sono una serie di comandi di Linux. Per creare un buon file, vi rimando al tutorial pubblicato da Arker su questo sito per la programmazione in Shell. Una differenza tra la programmazione in shell e questo è che per scrivere qualcosa a video bisogna fare una redirezione dell'output del comando alla console ( > /dev/tty0). In dettaglio questo file mostra la scritta "Connessione stabilita! Dettagli connessione:" a video e poi la parte riguardante l'interfaccia di rete ppp0 di ifconfig (non so perchè cmq non mi visualizza quest'ultima parte...qualcuno sa dirmelo?? :)
/etc/ppp/ip-down
Analogamente ad ip-up, questo file viene eseguito quando il collegamento si interrompe. Un esempio pratico può essere attivare fetchmail per scaricare la posta in demone all'attivazione dell'interfaccia, e killarlo alla sua disattivazione.
|
|
Se avete notato che per voi l'operazione è andata a buon fine, allora possiamo verificare se la connessione è andata a buon fine. Per prima cosa verifichiamo che l'interfaccia di rete sia stata configurata correttamente. Per verificarlo usiamo il comando "ifconfig". Dovreste ottenere un output simile al seguente:
$ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:409 errors:0 dropped:0 overruns:0 frame:0
TX packets:409 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:191490 (187.0 Kb) TX bytes:191490 (187.0 Kb)
ppp0 Link encap:Point-to-Point Protocol
inet addr:62.98.74.5 P-t-P:212.245.31.225 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:42 errors:0 dropped:0 overruns:0 frame:0
TX packets:45 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:21651 (21.1 Kb) TX bytes:2389 (2.3 Kb)
La parte che ci interessa è quella riguardante l'interfaccia ppp0. Se è simile a quella listata allora la vostra connessione è avvenuta con successo. Vediamo ora se la route è stata inviata con successo. Per farlo pinghiamo un indirizzo IP conosciuto, ad esempio quello del server remoto riportato nella prima riga dell'interfaccia sopra:
$ping 212.245.31.225
PING 212.245.31.225 (212.245.31.225): 56 octets data
64 octets from 212.245.31.225: icmp_seq=0 ttl=255 time=283.0 ms
64 octets from 212.245.31.225: icmp_seq=1 ttl=255 time=150.3 ms
64 octets from 212.245.31.225: icmp_seq=2 ttl=255 time=150.2 ms
64 octets from 212.245.31.225: icmp_seq=3 ttl=255 time=130.1 ms
64 octets from 212.245.31.225: icmp_seq=4 ttl=255 time=130.2 ms
64 octets from 212.245.31.225: icmp_seq=5 ttl=255 time=130.1 ms
--- 212.245.31.225 ping statistics ---
7 packets transmitted, 6 packets received, 14% packet loss
round-trip min/avg/max = 130.1/162.3/283.0 ms
Se ottenete un output simile a questo allora vuole dire che siete perfettamente connessi ad internet. L'ultima verifica riguarda la risoluzione dei nomi di dominio (vedete file resolv.conf). Diamo quindi un altro ping , però stavolta ad un nom e (www.inwind.it):
$ping www.inwind.it
PING www.inwind.it (195.210.91.83): 56 octets data
64 octets from 195.210.91.83: icmp_seq=0 ttl=118 time=149.6 ms
64 octets from 195.210.91.83: icmp_seq=1 ttl=118 time=150.0 ms
64 octets from 195.210.91.83: icmp_seq=2 ttl=118 time=139.9 ms
64 octets from 195.210.91.83: icmp_seq=3 ttl=118 time=139.9 ms
64 octets from 195.210.91.83: icmp_seq=4 ttl=118 time=150.0 ms
64 octets from 195.210.91.83: icmp_seq=5 ttl=118 time=140.0 ms
--- www.inwind.it ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 139.9/144.9/150.0 ms
Anche la configurazione del name server è a posto... Pronti per surfare????
Per maggiori informazioni vi rimando alla pagina di manuale di pppd e di chat. L'HOWTO sul PPP è esaustivo ma troppo esaustivo per i miei gusti. Scrivetemi con il messaggio privato per qualunque chiarimento.
Bye Bye Giulio (Ciuffi)
|
|
A questo punto per aprire la connessione dovremmo ogni volta dare un "pppd call inwind". Invece creiamo un file in /usr/sbin dal nome "ppp-on" con permesse 755 e posseduto da root. Questo file sarà un script di Shell e quindi vediamone il contenuto:
#!/bin/sh
#
# Questo file permette di connettersi ad internet, semplicemente digitando ppp-on invece di
# pppd call inwind.
#
echo "Tentativo di connessione ad Internet in corso..."
pppd call inwind
In questo modo quando dò $ppp-on mi scrive a video "Tentativo di connessione ad Internet in corso..." e poi mi fa partire la connessione.
Siamo ora pronti per fare la connessione. Proviamo direttamente da utente. Proviamo a dare un:
$ppp-on
Otteniamo però:
bash: ppp-on: command not found
Questo perchè nel path di un utente qualunque manca la directory /usr/sbin. Apriamo quindi il file /etc/profile e inseriamo il path /usr/sbin nella variabile $PATH:
# Set the default system $PATH:
PATH="/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/sbin:/usr/sbin"
e togliamolo da quello esclusivo per l'utente root:
# For root users, ensure that /usr/local/sbin, /usr/sbin, and /sbin are in
# the $PATH. Some means of connection don't add these by default (sshd comes
# to mind).
if [ "`id -u`" = "0" ]; then
echo $PATH | grep /usr/local/sbin 1 > /dev/null 2 > /dev/null
if [ ! $? = 0 ]; then
PATH=/usr/local/sbin:$PATH
fi
fi
Salviamo e chiudiamo quindi profile. Riproviamo a dare il comando:
$ppp-on
Otteniamo però:
/usr/sbin/pppd: must be root to run /usr/sbin/pppd, since it is not setuid-root
Settiamo quindi il bit setuid-root (praticamente sarà avviato con UID 0):
#chmod u+s /usr/sbin/pppd
Siamo arrivati alla fine. Per connettersi date il comando:
$ppp-on
Se avete ottenuto dei problemi interpretate l'errore (di solito riportato in /var/log/messages) e correggetelo.
|
|