[Revision Log]
17-08-2006 09:00 - modificata sezione dhcp
17-08-2006 09:40 - aggiunta sezione routing
17-08-2006 10:45 - modificata sezione introduttiva che potrebbe indurre delle incomprensioni. tnx wgator per la segnalazione
Visto che non ho un cacchio da fare e che in ufficio non c'è assolutamente nessuno in questo periodo estremamente estivo (14 gradi alle 14:00 del pomeriggio eheheh)....ed inoltre sono in vena ormai di guide come se piovesse...vi beccate il nat, pat, firewall etc... cosa che inizialmente volevo mettere nell'altra guida Cisco, ma che reputo argomento a parte.
La presente guida si riferisce solo ad un certo tipo utilizzo dei routers, cioè all'utilizzo casalingo. Molte cose sono state omesse, molti argomenti presi superficialmente. Tutte le soluzioni che do tengono conto SOLO dell'utilizzo casalingo. Per le infrastrutture business il discorso è differente, anche se la maggior parte delle cose dette qui si possono ricondurre anche a piccole reti aziendali con poche pretese.
PREMESSA
Il discorso qui è abbastanza complesso e necessiterebbe di conoscenze basilari un po ampie su alcuni aspetti. Tuttavia tenterò di essere il piu pratico possibile e di non fare una guida troppo teorica.
Tengo a sottolineare che la guida è rivolta solo ai possessori di router. I modem funzioano in tutt'altra maniera.
Inoltre le guide che ho trovato in giro sono troppo troppo tecniche e non di facile comprensione. Il mio scopo è, spero, quello di rendere la cosa digeribile alla maggior parte delle persone.
Infine tutto il discorso è solo riferito alla strutture piu comuni che usiamo tutti i giorni a casa e non al caso generale.
NAT, PAT: cos'è a cosa serve e come funziona.
Perche esiste e a che cosa serve il NAT/PAT?
La tecnica di natting/patting (Network Address Translation, Port Address Translation) nasce dal fatto che l'attuale sistema indirizzamento ip a 32 bit (ipv4), ha raggiunto infine la saturazione: vale a dire gli indirizzi ip sono finiti, o stanno finendo. La tecnica del nat consente ad intere lan di "essere viste" dall'esterno, cioe dalla rete pubblica internet, come un singolo host e quindi avere assegnato un solo indirizzo ip pubblico, invece di avere un indirizzo per ogni host pubblico.
Perche i pacchetti in Internet non possono girare con gli ip privati delle lan?
Questo è una di quelle cose che necessiterebbe la conoscenza del processo di routing. Di fatto, prendetelo come buono, in una rete con uno o piu router, tutte le reti divise da questo/i router, NON possono avere indirizzi ip che stanno sullo stesso spazio di indirizzamento, o sulla stessa subnet. ES:
Lan1: host: 192.168.1.1 255.255.255.0
Lan2: host: 192.168.1.2 255.255.255.0
Divise da un router. Questo non funzionarà. Non si puo'.
Differenza tra NAT e PAT
Il NAT modifica SOLO l'ip il PAT la porta del pacchetto. Nella maggior parte dei casi, ma soprattutto per il 99,9% dei casi nei router che usiamo a casa, il processo è ibrido NAT+PAT.
Il solo NAT presuppone di avere un pool (una serie) di indirizzi pubblici da associare all'indirizzo privato. Visto che l'indirizzo pubblico è unico ed è fornito dinamicamente dal provider, se uno a casa ha piu di un pc collegato, solo uno dei due a turno potrebbe uscire in internet.
Il NAT + PAT, permette di associare piu indirizzi lan privati, mantenendo un unico indirizzo pubblico e variando la porta. Quindi ad esempio:
lan1pc1 192.168.1.1
lan1pc2 192.168.1.2
dopo il NAT/PAT:
wanpc1: 212.1.1.1:1000
wanpc2:212.1.1.1:1001
quindi NAT (variazione dell'ip) e PAT (variazione della porta).
Come funziona?
La parola stessa lo dice: viene modificato il pacchetto ip e/o la porta, dove all'interno risiedono l'indirizzo di destinazione e l'indirizzo sorgente. In teoria possono essere modificati tutte e due gli indirizzi e porta (destinazione e sorgente), ma noi ci occuperemo solo del sorgente.
Il processo avviene creando una tabella di associazione (nat table) che accoppia le richieste in uscita dalla lan a un set di porte (scelte a caso dal router di volta in volta) ed a un indirizzo ip pubblico fornito dal provider.
ES:
Lanpc:192.168.1.1
Wanrt: 212.1.1.1
Il pc richiede una pagina web che ha indirizzo 151.1.1.1
-il pc manda il pacchetto al gateway (router), con indirizzo sorgente 192.168.1.1 e destinazione 151.1.1.1
-il router memorizza nella nat table che 192.168.1.1 ha richiesto una pagina che ha indirizzo 151.1.1.1
-il router sostituisce l'indirizzo sorgente nel pacchetto e ci mette quello pubblico del router 212.1.1.1 assegnato dal provider, e cambia la porta. Facciamo finta 212.1.1.1:1000
-viene memorizzato tutto nella nat table.
-il pacchetto torna indietro con le informazione richieste (la pagina web)
-il router controlla nella nat table se qualcuno all'interno della lan ha richiesto dei pacchetti provenienti da questo ip.
-se c'è una corrispondenza, sostituisce l'ip di destinazione con l'ip privato trovato nella tabella.
-e il pacchetto arriva all'host della lan
Questo è il funzionamento del NAT/PAT.
DMZ
Il fatto che esista una tabella di nat, fa si che tutti i pacchetti NON richiesti dalla lan (cioè pacchetti che non hanno corrispondenza nella nat table) vengano droppati (scartati) dal router e non inoltrati all'interno. Esiste pero un metodo di funzionamento, il DMZ (DemilitaredZone), che indica al router di forwardare (instradare) all'interno della lan, a tutti gli hosts, TUTTI i pacchetti in arrivo dalla rete pubblica. E' un sistema che viene di solito usato per i server pubblici, che hanno pero pool di indirizzi pubblici e comunque isolati dalle lan per ovvi motivi di sicurezza.
Ne sconsiglio vivamente l'utilizzo.
FIREWALLING
Il firewalling è una tecnica volta alla creazione di regole (rules) e all'ispezione dei pacchetti per motivi di sicurezza.
Trovo che il fatto che girino molti firewall software abbia fatto nascere delle idee distorte sul cosa siano e come funzionino tali firewall. Un firewall è un sistema che funziona a livello pachetto ip, non a livello dati.
Il modulo software dei firewall che è installato in praticamente su tutti i router è per la maggior parte dei casi assolutamente inutile. Non è assolutamente necessario perderci un secondo di tempo ma lasciate tutto come stà. Delle porte da aprire ce ne occupiamo poi.
Quand'è che ho necessita di usare un firewall?
Una delle cose che mi da piu fastidio a questo mondo, è il fatto di fregare la gente. Fare leva sull'ignoranza per vendere cose assolutamente, in certi casi ovviamente, inutili a prezzi folli. Il caso piu eclatante è quello del firewall.
Potrei elencare decine e decine di casi in cui firewall installati e configurati (male) era praticamente come se non esistessero, e nella maggior parte dei casi non sarebbero nemmeno serviti.
Quando il firewall ha un senso?
Ricordando il fatto che stiamo parlando di router e non di modem, il firewall ha senso quando:
- ho un pool di indirizzi pubblici, per cui il router non fa nat e gli host sono direttamente raggiungibili dalla rete pubblica.
- sono in DMZ
e basta. (ribadisco il fatto che stiamo considerando il sottoinsieme di utenza casalinga, per le reti lan di un certo spessore la storia è un altra...ma neanche tanto diversa)
Ma soprattutto perche?
Come vi dicevo prima, i pacchetti vengono forwardati all'interno della lan solo se esiste un match (corrispondenza) sulla nat table. Fine del discorso. Niente entra se non è rischiesto da un host interno.
PORTFORWARDING
PREMESSA: questo paragrafo dovrebbe andare su NAT ma è necessario leggersi parte del precedente paragrafo per capire meglio.
Credo che questo sia l'argomento di maggior interesse per tutti. Dando per scontato che abbiate capito (e soprattutto letto...) tutta la mia pappardella
, sfatiamo un mito:
- il portforwarding non è firewalling.
Quando uno imposta una regola di port forward (in alcuni router li chiamano virtual server... o altri nomi strani e fantasiosi, giusto per fare ancora di piu confusione) NON si creano regole di firewalling. Se qualcuno mi dicesse ma iptables? Ecco iptables è un modulo ibrido di linux (e di alcuni router/firewall linux based) e comprende anche nat.
Dicevamo: il portforward è una associazione MANUALE che si fa sulla tabella NAT. E' una specie di sottoinsieme del DMZ.
Perchè?Alle volte c'è la necessita che i pacchetti che arrivano dall'esterno, non debbano essere necessariamente richiesti prima dall'interno (tipo quando si gioca online o sul mulo). In questi casi è sufficiente indicare al router su quali porte (PAT) e su quale indirizzo ip lan interno (NAT) mandare i pacchetti che arrivano su porte che noi conosciamo a priori. La regola:
allow source: any destination: any = DMZ. Siamo daccordo?
Quindi evitate di usare any ma usate sempre ip.
Il sito
http://www.portforward.com/default.htm indica la configurazione corretta per praticamente qualsiasi router in circolazione per qualsiasi programma riguradante il portforwarding.
ES:
porta pubblica di un gioco: 1050
porta privata (la stessa): 1050
ip privato : 192.168.1.1
regola:
source port:1050
private port: 1050
lan ip: 192.168.1.1
Nella maggior parte dei casi, c'è un implicito source ip address (pubblico): any. Altrimenti lo dovete specificare a meno che non siate sicuri dell'ip pubblico che vi interessa.
Corrette impostazioni di un firewall (nel caso in cui ne abbiate bisogno...)
Supponendo che ne abbiate veramente bisogno, le tecniche di firewalling sono complesse da spiegare cosi, pero esiste la regola MASTER che ogni utente amministratore, pinco pallino deve seguire come la bibbia:
PRIMA REGOLA
- porte tutte chiuse e traffico disabilitato su tutti gli indirizzi.
da qui in poi si abilitano ad uno a uno tutti i servizi necessari alla lan.
Poi ci sarebbe altra roba, ma già cosi per una piccola lan è sufficiente.
ROUTING (buttato un po lì ma per dare l'idea 
)
Ho scritto stà roba l'altro giorno per ripondere (spero poi che abbia capito...
) ad un utente che mi chiedeva lumi. Siccome mi è piaciuto molto quello che ho scritto (uh?
) lo posto nella speranza che capiate qualcosa e vi facciate un idea sull'arcano argomento.
La metafora
Immagina di essere in macchina nella tua citta (nella tua LAN). Tu sei il bel pacchetto che se ne va in giro tranquillo per la città in macchine e va a trovare tutti i suoi amici hosts. Che tu sai dove abitano perche abitano nella tua città.
A sto punto pero devi andare da uno che non conosci e che abita in un punto che non sai ma di cui conosci il nome. L'unica uscita dalla tua città è l'autostrada e tu sai dov'è (che è il gateway, cioè il router), perche è sempre nella tua citta (lan). Prendi l'autostrada.
Mentre viaggi nell'autostrada vedi i cartelli (la tabella di rounting che ti dice che per andare in un certo posto devi prendere una certa via). Segui i cartelli (in realtà sono i cartelli a livello di routing che portano te ma è per fare un esempio) fino che trovi l'uscita che ti porta o su un altra autostrada, ma sempre piu vicino alla destinazione, oppure direttamente nella paese (lan) dove abita il tuo amico che non conosci. Questo è il routing.
Come si formino le tabelle di routing è un altra storia, ma è per dare l'idea.
A ip life: how does all the system works and a funny tale 
credetemi che non ho mandato tutto in vacca, secondo me da molto l'idea!
L'idea è quella di far capire che non è l'ip che decide ma è il router che "obbliga". Di fatto in tutti i testi l'ip è indicato come protocollo "routed" (ruotato).
Interpreti:
pacchetto ip: IP
router: RT
switch:SW
IP:"azz , mi tocca uscire dalla lan oggi, chissà che casino sulle dorsali...vabbe, partiamo!"
IP:"ok allora devo andare qui. E' fuori la mia lan per cui mi dirigo al punto di uscita, vado sul router"
IP:"hey RT?"
RT:"uh?"
IP:"senti questo è il mio header vedi un po dove farmi uscire"
RT:"famme vedè..."
RT:"mmmm capito, tiè esci di la"
IP:"tenk iu very macc"
RT:"prego, vai piano che è un attimo a fare un collisione" (è vero ci sono anche le collisioni mauauaua e dipendono anche dalla velocita muauauu)
IP:"popopopopopopo a ecco un altro RT"
RT2:"che palle oggi tutti sti pacchetti...avanti un altro"
IP:"hey RT2 senti un po ciapa qua il mio header, mi manda, come puoi vedere dal MAC, RT"
RT2:"ah RT come sta? è da un pezzo che non ci scambiamo le tabelle di routing...sto bastardo...mah lo avranno messo in passive, boh...vabbe fammè vedè...ah sei arrivato man!Esci di lì e mostra allo switch il mac"
IP:"grassie"
SW:"bonjour"
IP:"bonjour?"
SW:"si so francese!"
IP:"vabbuo, ah ma non è che mi tiri un colpo di header vero?(asdasdasdasd), RT2 mi ha detto di mostrarti il mio MAC..."
SW:"da qua!"
IP:"ciapa"
SW:"va ben, devi consegnare lì (indicando un uscita), pussa via, ou revoire"
IP:"grassie...cmq siamo campioni del mondo, asdasdasd
"
Conlusioni
Il router non "si prende cura di niente" lui ha solamente i cartelli (rotte) per dire ad un pacchetto dove andare se la l'amico (host) non si trova nella propria citta (lan).
Nel caso ci siano 2 o piu router esiste un protocollo di livello tre gestito dai comandi icmp (ora non mi ricordo il codice esatto del codice icmp) che è ingrado di comunicare all'host che richiede di uscire verso l'esterno utilizzando un router che non ha le rotte per quella determinata destinazione. L'icmp è in grado di indicare al client di dirigere i pacchetti verso un altro gateway (router) che ha le indicazioni necessarie.
Spero di essere stato chiaro.
Il routing è difficile e non intendo, a meno di richieste, trattarlo perche poco pratico e molto molto teorico inoltre bisogna partire da un po prima...cioe dal subnetting...
DHCP
Il protocollo dhcp permette di assegnare dinamicamente agli hosts che sono configurati per farlo (di default se non avete toccato niente è cosi), indirizzi ip presi da uno scope dhcp (range ip).
Quando utilizzarlo?
Il dhcp è buona norma utilizzarlo quando NON ci sono regole di forwarding attive. Questo perche le regole di forwarding si basano su ip fissi. Se per caso quella mattina il dhcp si sveglia e decide di cambiare ip al vostro un pc in lan (perche in fondo il dhcp è bastardo!) e avete regole di portforwarding attive, ebbene quelle regole non varranno piu una cippa perche si riferiscono ad ip fissi e non tengono conto delle variazione del dhcp. Quindi se usate portforwarding usate ip fissi.
Sistemi ibridi
Qui il problema sta nel fatto che se io ho una rete in dhcp (tutta) e imposto alcuni client con ip fisso, il dhcp se ne sbatte e c'è la possibilità che vada ad assegnare ad un altro client in dhcp lo stesso indirizzo, con conseguente conflitto.
Il buon
gionnico mi segnala che esiste su alcuni Netgear la possibilità di implementare sistemi leggermente diversi da quelli standard. Non era mia intenzione parlarne (sincermante quello che ha segnalato non lo conoscevo neanche io
) ma visto che è saltato fuori, faccio una veloce carrellata di come creare, a seconda delle esigenze, un sistema dhcp ibrido.
Perchè crearlo? Perche ad esempio se volete che alcuni pc in rete abbiano ip fissi mentre altri ricevano gli indirizzi automaticamente. Questi tipi di strutture sono di solito usate nelle grandi lan dove a livello core layer (diciamo sala macchine, sala server...) di solito i server sono con ip fisso mentre tutto il resto della lan è in dhcp.
Ci sono 3 sistemi (2 quelli standard + 1 quello menzionato sopra che non consocevo):
- si imposta un range di indirizzi di assegnazione piu ristretto pur mantenendosi nella stessa subnet. Questo ti permette di sapere che certi indirizzi non verrano mai assegnati automaticamente. Questi indirizzi saranno i nostri ip fissi per i nostri server, o client che dir si voglia.
- oppure se i lavori sono stati fatti da
come spesso capita con i nostri super cazzuttissimi consulenti strafighi supercertificati che costano 1000eur/giorno, avremo spazi di indirizzamento già occupati e non contigui per cui non sara possibile impostare range di ip. In questo caso bisogna andare a manina e pescarsi ip liberi. Questi ip possono essere "esclusi" dall'autoassegnazione del dhcp, e quindi non verranno mai rilasciati.
- l'altro è diametralmente opposto (cioè il sistema che ha segnalato l'utente), ma di fatto ha lo stesso risultato. Vale a dire fa in modo che il dhcp leghi un ip in maniera fissa ad un MAC address, quindi ad una certa scheda di rete fornira sempre e solo lo stesso ip. Di per se il dhcp dovrebbe già farlo, ma nn sempre è cosi. E' un sistema che reputo interessante e molto adatto ad un utenza magari meno esperta. Qualcuno si è inventato questo sistema che viaggia parallelo al protocollo dhcp e ne influenzi le assegnazioni. Non tutti i router a quanto pare lo supportano
Server Pubblici
Ora che sappiamo tutti bene l'argomento e abbiamo studiato a casa
, parliamo di come rendere pubblico un bel serverino interno alla nostra lan dietro al nostro bel routerino nattato.
Dobbiamo per questo fare un set di regole di portforward in base alle nostre esigenze, e quindi andremo ad inserire a mano delle entry nella nat table.
Dunque: per evitare di scrivere da browser sempre un ip pubblico, è bello registrarsi su dyndns.org o servizi simili dove, anche con ip dinamici pubblici (cioè la quasi totalità dei casi), scriverete sempre la stessa cosa anzichè cambiare ogni volta indirizzo ip. Dove sta la fregatura? perche non posso farmi i miliardi offrendo hosting sul mio atholn64 venice a 10Ghz? Perche non potrete usare le porte standard ma dovrete usarne delle altre...e perche?Perche altrimenti le richieste interne alla lan si sovrapporebbero alle richieste in entrata.
Tuttavia il discorso appena descritto è quello piu generale possibile. In realtà funziona anche con la porta 80 singola. Il problema è che sulla lan nessun altro pc oltre al server sara in grado di usufruire di internet, perche tutte le richieste sulla porta 80 finiranno sul server e non sul client che lo ha richiesto. Le regole di portforwarding hanno la priorità delle regole dinamiche create dal router. Stessa cosa vale per il resto dei servizi tipo ftp etc...
Quindi:
ippclan: 192.168.1.1
ipwanrt: 212.1.1.1
Regola da impostare (andate sulla falsa riga delle conf che trovate sul sito segnalato sopra):
source ip public : any (implicito nella maggior parte dei router, per cui questa voce non la troverete).
source ip port: 2000 (ad esempio, cmq sopra la 1024)
dest ip port: 2000 (ad esempio, ma deve essere configurata nel webserver).
dest ip address: 192.168.1.1
per collegarsi (supponendo di aver registrato un dns pippo):
http://dyndns.pippo.org:2000
e se voglio aggiungere altri servizi e magari su un altro pc in lan? Cambiate solo la porta...
source ip public : any (implicito nella maggior parte dei router, per cui questa voce non la troverete).
source ip port: 2001 (ad esempio, cmq sopra la 1024)
dest ip port: 2001 (ad esempio, ma deve essere configurata nel webserver).
dest ip address: 192.168.1.2
ftp 212.1.1.1:2001
a presto!
