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.
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! ).
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!

[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

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?
_________________
"Dream on
Do you believe...all the things that you are seeing are true?
The Start's where the End's leading you
Do you believe...all's as twisted as one would perceive?
Seek the Answer and soon you'll believe"

[Sym]

Up!
_________________
"Dream on
Do you believe...all the things that you are seeing are true?
The Start's where the End's leading you
Do you believe...all's as twisted as one would perceive?
Seek the Answer and soon you'll believe"

[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.
_________________
Enjoy your freedom.
Sex is like hacking. You get in, you get out, and you hope you didnt leave something behind that can be traced back to you.
<----------------------->
Andrea Cerrito

[cerri]

[Ginko]

[Ginko]

[BlueRaven]

[cerri]

[BlueRaven]

[cerri]