# Accesso ai demoni dietro un NAT su IP pubblico? Nooo! :-)

## BlueRaven

Posto questa spiegazione sperando di fare cosa gradita a tutti voi, oltre che ad Akiross che me l'ha chiesta.  :Smile: 

Cercherò di essere breve, anche perché il TCP/IP non è certo argomento che si possa esaurire in un post, per cui perdonatemi le approssimazioni.

Per prima cosa, qualche base elementare sul protocollo, per chi ne fosse digiuno: ogni pacchetto che viaggia sulla Rete ha un indirizzo IP sorgente e un indirizzo di destinazione, che servono ad identificare i due estremi della comunicazione.

In particolare, nel caso del protocollo TCP, si parla di connessione, in quanto le due macchine aprono un vero e proprio canale di comunicazione, che viene mantenuto fino a quando la stessa non è completa.

Questo, ad esempio, non si verifica con il protocollo UDP.

Particolare importanza ha la fase di instaurazione della comunicazione: questa avviene con un particolare processo, detto di handshaking, in cui i due host si scambiano una terna di pacchetti.

Esistono delle particolari categorie di indirizzi IP, le cosiddette classi private ( definite nella RFC 1918), che vengono usate normalmente per configurare il TCP/IP in una LAN.

Caratteristica principale di queste classi IP è di essere non routabili, ovvero un pacchetto che abbia come indirizzo sorgente uno di quelli appartenenti a queste classi non viene inoltrato su Internet (misconfigurazioni a parte).

Ora, il NAT risolve appunto questo problema: permettere a macchine che abbiano un IP privato di accedere ai servizi su Internet.

Questo si ottiene interponendo tra la LAN e la rete un dispositivo, detto gateway, che ha due (o più, ma facciamola semplice) IP: uno privato su un'interfaccia collegata alla LAN, l'altro pubblico con interfaccia verso Internet.

Questo gateway non fa altro che sostituire l'IP sorgente del pacchetto uscente col proprio e sostituire, poi, l'IP di destinazione della risposta con quello della macchina che ha fatto la richiesta.

Le macchine della LAN sono istruite a mandare al gateway i pacchetti ogni volta che non è possibile raggiungere direttamente la destinazione, ovvero quando non c'è nessun'altra interfaccia che è collegata alla rete della macchina di destinazione.

Ipotizziamo di avere questa situazione: abbiamo la macchina A, con indirizzo IP privato 192.168.0.1, che è il nostro client.

Sulla stessa rete, abbiamo la macchina B, con indirizzo IP privato 192.168.0.100 e su cui gira un server FTP sulla porta 21.

Abbiamo, infine, la macchina C che fa da gateway e che ha IP 192.168.0.254 sull'interfaccia verso la LAN e 80.105.27.241 verso Internet.

Prendiamo il caso di una normale comunicazione: A vuole comunicare con un server FTP, chiamato D, che sta, diciamo, su 193.206.212.84.

A non ha un'interfaccia verso questa rete per cui spedisce il pacchetto a C.

C si vede arrivare un pacchetto con indirizzo sorgente 192.168.0.1 e destinazione 193.206.212.84.

C sostituisce l'indirizzo sorgente col suo e spedisce il pacchetto a D, che pertanto si vedrà arrivare un pacchetto con IP sorgente 80.105.27.241 e destinazione il suo IP.

Quando D risponde, risponde direttamente a C: per cui il pacchetto avrà IP sorgente 193.206.212.84 e destinazione 80.105.27.241. C, a questo punto, sa che la richiesta originale era stata fatta da A e sostituisce l'IP di destinazione con quello di A. A, quindi, vede arrivare un pacchetto con IP sorgente 193.206.212.84 e destinazione 192.168.0.1, che è il suo.

E fin qui nessun problema (spero!   :Wink:  ).

Ora, poniamo che io voglia che il server FTP che gira su B sia visibile su Internet: siccome l'IP è privato, dovrò dire al mio gateway che tutti i pacchetti in arrivo con destinazione l'IP di C 80.105.27.241 e porta di destinazione 21 vengano rimandati verso B.

Che succede se la richiesta in questione viene fatta da A?

Se uso l'IP privato, nessun problema, la comunicazione avviene esattamente come prima.

Se uso l'IP pubblico, invece, succede questo: A invia a C il pacchetto con IP sorgente 192.168.0.1 e IP destinazione 80.105.27.241 e porta di destinazione 21.

A questo punto C sa che deve cambiare l'indirizzo di destinazione e rimandare il pacchetto a B, per cui B si vede arrivare un pacchetto con IP sorgente 192.168.0.1 e IP destinazione 192.168.0.100.

E qui sta il problema: quando B risponde, per prima cosa, controlla se per caso A è sulla sua stessa rete. Ricordate? Se due host sono sulla stessa rete, del gateway non c'è bisogno.

Quindi, stavolta, B risponde direttamente ad A: A si vede arrivare un pacchetto con IP sorgente 192.168.0.100 e porta sorgente 21 e destinazione il suo IP.

Però A si ricorda che la richiesta in questione lui l'aveva fatta al gateway, su 80.105.27.241 e NON a B direttamente.

In questi casi, il protocollo TCP prevede che l'host che riceve un pacchetto inaspettato segnali la cosa all'altra macchina, chiudendo la connessione.

Questo viene fatto con un pacchetto cosiddetto di reset (RST): B lo riceve e a sua volta chiude la connessione.

Per cui A resta in attesa di una risposta dal gateway che, ovviamente, non arriverà mai.

Ed ecco spiegato perché non si può usare un servizio che si basa su TCP dietro un NAT provenendo dalla stessa rete del server.

Come ricordava Igaryu, ovviamente, nessun problema se si arriva dall'esterno: in questo caso, c'è sempre di mezzo il gateway, che traduce gli indirizzi e rende possibile la comunicazione.

That's all, folks!  :Very Happy: 

----------

## Sym

Già che siamo in tema...ho un problema col dnat. Vi spiego la situazione. 

ho una macchina che fa da firewall per una rete interna:

2 indirizzi pubblici mettiamo 1.2.3.4 e 1.2.3.5 bindati sulla eth1 

1 indirizzo privato interno mettiamo 10.0.0.50 su eth0

Ora, faccio snat per tutta la rete interna 10.0.0.0/24 e funziona benissimo; per mascherare la rete uso l'ìndirizzo 1.2.3.4. Sulla stessa macchina vi è un webserver: se arrivano pacchetti per la porta 80 sull'indirizzo 1.2.3.5 vengono processati dal firewall, mentre se arrivano pacchetti per la porta 443 sull'indirizzo 1.2.3.5 devo venire reindirizzati su una macchina della rete interna, mettiamo la 10.0.0.20. Il dnat non riesco ad implementarlo   :Sad: 

iptables -t nat -A PREROUTING -p tcp -d 1.2.3.5 --dport 443 -i eth1 -j DNAT --to  10.0.0.20:443

Ovviamente nella catena che gestisce i pacchetti in forward da fuori a dentro ho aggiungo una regola che lasci passare i pacchetti --syn destinati alla 10.0.0.20. Dove sta il problema secondo voi?

----------

## Sym

Up!   :Confused: 

----------

## cerri

Per risolvere questi problemi devi:

1) abilitare il log dei pacchetti droppati;

2) se il punto 1 non basta, abilitare il log dei pacchetti ammessi.

In questo modo capisci quello che succede.  :Very Happy: 

----------

## cerri

 *BlueRaven wrote:*   

> Caratteristica principale di queste classi IP è di essere non routabili,

 

Questo non e' assolutamente vero. La differenza di routable / not routable si fa a livello di di protocollo.

 *BlueRaven wrote:*   

> ovvero un pacchetto che abbia come indirizzo sorgente uno di quelli appartenenti a queste classi non viene inoltrato su Internet (misconfigurazioni a parte).

 

Appunto. Per il resto e' ok  :Wink: 

----------

## Ginko

 *BlueRaven wrote:*   

> Se uso l'IP pubblico, invece, succede questo: A invia a C il pacchetto con IP sorgente 192.168.0.1 e IP destinazione 80.105.27.241 e porta di destinazione 21.
> 
> A questo punto C sa che deve cambiare l'indirizzo di destinazione e rimandare il pacchetto a B, per cui B si vede arrivare un pacchetto con IP sorgente 192.168.0.1 e IP destinazione 192.168.0.100.

 

Il problema non c'e' se l'indirizzo di A viene mascherato in uscita verso internet. B si vedrebbe arrivare una connessione da un indirizzo esterno e la cosa funzionerebbe senza problemi.

Saluti

--Gianluca

----------

## Ginko

 *BlueRaven wrote:*   

> ovvero un pacchetto che abbia come indirizzo sorgente uno di quelli appartenenti a queste classi non viene inoltrato su Internet (misconfigurazioni a parte).

 

Molto vero! Provate ad attaccare un router direttamente ad internet, attivate OSPF e pretendete di essere il gateway per la rete 10.0.0.0/8, lanciate ethereal e ne vedrete di tutti i colori...  :Smile: 

--Gianluca

----------

## BlueRaven

 *cerri wrote:*   

>  *BlueRaven wrote:*   Caratteristica principale di queste classi IP è di essere non routabili, 
> 
> Questo non e' assolutamente vero. La differenza di routable / not routable si fa a livello di di protocollo.

 

Giustissimo, scusate lo sfondone.   :Embarassed: 

----------

## cerri

 *BlueRaven wrote:*   

> Giustissimo, scusate lo sfondone.  

 

HAHAHAAHAHHAAHAHAHAHAHAHAH

Ho riso venti minuti quando ho letto "sfondone"!!!!!!!!!  :Very Happy:   :Very Happy:   :Very Happy: 

----------

## BlueRaven

 *cerri wrote:*   

> Ho riso venti minuti quando ho letto "sfondone"!!!!!!!!!   

 

Non l'avevi mai sentito?   :Cool: 

----------

## cerri

 *BlueRaven wrote:*   

> Non l'avevi mai sentito?  

 

Decisamente no... ma ora me lo ricordero'!!!   :Mr. Green: 

----------

