Siccome mi e' stato richiesto, posto un piccolo articolo sul funzionamento del NAT e della sua implementazione in linux come MASQUERADE. Introduciamo innanzitutto dei termini che ricorreranno nell'articolo: Per IP address _Privato_ si intende un indirizzo appartenente ad uno dei gruppi di indirizzi designati ad essere usati nelle LAN basate su IP e non interconnesse con Internet (in maniera diretta, perlomeno). Tali indirizzi sono stati scelti da IANA (Internet Assigned Numbers Authority) e sono i seguenti: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 Tutti questi indirizzi non vengono assegnati a nessuna macchina connessa ad Internet. Innanzitutto diciamo che NAT sta per Network Address Translation. E' chiamato cosi' perche' il suo compito fondamentale e' tradurre indirizzi IP privati in indirizzi IP pubblici, e viceversa. Originariamente il NAT fu sviluppato per permettere l'accesso alla rete da parte di piu' client di quanti IP address si possedessero. L'idea e' simile ai centralini dei grandi uffici o enti, in cui le linee per connettersi con l'esterno sono molte meno del numero effettivo degli utenti (che d'altro canto si suppone non passino tutta la giornata al telefono). In questo scenario ogni volta che una macchina vuole connettersi all'esterno della Intranet, gli viene "prestato" un IP pubblico dal router NAT. Questo IP viene liberato in genere dopo un certo timeout di inutilizzo, fino allo scadere del quale la macchina che lo possiede ne ha un uso esclusivo. Il sistema tuttavia puo' essere applicato anche se si possiede UN SOLO IP address pubblico. Cio' e' possibile mascherando oltre che gli indirizzi IP, anche le porte TCP/UDP. Per spiegare come questo sia possibile bisogna esporre come funziona il NAT. Un router NAT fa qualcosa di piu' di un normale router. Quando riceve dalla LAN un pacchetto IP destinato ad una macchina esterna alla LAN: - memorizza [IP:porta] sorgente e destinazione in una tabella. Chiamiamo Entry1 la prima coppia ed Entry2 la seconda. - cambia l'IP e la porta del sorgente con un IP pubblico ed una porta disponibile, presa da un opportuno pool (in genere da 50000 in su). - infine come un normale router instrada il pacchetto opportunamente all'esterno della LAN (verso Internet). Quando il router NAT riceve un pacchetto proveniente dall'esterno della LAN (da Internet): - cerca nella tabella sopra citata nel campo Entry2 se esiste una voce corrispondente all'[IP:porta] SORGENTE del pacchetto ricevuto (in tal caso la sorgente e' ovviamente l'host remoto). - Se esiste, il router sostituisce l'indirizzo di destinazione del pacchetto con il campo Entry1. Altrimenti il pacchetto viene trattato in maniera diversa (gettato, respinto o altro) adesso cerchero' di viasualizzare il meccanismo attraverso un esempio e dei disegni: In tale esempio il client Worley (192.168.1.10) invia un pacchetto al server web www.tiscalinet.it (porta di destinazione 80) e riceve una risposta. Lo schema che segue rivolge l'attenzione ad i soli pacchetti: Pacchetto in uscita: SORG: 192.168.1.10:2250 NAT SORG: 151.12.10.187:61251 DEST: 195.130.224.57:80 -------> DEST: 195.130.224.57:80 Pacchetto in ingresso: SORG: 195.130.224.57:80 NAT SORG: 195.130.224.57:80 DEST: 192.168.1.10:2250 <------- DEST: 151.12.10.187:61251 Questo invece rappresenta lo schema completo: Vediamo cosa succede quando il client Worley invia una richiesra al server Web www.tiscalinet.it. (i disegni sono sviluppati in verticale perche' quasi tutti i client di posta fanno il word wrap. E' probabile che con il vostro client non vengano rispettati spazi e tabulazioni. Per vedere meglio i disegni potere copiarli ed incollarli in un editor di testi che abbia dimensione del carattere fissa, come Textpad) ------------------------- client (Worley) IP privato: 192.168.1.10 ------------------------- | | | | ------------------------ |-> Pacchetto Originale SORG: 192.168.1.10:2250 DEST: 195.130.224.57:80 ------------------------ | | | | --------------------------- | IP privato: 192.168.1.1 <-----| Router NAT IP pubblico: 151.12.10.187 --------------------------- | | | | | -------------------------- |--> Pacchetto Modificato SORG: 151.12.10.187:61251 DEST: 195.130.224.57:80 -------------------------- | | | | --------------------------- | Server Web <-----| IP pubblico: 195.130.224.57 --------------------------- Vediamo cosa succede quando lo stesso server web invia una risposta relativa alla precedente richiesta del client Worley. --------------------------- Server Web IP pubblico: 195.130.224.57 --------------------------- | | | | -------------------------- |-> Pacchetto Originale SORG: 195.130.224.57:80 DEST: 151.12.10.187:61251 -------------------------- | | | | --------------------------- | IP pubblico: 151.12.10.187 <-----| Router NAT IP privato: 192.168.1.1 --------------------------- | | | | | -------------------------- |--> Pacchetto Modificato SORG: 195.130.224.57:80 DEST: 192.168.1.10:2250 -------------------------- | | | | --------------------------- | Client Worley <-----| IP privato: 192.168.1.10 --------------------------- Tornando al discorso precedente, basta osservare che una comunicazione TCP o UDP e' univocamente individuata dalla coppia [IP:porta] di sorgente e destinazione per convincersi che in realta' per un numero limitato di macchine (fino a un centinaio) un singolo IP è sufficiente. Infatti il numero di porte a disposizione del router NAT e' enorme rispetto al numero di pacchetti che esso potrebbe processare (volendo usare le sole porte da 50000 in su: sono piu' di 15000 porte utilizzabili per instaurare altrettante comunicazioni... per una rete di 20 macchine cio' vul dire 750 comunicazioni a macchina) Se poi il router NAT fa solo quello, allora le porte possono diventare anche 60000. Ed ora passiamo al MASQUERATING ed alle piu' comuni forme di router NAT che si trovano in commercio ultimamente. Il NAT puro e semplice ha due problemi: - il protocollo di comunicazione usato dalle applicazioni deve basarsi solo ed esclusivamente sullo header TCP/UDP e IP per desumere INDIRIZZI e PORTE. Tali informazioni non devono risiedere nell'area dati del pacchetto. - Non e' possibile usare programmi di tipo server, cioe' che attendono su una certa porta una connessione di un client. Mentre il secondo problema e' risolvibile molto seplicemente con una soluzione unica, il primo va risolto protocollo per protocollo. Prendiamo come esempio tipico FTP, un protocollo storico che da moltissimi problemi li' dove ci sono router NAT e firewall mal configurati (o troppo restrittivi). In alcuni casi nell'FTP vengono scambiati (nell'area dati del pacchetto TCP) informazioni su porta ed indirizzo da usare per le comunicazioni dati. La situazione tipica e' quella in cui un client inva un comando PORT specificando il proprio indirizzo IP privato (es: 192.168.1.10) ed una porta sulla quale si mette in attesa della connessione dati. I problemi citati in precendenza si verificano entrambi: - il server FTP tentera' di rispondere ad un indirizzo privato (senza riuscirci mai, ovviamente) che ha ricavato dal comando PORT ricevuto. - il client si mette in attesa di una connessione (in tal caso si comporta come un server) sulla porta specificata nel comando PORT. Tuttavia il router NAT e' del tutto all'oscuro di questa situazione. NOTA: a tutti gli effetti il "client" FTP si comporta sia come client che come server. FTP fu pensato non solo per permettere il semplice scambio di files tra un client e un server, ma per ben altri piu' complessi usi che, per quanto ne sappia, non sono mai avvenuti. Il risultato e' che uno dei protocolli piu' diffusi non funziona a dovere con il NAT. La soluzione adottata dal MASQUERADE di linux per risolvere il primo problema e' un tipo di moduli del kernel che hanno il compito di individuare un determinato protocollo e di correggere opportunamente i dai in esso contenuti e di informare il modulo principale di MASQ della situazione. In particolare, il modulo che si occupa di far funzionare FTP intercetta i comandi PORT (anche i PASV) e ne modifica i parametri come conviene (non fatemi spiegare pure FTP, adesso.. :). Altri protocolli che non sono "NAT fiendly" sono ICQ, programmi di conferencing, QUAKE... Alcuni necessitano di un modulo apposito. Altri, piu' "NAT fiendly", si accontentano di un Port Forwarding. Il Port Forwarding e' la soluzione al secondo problema del NAT. Esso permette di inpartire ordini speciali al modulo MASQ del kernel, che stabiliscono in maniera statica come trattare le comunicazioni in ingresso destineate a determinate porte. E' ad esempio possibile stabilire che tutte le connessioni destinate alla porta 80 siano forwardate all'IP 192.168.1.25, che e' il nostro server Web sulla LAN. C'e' da notare una cosa; il problema dei servizzi in ingresso viene in realta' spacciato come cosa buona e voluta da molti vendor di software router NAT. Come dire "A feature is a bug with seniority". Infatti tale caratteristica fa si che il router funga anche da semplice firewall, in quanto rende invisibile la rete dietro il router: le comunicazioni possono essere iniziate solamente dall' interno (solo in tal caso viene creata una entry nella tabella del NAT che permette di individuare i pacchetti di risposta) ed i servizzi disponibili all'esterno possono essere cotrollati attraverso il port forwarding. Per il momento l'articolo finisce qui. Se qualcuno ha bisogno di chiarimenti, chieda pure. Il mio indirizzo e' paipai_rimuovi_questo@tiscali.it Ciauz! midorichan (paipai@paipai.net) //////////////////////////////////// ... A feature is a bug with seniority.