Prof. Giuseppe F. Rossi E-mail: giuseppe.rossi@unipv.it UNIVERSITA' DEGLI STUDI DI BERGAMO A.A. 2013/14 - II Semestre FONDAMENTI DI RETI E TELECOMUNICAZIONE Lucidi delle Lezioni - Capitolo XIII Architettura TCP/IPv4: nodi di interconnessione Capitolo XIII 1/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Struttura del capitolo I nodi router IP I nodi proxy TCP/IP I nodi NAT Il concetto di protocol tunneling Capitolo XIII 2/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Siano date due reti (con topologia semplice o complessa) funzionanti attraverso i protocolli dell'architettura TCP/IP: si vogliono esplorare le possibilità di interconnessione Soluzioni classiche Nodo router IP Nodo proxy TCP/IP Soluzioni particolari Nodo di interconnessione Capitolo XIII 3/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Nodo router IP Commutazione delle PDU-IP a livello 3 La rete complessiva formata dall'unione delle 2 reti date utilizza un unico spazio di indirizzamento IP Soluzione classica nel modello di rete TCP/IP Appl Appl TCP/UDP IP DLC Physical Client Intranet Router IP (forwarding) DLC DLC Physical Physical Internet TCP/UDP IP DLC Physical Server Rete IP Capitolo XIII 4/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Nodo proxy TCP/IP Interconnessione a livello applicativo (quindi selettivo per applicazione) Ammette solo sessioni unidirezionali, cioè il messaggio di inizio della comunicazione può fluire in un sol senso (vi sono anche dispositivi reverse proxy che permettono sessioni bidirezionali) A livello IP le due reti non sono connesse, ma devono comunque utilizzare 2 spazi di indirizzamento disgiunti in quanto, in caso contrario, nascerebbe un'ambiguità Proxy Appl TCP IP DLC Physical Client Intranet Appl. Proxy TCP / UDP IP (NO forwarding!!) DLC DLC Physical Physical Direzione della sessione Internet Appl TCP IP DLC Physical Server Rete IP Rete IP Capitolo XIII 5/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
NAT = Network Address Translation Operazione attraverso la quale uno spazio di indirizzamento di livello 3 di una rete viene rimappato su un secondo spazio di indirizzamento mantenendo una connettività trasparente tra nodo host mittente e host destinatario Nel corso del tempo l'operazione di NAT ha subito una serie di evoluzioni che ha dato origine a diverse tipologie di dispositivi (quindi sarebbe meglio parlare di "famiglia di dispositivi NAT"), i quali, in alcuni casi, prevedono anche una rimappatura dei numeri di port dei protocolli di trasporto I dispositivi NAT sono router IP (cioè dispositivi di commutazione di livello 3), ai quali è stata aggiunta la funzione di rimappatura degli spazi di indirizzamento IP Capitolo XIII 6/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Livelli architetturali e numerazione delle reti nelle interconnessioni via NAT (IP) Rete a numerazione pubblica Appl TCP/UDP IP DLC Physical Client Rete a numerazione privata Intranet Router NAT IP (funz. NAT) DLC DLC Physical Physical Internet Appl TCP/UDP IP DLC Physical Server Rete IP Capitolo XIII 7/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Le numerazioni IP private (RFC 1918) 10.0.0.0-10.255.255.255 (Prefisso 10.0.0.0/8) 172.16.0.0-172.31.255.255 (Prefisso 172.16.0.0/12) 192.168.0.0-192.168.255.255 (Prefisso 192.168.0.0/16) Capitolo XIII 8/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Classificazione dei dispositivi NAT Traditional NAT o Outbound NAT Basic NAT Network Address Port Translation (NAPT) Bi-directional NAT o Two-Way NAT Twice NAT Capitolo XIII 9/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Esempio di interconnessione di due reti IPv4 attraverso un dispositivo NAT (Basic NAT): il concetto generale sarà spiegato nelle prossime slide Rete A Src = 10.31.44.7 Dst = 145.23.4.7 Router NAT Src = 198.76.29.2 Dst = 145.23.4.7 Rete B Spazio assegnato da Rete B a Rete A Prefix = 198.76.29.0/24 10.31.44.7 198.76.29.2............ Tabella di mappatura degli spazi di indirizzamento Capitolo XIII 10/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Osservazioni (valide per tutti i tipi di NAT) Associazione (binding) degli spazi di indirizzamento 2 modalità Statica Semplice, ma poco efficiente Dinamica Molto efficiente, ma complessa (... vedasi prossima slide) Ogni indirizzo presente nelle PDU-IP deve essere traslato coerentemente con lo spazio di indirizzamento nel quale entra il pacchetto, affinché routing e forwarding avvengano correttamente Capitolo XIII 11/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Associazione dinamica degli spazi di indirizzamento Quando inizia una sessione comunicativa (NAT "vede" il primo pacchetto) un indirizzo di uno spazio di indirizzamento viene associato 'al volo' ad un indirizzo libero di un altro spazio di indirizzamento Quando le sessioni comunicative di un nodo interno non utilizzano più l'indirizzo esterno associato (e quindi quando il NAT vede transitare l'ultimo pacchetto dell'ultima sessione attiva), allora esso dovrebbe essere rilasciato e reso disponibile ad altri Occorre definire cosa é una sessione comunicativa per poter riconoscere quando essa termina: dipende dal protocollo cui ci si riferisce TCP e UDP (ricordare che UDP é connectionless e non ha alcun stato associato): la quaterna (Src_IP_Addr, Src_Port_Nr, Dest_IP_Addr, Dest_Port_Nr) ICMP: dipende dallo specifico messaggio (e non sempre esiste il concetto di sessione) IP: non esiste il concetto di sessione comunicativa Capitolo XIII 12/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Riconoscimento da parte del NAT della terminazione della sessione comunicativa: questa operazione, non facile, è fondamentale per poter liberare l'indirizzo Protocollo TCP Nei Code_Bits FIN=1 per entrambe le half-connection Ma se la PDU-ACK relativa al 2 FIN=1 poi non arriva a destinazione...? NAT crede che la connection sia terminata ma la cosa non é così Così come una entità comunicante TCP nella procedura di active close permane nello stato TIME_WAIT per 2MSL secondi, per lo stesso motivo il NAT deve tenere allocato l'indirizzo almeno per 2MSL Altro problema: cosa succede, per esempio, se un end-point effettua reboot? NAT crede la connection funzionante ma invece é terminata E' necessario deallocare gli indirizzi se per un po' di tempo non passa traffico (quanto tempo?) Nota (ulteriore complicazione): il non passaggio di PDU-TCP non significa con certezza che la connection sia stata abbattuta Protocolli non-tcp: spesso non è possibile riconoscere il fine sessione Capitolo XIII 13/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Talune applicazioni TCP/IP trasportano nei loro messaggi indirizzi IP e numeri di port TCP e/o UDP (tale caratteristica determina nell'architettura TCP/IP una interdipendenza tra i livelli 3, 4 e applicativo) Nel caso avvenga un rimappaggio degli spazi di indirizzamento nelle PDU dei protocolli di livello 3 e 4 risulta necessario anche correggere i messaggi applicativi facenti riferimento a tali indirizzi ALG (Application Level Gateway) Funzionalità aggiuntive separate dal NAT che 'collaborano' con quest'ultimo Sono necessari in presenza di applicazioni che funzionano nella modalità illustrata sopra: per ogni applicazione è quindi necessario realizzare il relativo ALG Capitolo XIII 14/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Schema di riferimento per lo studio dei diversi tipi di NAT Internal Address Realm (IAR) Pri_N NAT Pub_N External Address Realm (EAR) Pri_A Pub_X Host A Host X Capitolo XIII 15/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Traditional NAT (o Outbound NAT) Permettono solo sessioni unidirezionali (= il messaggio di inizio sessione può fluire in un sol senso) da IAR a EAR: Host_A può iniziare una sessione con Host_X ma non viceversa Gli indirizzi di EAR sono univoci e validi sia in EAR che in IAR Le info di routing possono essere propagate da EAR in IAR ma non viceversa (es. uscirebbero su Internet dei prefissi riferiti ad uno spazio di indirizzamento privato) Gli indirizzamenti usati su IAR e EAR devono essere disgiunti (in caso contrario non si potrebbero propagare le info di routing da EAR in IAR) 2 principali sottotipi Basic NAT Network Address Port Translation (NAPT) Capitolo XIII 16/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Basic NAT: associa tra loro 2 indirizzi IP (IP_Addr_Pri) => (IP_Addr_Pub) Un indirizzo IP di un sottoinsieme di EAR è corrispondente di uno e un solo indirizzo IP di un sottoinsieme di IAR Spazio IPv4 di IAR Spazio IPv4 di EAR Capitolo XIII 17/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Network Address Port Translator (NAPT): associa tra loro 2 coppie (IP_Addr, Port_Nr) (IP_Addr_Pri, Port_Nr_X) => (IP_Addr_Pub, Port_Nr_Y) Una coppia ordinata (IP_Addr, Port_Nr) di sottoinsieme di EAR è corrispondente di una e una sola coppia ordinata (IP_Addr, Port_Nr) di un sottoinsieme di IAR, quindi un indirizzo IP di un sottoinsieme di EAR è corrispondente di almeno un indirizzo IP di un sottoinsieme di IAR Spazio IPv4 di IAR Spazio IPv4 di EAR Capitolo XIII 18/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Bi-directional NAT (o Two-way NAT) Le comunicazioni possono essere iniziate sia da host di IAR che da host di EAR Un IP_Addr_Pri viene associato ad un IP_Addr_Pub staticamente o dinamicamente In IAR+EAR ogni nodo referenzia un qualunque altro nodo attraverso un sistema di naming univoco (utilizzando il servizio DNS) Quindi un host di EAR referenzia un host di IAR attraverso un nome simbolico DNS a prescindere dalla associazione IP_Addr_Pri - IP_Addr_Pub fatta dal NAT Questo tipo di NAT richiede la presenza di una funzionalità ALG-DNS che gestisce la sostituzione degli indirizzi nelle Query/Response DNS sulla base delle associazioni (IP_Addr_Pri) => (IP_Addr_Pub) fatte dal NAT Capitolo XIII 19/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Bi-directional NAT (o Two-way NAT) (cont.) Esempio: l'host "giovanni.azienda4.com" (IP_Addr = 195.223.26.4) deve spedire un pacchetto IP a "sonia.azienda7.it" (inizialmente IP_Addr =?) EAR assegna ad IAR lo spazio pubblico 199.76.29.0 "giovanni.azienda4.com" di EAR chiede al proprio DNS di risolvere "sonia.azienda7.it" (di cui non conosce l'ip_addr poiché potrebbe essere stato mappato dinamicamente) Gli indirizzi IP dei DNS in IAR devono essere mappati staticamente su indirizzi di EAR Query: IP_Addr di "sonia.azienda7.it"? DNS di "azienda4.com" EAR giovanni.azienda4.com (195.223.26.4) Resp: 199.76.29.2 ALG DNS Two-way NAT 10.75.44.6 199.76.29.2............ Resp: 10.75.44.6 IAR sonia.azienda7.it (10.75.44.6) DNS di "azienda7.it" Capitolo XIII 20/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Twice NAT Nei Traditional NAT e nei Bi-directional NAT il transito di un datagram comporta la sostituzione di 1 solo indirizzo IP I Twice NAT il transito di un datagram comporta la sostituzione di entrambi gli indirizzi IP Sono necessari quando IAR e EAR utilizzano spazi di indirizzamento IP sovrapponentesi Supponiamo che su una Intranet si usino indirizzi privati che in realtà sono indirizzi pubblici di Internet (da non fare!) Esempio numerico Su una Intranet si usa lo spazio di indirizzamento 200.200.200.0 usato all'esterno da Internet per un'altra rete Se l'host interno Host_A (200.200.200.1) vuole raggiungere l'host esterno Host_X (200.200.200.100) come fa...? C'é un'ambiguità (sovrapp. degli spazi di indirizzamento) Capitolo XIII 21/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Twice NAT (cont.) Gli host di EAR vedono il resto della rete (EAR+IAR) secondo l'indirizzamento pubblico Gli host esterni di EAR con gli indirizzi uguali agli indirizzi interni sono visti da IAR come aventi indirizzi privati (es. 10.x.x.x,... ) Indirizzi Pubblici EAR Indirizzi esterni sovrapposti IAR (ind. sovrapposti) Indirizzi Privati Capitolo XIII 22/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Twice NAT (cont.) Esempio numerico: una Intranet viene numerata con i seguenti indirizzamenti Indirizzi privati utilizzati all'interno: 200.200.200.0/24 Indirizzi pubblici con i quali sono noti i nodi della Intranet su Internet: 138.76.28.0/24 Indirizzi privati con i quali i nodi della Intranet referenziano i nodi di Internet aventi indirizzi pubblici 200.200.200.0/24: 172.16.1.0/24 Datagram da host (interno) Host_A a host (esterno) Host_X Percorso sulla Intranet verso il NAT: Src_Addr=200.200.200.1 e Dest_Addr=172.16.1.100 Dopo il transito dal NAT: Src_Addr=138.76.28.1 e Dest_Addr=200.200.200.100 Datagram da host (esterno) Host_X a host (interno) Host_A Percorso su Internet verso il NAT: Src_Addr=200.200.200.100 e Dest_Addr=138.76.28.1 Dopo il transito dal NAT: Src_Addr=172.16.1.100 e Dest_Addr=200.200.200.1 Capitolo XIII 23/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Considerazioni sui nodi NAT Il cambio di un indirizzo nei messaggi dei protocolli dell'architettura TCP/IP é un'operazione tutt'altro che indolore a causa della imperfezione dell'architettura (livelli interdipendenti) La sostituzione di un indirizzo IP in un datagram impone queste operazioni Il ricalcolo del campo HEADER_CHECKSUM nella testata IPv4 La sostituzione degli indirizzi negli eventuali messaggi ICMP con ricalcolo del CHECKSUM Il ricalcolo dei campi CHECKSUM di TCP e UDP con le nuove pseudo-header Se le applicazioni si scambiano indirizzi IP e/o numeri di port allora è necessaria anche la presenza di uno specifico ALG Capitolo XIII 24/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Esempio di un caso critico: l'applicazione FTP (File Transfer Protocol) FTP trasporta indirizzi IP e numeri di port all'interno di alcuni messaggi applicativi Sulla control-connection di FTP (active mode) viene scambiato il comando PORT Esempio: PORT n1,n2,n3,n4,n5,n6 dove (n1,..., n6 sono codificati in ASCII) (n1.n2.n3.n4) = IP_Addr del Client (n5x256+n6) = Port_Nr del TCP sul Client per la data-connection Se un NAT esegue dei mappaggi su IP_Addr e/o Port_Nr é necessario modificare il contenuto di PORT: l'applicazione FTP può continuare a funzionare a condizione che sul NAT sia presente l'alg per FTP Problema (risolubile... ma in totale contrasto con qualunque principio architetturale) PORT può cambiare di dimensione => può cambiare la dimensione del payload di alcuni segment di TCP della control connection => disallineamento sui Seq_Nr e Ack_Nr ALG deve costruire una tabella di traslazione dei valori di Seq_Nr/Ack_Nr del TCP da applicare a tutto il successivo traffico della control-connection dell'ftp Capitolo XIII 25/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Il concetto di protocol tunneling Schematizzazione del funzionamento del protocol tunneling: il trasporto punto-a-punto di un pacchetto Px avviene sfruttando i servizi di rete forniti da Py Px Py...... Py Px DLC Physical DLC Physical Px-PDU Px-PDU Tunnel Px-PDU PY Px-PDU Px-PDU Capitolo XIII 26/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014
Il concetto di protocol tunneling Una PDU di un protocollo Px, viene trasportata dall'entità originante all'entità destinatario attraverso una rete comunque complessa, sfruttando il seguente principio Incapsulamento di PDU-Px in un protocollo Py. Di norma Px e Py presentano almeno una delle seguenti caratteristiche: Appartengono ad architetture di comunicazione diverse Il livello architetturale di Px é uguale o inferiore al livello di Py Px 'osserva' un servizion di trasferimento, creato da Py, che collega le due macchine della rete end-point del tunnel La rete intermedia gestisce Py, mentre Px viene visto come una normale sequenza di dati da trasportare da un capo all'altro del tunnel Capitolo XIII 27/27 Copyright Ing. Giuseppe F. Rossi, 1995-2014