Telnet è
un'applicazione standard di 'Internet ed è disponibile nella maggior parte
delle implementazioni del TCP/IP, indipendentemente dal sistema operativo host.
Si tratta di un semplice protocollo di login remoto, implementato secondo un
modello di tipo client-server, che permette ad un utente attestato ad una certa
macchina di stabilire una connessione TCP con un server di login che si trova su
un'altra macchina, la porta che utilizza è la numero 23. Subito dopo Telnet
rilancia i caratteri battuti sulla tastiera dell'utente direttamente al
calcolatore remoto come se essi fossero battuti su una tastiera direttamente
connessa ad esso. Inoltre Telnet rimanda l'output della macchina remota indietro
fino allo schermo dell'utente.
Il servizio è definito trasparente perchè dà l'apparenza che la tastiera e lo
schermo dell'utente siano attaccati direttamente alla macchina remota. Sebbene
Telnet non sia molto sofisticato se paragonato ad altri protocolli di terminale
remoto, esso risulta tuttavia largamente diffuso. Di solito, il codice client di
Telnet permette all'utente di specificare la macchina remota a cui ci si vuole
connettere dando il suo nome di dominio oppure il suo indirizzo IP.
Come aprire telnet
Telnet è un client presente di default in windows e ci si può accedere in tre
diversi modi:
1)premendo avvio/start, poi esegui e si digitando "telnet" nella
finestra di dialogo.
2)facendo click sul file "telnet.exe" presente nella cartella
"windows".
3)digitando "telnet" nel prompt ms-dos.
Generalità e Processi:
Telnet offre tre servizi di base. Per prima cosa, definisce un network virtual
terminal (terminale virtuale di rete) che fornisce una interfaccia standard
verso i sistemi remoti. Il programma client non può essere istruito sui
dettagli di tutti i possibili sistemi remoti, così esso è realizzato per usare
l'interfaccia standard. In secondo luogo, Telnet include un meccanismo che
permette ai due moduli client e server di negoziare delle opzioni,
e fornisce un insieme di opzioni standard (ad esempio, una delle opzioni
controlla se i dati trasmessi attraverso la connessione debbano essere
rappresentati mediante il set standard di caratteri ASCII a 7 bit oppure
mediante un set di caratteri ad 8 bit). Infine, Telnet tratta simmetricamente
entrambi gli estremi della connessione. In particolare, Telnet non obbliga che
l'input del client provenga da una tastiera, e nemmeno che l'output di tale
client sia costituito per forza da uno schermo. In questa maniera, Telnet
permette ad un qualsiasi programma di diventare utente del client.
Inoltre, entrambe le parti possono negoziare le opzioni. Quando un utente invoca
Telnet, un determinato programma applicativo sulla macchina dell'utente diviene
il client. Esso stabilisce una connessione TCP con il server, tramite la quale
comunica con questo. Una volta stabilita la connessione, il client legge i
caratteri battuti sulla tastiera dell'utente e li trasmette al server, e nel
frattempo legge i caratteri che il server gli ritorna
indietro per visualizzarli sullo schermo dell'utente. Il server deve accettare
la richiesta di connessione dal client, dopodiché deve rilanciare i dati
ricevuti tramite questa connessione al sistema operativo della macchina su cui
si trova. In pratica il server deve gestire connessioni multiple concorrenti. Di
solito, un processo padre aspetta su una determinata porta una richiesta di
connessione e, quando questa arriva, crea un processo figlio che gestisce tale
connessione. Perciò il processo illustrato rappresenta il processo figlio che
gestisce una particolare connessione.
Si adopera il termine pseudoterminale per descrivere il punto di ingresso (entry
point) del sistema operativo che permette ad un programma quale il server Telnet
di immettere caratteri nel sistema operativo della macchina remota facendo
credere a quest'ultimo che essi provengano da una tastiera. Sarebbe impossibile
realizzare un server Telnet senza che il sistema operativo fornisca una tale
possibilità. Se il sistema supporta un dispositivo di pseudoterminale, il
server Telnet può essere implementato mediante programmi applicativi. Nel
server, ogni processo figlio funge da collegamento tra il flusso di dati
provenienti dalla connessione TCP ed un particolare dispositivo di
pseudoterminale.
Fare in modo che il server Telnet sia un programma a livello applicativo
comporta sia vantaggi che svantaggi. Il vantaggio più ovvio è che risulta più
semplice la modifica ed il controllo del server rispetto al caso in cui il
codice sia contenuto nel sistema operativo. Lo svantaggio è chiaramente
l'inefficienza, poichè ciascun carattere deve viaggiare dalla tastiera
d'utente, attraverso il sistema operativo, fino al programma client, dal
programma client tornare al sistema operativo e, attraverso la connessione di
rete, arrivare alla macchina remota. Qui, i dati devono arrivare, attraverso il
sistema operativo, fino al programma applicativo server, e da quest'ultimo di
nuovo indietro al sistema operativo in un dispositivo di pseudoterminale.
Alla fine, il sistema operativo remoto invia il carattere al programma
applicativo che l'utente sta facendo correre. Si capisce che, nel frattempo,
l'output (compresi i caratteri di echo se tale opzione è stata selezionata)
viaggia a ritroso dal server al client lungo lo stesso percorso.
Passaggio di comandi per controllare la parte remota:
Sopra ho accennato al fatto che molti sistemi forniscono un meccanismo che
permette agli utenti di terminare un programma in esecuzione. Di solito, il
sistema operativo accoppia tale meccanismo ad un particolare tasto o sequenza di
caratteri. Ad esempio, a meno che l'utente non specifichi diversamente, molti
sistemi Unix riservano al carattere generato dalla sequenza Control-C la
funzione di interruzione. Digitando Control-C si costringe Unix a terminare il
programma in esecuzione; il programma non riceve Control-C come input. Il
sistema inoltre può riservare altri caratteri o sequenze di caratteri per altre
funzioni di controllo. NVT di Telnet adatta le funzioni di controllo definendo
come esse devono essere passate dal client al server.
Dal punto di vista concettuale, si immagina che NVT possa accettare immissioni
di caratteri da una tastiera in grado di generare più dei 128 possibili
caratteri. Si suppone cioè che la tastiera dell'utente abbia tasti virtuali
(immaginari) che corrispondono alle funzioni tipicamente usate per controllare i
processi. Ad esempio, NVT definisce un tasto concettuale di
"interruzione" ("interrupt") che serve a richiedere la
terminazione di un programma. Nella pratica, la maggior parte delle tastiere non
fornisce tasti in più per i comandi. Tuttavia, certi sistemi operativi o
interpreti di comandi presentano una varietà di modi per generarli. Abbiamo già
menzionato la tecnica più comune: accoppiare un determinato carattere ASCII ad
una funzione di controllo cosicchè,
quando l'utente preme il tasto, il sistema operativo effettua l'azione
appropriata invece di accettare il carattere come input. I progettisti dell'NVT
hanno scelto di tenere separati i comandi dal normale set di caratteri ASCII per
due ragioni. Per prima cosa, definire separatamente le funzioni di controllo
significa conferire a Telnet una maggiore flessibilità. Esso può infatti
trasferire tutte le possibili sequenze di caratteri ASCII tra il client ed il
server così come tutte le possibili funzioni di controllo. Inoltre, tenendo
separati i segnali dai normali dati, NVT permette al client di specificare i
segnali senza ambiguità, ovvero senza confusione circa il fatto se il carattere
immesso debba essere trattato come dato o come funzione di controllo.
Per mandare le funzioni di controllo attraverso la connessione TCP, Telnet le
codifica adoperando una cosiddetta sequenza di escape. Una sequenza di escape
usa un ottetto riservato per indicare che è in arrivo un ottetto in cui è
codificato un comando. In Telnet, l'ottetto riservato che apre una sequenza di
escape è noto come l'ottetto interpret as command (IAC). I segnali generati dai
tasti concettuali di una tastiera NVT corrispondono ciascuno ad un comando. Ad
esempio, per richiedere che il server interrompa il programma in esecuzione, il
client deve inviare la sequenza di due ottetti IAC IP (255 seguito da 244).
Comandi addizionali permettono al client ed al server di negoziare il set di
opzioni da usare e di sincronizzare la comunicazione.
Faccio notare che la codifica NVT di tutti i caratteri stampabili e di
controllo, qualora sia in vigore il comportamento di default, coincide con la
codifica standard ASCII a 7 bit, la quale comporta una corrispondenza di tali
caratteri con i primi 128 numeri naturali (da 0 a 127), e conseguentemente il
valore nullo del bit pesante (o più significativo, cioè quello a sinistra)
nell'ottetto che rappresenta il dato. Poichè la codifica NVT delle funzioni di
controllo prevede l'impiego di ottetti ai quali, secondo la rappresentazione
binaria, corrispondono numeri naturali maggiori di 128, cioè col bit pesante
settato ad 1, si evince che non può esservi confusione tra alcun dato e
qualsiasi ottetto di comando, in particolare l'ottetto IAC, formato interamente
da bit unitari (codifica decimale 255, cioè in binario 11111111).
Tale confusione può però verificarsi qualora sia in vigore l'opzione
cosiddetta di trasmissione binaria, la quale prevede l'uso di un set di
caratteri ad 8 bit, cioè di ottetti in cui il bit pesante può essere settato
ad 1 anche per la codifica di dati. In tal caso, è previsto che se deve essere
trasmesso un dato (ovvero un carattere) tale che l'ottetto che lo codifica è
uguale all'IAC, allora
tale ottetto deve essere trasmesso due volte.
size"4">Come si forza il server a leggere una funzione di
controllo:
size"2">L'invio delle funzioni di controllo assieme ai normali dati
non sempre è sufficiente per garantire il risultato desiderato. Per capire il
perchè, consideriamo la situazione in cui un utente vuole mandare la funzione
di controllo interrupt process al server. Di solito, un tale evento è
necessario quando il programma in esecuzione sulla macchina remota sta
funzionando male e l'utente vuole che il server termini il programma. Per
esempio, il programma potrebbe star eseguendo un loop infinito senza leggere
l'input o generare alcun output. Sfortunatamente, se l'applicazione sulla
macchina remota smette di leggere l'input, i buffer del sistema operativo si
riempiono ed il server non potrà più scrivere dati sullo pseudoterminale.
Quando ciò accade,
è previsto che il server smetta di leggere i dati che provengono dalla
connessione TCP, i cui buffer di conseguenza si riempiono. In una circostanza
del genere, l'entità TCP sulla macchina del server notifica la situazione
all'entità paritaria sulla macchina locale informandola circa la dimensione
nulla della finestra di flusso, ed in seguito a tale notifica si interrompe il
flusso di dati lungo la connessione. Se l'utente genera una funzione di
controllo di interruzione nel momento in cui i buffer sono pieni, la funzione di
controllo non raggiungerà mai il server. Ovvero, il client può senz'altro
generare la sequenza di comando IAC IP e
scriverla sul proprio socket, ma poichè l'entità TCP ha interrotto la
trasmissione verso l'entità paritaria remota, il server non potrà leggere la
suddetta sequenza di controllo. Per risolvere il problema, Telnet adopera un
segnale cosiddetto fuori-banda
(out of band signaling). Il TCP implementa la segnalazione fuori banda col
meccanismo di urgent data. Ogniqualvolta deve inserire una funzione di controllo
all'interno del flusso di dati, il modulo client di Telnet genera un comando di
SYNCH, costituito dalla sequenza "IAC (segnale utente) IAC DMARK" (per
esempio, se l'utente ha generato il segnale di interrupt process premendo la
combinazione Control-C sulla propria tastiera, il comando di SYNCH sarà formato
dalla sequenza "IAC IP IAC DMARK"). Tale sequenza viene passata
all'entità TCP sottostante contemporaneamente ad un'apposita segnalazione che
forza la stessa entità TCP a trasmettere un segmento (col bit di URGENT DATA
settato ad 1) che elude il controllo di flusso e giunge immediatamente all'entità
TCP remota.
Questa, ricevendo un così fatto segmento, segnala al modulo server di Telnet
che sono arrivati dati con la massima priorità, ed è previsto che il server,
in virtù di una tale segnalazione, scarichi dal buffer della connessione TCP
tutti i dati che trova, continuando però ad interpretare i comandi. Di
conseguenza il server, durante tale operazione, è destinato ad incontrare
dapprima la sequenza di comando "IAC (segnale utente)", dalla quale
capisce cosa l'utente vuole che faccia, e subito dopo la sequenza di comando
"IAC DMARK", che ha il significato "torna al normale modo di
processamento".
Opzioni di Telnet:
Finora abbiamo omesso la descrizione di uno degli aspetti più complessi di
Telnet: le opzioni. In Telnet, le opzioni sono negoziabili, e rendono possibile
a client e server riconfigurare la loro connessione
Ad esempio, abbiamo già detto che di solito il flusso di dati è a 7 bit e gli
ottetti col bit pesante settato ad 1 sono usati per passare informazioni di
controllo come il comando di interrupt process. Comunque, Telnet fornisce anche
un'opzione che permette a client e server di scambiarsi dati ad 8 bit (quando
questo succede, l'ottetto riservato IAC deve essere raddoppiato se appare come
dato). Client e server hanno bisogno di una fase di negoziazione, ed entrambi
devono accettare il passaggio di dati ad 8 bit prima che un tale tipo di
comunicazione sia possibile.
L'area delle funzionalità delle opzioni Telnet è vasta: alcune estendono le
possibilità in modo maggiore, mentre altre si occupano di dettagli meno
importanti. Per esempio, il protocollo originale fu progettato per un ambiente
half-duplex in cui era necessario dire all'altra parte di "andare
avanti" (go ahead) prima che essa potesse trasmettere altri dati. Una delle
opzioni controlla se Telnet opera in modo half-duplex o full-duplex. Un'altra
opzione permette al server sulla macchina remota di determinare il tipo di
terminale d'utente. Il tipo di terminale è importante per il software che
genera le sequenze di posizionamento del cursore (ad esempio un editor a tutto
schermo in esecuzione sulla macchina remota).
La maniera in cui Telnet negozia le opzioni risulta interessante. Siccome
talvolta ha senso anche per il server iniziare l'esecuzione di una particolare
opzione, il protocollo prevede di permettere ad entrambe le parti di effettuare
una richiesta. In tal maniera, si dice che il protocollo è simmetrico per
quanto riguarda il processamento delle opzioni. Entrambe le parti inoltre
rispondono ad una richiesta con un'accettazione o un rifiuto. Nella terminologia
Telnet, la richiesta è WILL X, che significa permettimi di usare l'opzione X; e
la risposta può essere sia DO X che DON'T X, ovvero rispettivamente ti permetto
di usare l'opzione X e non ti permetto di usare l'opzione X.
La simmetria consiste nel fatto che DO X richiede che il ricevente cominci ad
usare l'opzione X, mentre WILL X o WON'T X significa voglio cominciare ad usare
l'opzione X o non voglio cominciare ad usarla.
Un altro interessante aspetto della negoziazione consiste nel fatto che entrambi
i moduli Telnet devono essere in grado di eseguire una implementazione base di
NVT (cioè senza alcuna opzione in vigore). Se una delle due parti tenta di
negoziare un'opzione che l'altra non capisce, la parte che riceve la richiesta
si limita semplicemente a declinare l'invito. In questa maniera, è possibile
fare interagire versioni di moduli Telnet più recenti e sofisticate (cioè
software che comprende più opzioni) con versioni meno sofisticate. Se sia il
client che il server capiscono le nuove opzioni, essi potranno incrementare la
qualità dell'interazione, altrimenti faranno riferimento ad uno stile meno
efficiente ma comunque funzionante.
