Progetto e configurazione di una rete
Progetto e configurazione di una rete |
|
|
|
Per la realizzazione di questo modulo useremo
Netkit4TIC
con la
connettività
con la rete reale (leggere il file README)..
Scarica il tarball
contenente tutto il necessario e
scompattalo in una sottodirectory della tua HOME directory.
Usa questo utile
IP calculator
(apt-get show ipcalc) per calcolare network, netmask,
broadcast, hostMin e hostMax (IPv4 only).
Questa esercitazione è intesa come banco di prova per una rete reale. Credo di poter affermare con serenità che il numero di ore spese per l'installazione e la configurazione di una rete virtuale sia nettamente inferiore alla sua controparte reale visto che il risultato finale sono file di configurazione funzionanti "al primo tentativo".
La lista dei passi:
La mappa (pdf, xml) della rete è, con buona approssimazione, quella della rete sperimentale che puoi trovare nel modulo 10.
Configurazione DNS |
|
Per prima cosa consiglio di leggere la documentazione sull'implementazione DNS di bind e in seguito provare l'esperienza virtuale su DNS.
In questa prima versione sono stati
configurati i DNS in modo da poter usare il dominio tic.fdns.net.
L'esercizio è completo con la simulazione del DNS per il
ROOT-SERVER, per i domini net,
fdns.net,
tic.fdns.net e il dominio "inverso" in-addr.arpa.
Per quest'ultimo abbiamo deciso che il dominio
5.57.216.in-addr.arpa sia gestito da ns.net mentre
5.57.217.in-addr.arpa da ns.fdns.net. Per
la delegazione di 216/29.5.57.217.in-addr.arpa a
ns1.tic.fdns.net ho usato la documentazione presente in
RFC 2317.
Sollecitiamo l'intero sistema di risoluzione in modo da analizzare il funzionamento e i meccanismi dei sistemi coinvolti:
SSO-server# host ns.fdns.net
ns.fdns.net has address 216.57.5.215
Ogni nodo ben configurato ha il risolutore dei nomi impostato
per chiedere il servizio al propio gestore di dominio.
Tale configurazione è memorizzata nel file
/etc/resolv.conf. Quando il server
interpellato (srv1.tic.fdns.net) riconosce
di non essere autoritativo chiederà la risoluzione al
ROOT server che in seguito rimanderà al
server autoritativo per net che a sua volta rimanderà
al server autoritativo per fdns.net che a sua volta rimanderà
al server autoritativo per tic.fdns.net che alla fine
risolverà il nome in indirizzo. A questo punto il primo server
interpellato ha la risoluzione dell'indirizzo e la comunicherà
al client. Nello stesso tempo memorizza in una cache il risultato
in modo tale da rispondere velocemente ad una successiva identica
richiesta.
Ecco le tracce di quello che succede nel server
ns1.tic.fdns.net rispettivamente nell'interfaccie
eth0 ed
eth1
durante la richiesta dell'host SSO-server. Se
lo stesso server richiede in seguito la stessa informazione
non troveremo alcuna attività sull'interfaccia eth0
e invece una rapida risposta sull'interfaccia
eth1.
Per ottenere la lista dei root server nel caso reale avremmo dato il comando:
$ dig @ns.icann.org ns +nocomment +nostats +nocmd +noquestion
mentre nel nostro caso virtuale:
SSO-server# dig @ns.fdns.net ns +nocomment +nostats +nocmd +noquestion
. 604452 IN NS ROOT-SERVER.
ROOT-SERVER. 604452 IN A 216.57.5.213
cambia solo il risultato ;-)
Verifichiamo ora la view esterna:
fdns# dig tic.fdns.net any +nocomment +nostats +nocmd +noquestion
tic.fdns.net. 604680 IN MX 20 smtp2.tic.fdns.net.
tic.fdns.net. 604680 IN MX 0 smtp.tic.fdns.net.
tic.fdns.net. 604680 IN NS ns2.tic.fdns.net.
tic.fdns.net. 604680 IN NS ns1.tic.fdns.net.
tic.fdns.net. 604680 IN SOA ns.tic.fdns.net. \
root.ns.tic.fdns.net. 2003061901 10800 3600 604800 86400
tic.fdns.net. 604680 IN A 217.57.5.219
tic.fdns.net. 604680 IN NS ns1.tic.fdns.net.
tic.fdns.net. 604680 IN NS ns2.tic.fdns.net.
ns1.tic.fdns.net. 604680 IN A 217.57.5.219
ns2.tic.fdns.net. 604680 IN A 217.57.5.220
e quella interna:
SSO-server# dig tic.fdns.net any +nocomment +nostats +nocmd +noquestion
tic.fdns.net. 604800 IN A 10.10.10.65
tic.fdns.net. 604800 IN SOA tic.fdns.net. \
root.tic.fdns.net. 2003061902 10800 3600 604800 86400
tic.fdns.net. 604800 IN NS ns1.tic.fdns.net.
tic.fdns.net. 604800 IN NS ns2.tic.fdns.net.
tic.fdns.net. 604800 IN MX 0 smtp.tic.fdns.net.
tic.fdns.net. 604800 IN MX 20 smtp2.tic.fdns.net.
ns1.tic.fdns.net. 604800 IN A 10.10.10.65
ns2.tic.fdns.net. 604800 IN A 10.10.10.66
Configurazione MTA |
|
In questa esercitazione è stato
configurato l'MTA di tic.fdns.net in modo da poter testare l'invio
di posta verso
il dominio tic.fdns.net. Il servizio è gestito da Postfix
(in precedenza da
sendmail).
L'esercizio si basa sullo step precedente e nel settaggio di Postfix
sui nodi ns.net, ns.fdns.net e
ns.tic.fdns.net.
Per questo lavoro ho attinto dall'esperienza su
lab-eMail
in cui viene usato Postfix come MTA. In aggiunta abbiamo installato
ipopd come server POP e uw-imapd come server IMAP
entrambi con TLS e Kerberos abilitati. Tali servizi sono attivati
"a richiesta" da xinetd (il successore dell'Internet
super-server inetd).
Il client che abbiamo usato è
Mutt che ha capacità
di connessione SSL con protocollo POP o IMAP. Inoltre abbiamo installato
squirrelmail in modo da provare anche una interfaccia WEB mail.
Per le stazioni che non hanno un proprio server di posta abbiamo configurato Postfix nella modalità "null client".
Iniziamo con un test del funzionamento della configurazione della e-mail
con lo scopo di mostrare la struttura di un messaggio di posta
utilizzando il comando telnet.
Nella macchina srv1 sono già definiti due
utenti tizio e caio con password
not24get.
Supponiamo che l'utente tizio all'interno del
nodo
ns.fdns.net voglia spedire
una mail all'utente caio@tic.fdns.net:
fdns# telnet mail.tic.fdns.net 25 Trying 217.57.5.219... Connected to mail.tic.fdns.net. Escape character is '^]'. 220 mail.tic.fdns.net ESMTP Postfix (Debian/GNU) HELO ns.fdns.net 250 mail.tic.fdns.net MAIL FROM: <root@fdns.net> 250 Ok RCPT TO: <caio@tic.fdns.net> 250 Ok DATA 354 End data with <CR><LF>.<CR><LF> Questo e' un messaggio composta da una sola riga a scopo di test . 250 Ok: queued as E4CC012262 QUIT 221 bye Connection closed by foreign host.
Ora utilizzamo invece Mutt sempre dal nodo ns.fdns.net
per spedire un secondo messaggio di test a caio@tic.fdns.net.
fdns# mutt -s test caio@tic.fdns.net < test-mail.txt
Ora proviamo ad accedere, anche da nodi diversi, alla casella di caio attraverso protocollo POP3 verificando l'avvenuta recapitazione del messaggio:
fdns# mutt -f pop://caio@pop.tic.fdns.net/ SSO-server# mutt -f pop://caio@pop.tic.fdns.net/
oppure attraverso il protocollo imap:
fdns# mutt -f imap://caio@imap.tic.fdns.net/ SSO-server# mutt -f imap://caio@imap.tic.fdns.net/
Volendo ora provare l'interfaccia WEB, attiviamo sia il server
Apache che il server MySQL essenziali per squirrelmail:
srv1.tic.fdns.net# /etc/init.d/apache start srv1.tic.fdns.net# /etc/init.d/mysql start
Per accedere alle mailbox via WEB
useremo la
connettività
con la rete reale (leggere il file README) che ci
permette l'uso del browser dell'host reale:
realHost$ mozilla-firefox http://192.168.77.2/squirrelmail
ed ecco come appare dopo essersi autenticati come utente caio.
Verifica server di backup |
|
Il servizio DNS e il servizio Mail del dominio tic.fdns.net
sono configurati come servizi primari nel nodo srv1
e come servizi secondari nel nodo srv2.
La verifica di questa impostazione può essere fatta da un
qualsiasi nodo con il comando:
SSO-server# host -t mx tic.fdns.net tic.fdns.net mail is handled by 20 smtp2.tic.fdns.net. tic.fdns.net mail is handled by 0 smtp.tic.fdns.net. fdns# host -t mx tic.fdns.net tic.fdns.net mail is handled by 20 smtp2.tic.fdns.net. tic.fdns.net mail is handled by 0 smtp.tic.fdns.net.
Ora mettiamo alla prova la ricezione della posta nel caso che il server smtp primario sia non operativo (ad esempio per guasto o per manutenzione):
srv1# /etc/init.d/postfix stop
Stopping mail transport agent: Postfix.
Spediamo una mail ad un utente del dominio:
SSO-server# mutt -s test tizio@tic.fdns.net < test-mail.txt
Il servizio SMTP del nodo SSO-server.tic.fdns.net quando
tenterà di mettersi in comunicazione con il gestore della
mail del dominio tic.fdns.net ossia con
smtp.tic.fdns.net
non riceverà
risposta e quindi il messaggio verrà mandato al nodo
smtp2.tic.fdns.net
il quale a sua volta tenterà di mandarlo al nodo
smtp.tic.fdns.net che però è down.
Il messaggio viene perciò accodato nel nodo
smtp2.tic.fdns.net
che a intervalli di tempo tenterà l'invio verso il
server smtp.tic.fdns.net.
Al ripristino del servizio:
srv1# /etc/init.d/postfix start
Starting mail transport agent: Postfix.
simuliano, per impazienza, un flush delle code del server secondario:
srv2# mailq -q
e sperimenteremo la ricezione della mail da parte dell'utente
tizio@tic.fdns.net. Tutto questo è tracciato
nella cattura del traffico smtp
(FILE ACP)
e nel seguente
screenshot.
|
|
Sandro Doro (email me)