[Tech] SNATsemistatico

[Leonardo Boselli]

On 19 Mar 2003, at 14:57, Morpheus wrote:
> 
> > Ok, allora dovrebbe funzionare cosi': si divide il problema in due
> > (connessioni da dentro verso fuori e da fuori verso dentro)
> > iptables -t nat -A  PREROUTING  -d a.b.c.236 -j DNAT --to 10.10.5.7
> > (non ho mai verificato pero' come si comporta senza specificare le
> > porte ma secondo la documentazione dovrebbe andare bene)

e questo funziona perfettamente (da fuori verso dentro)

> > e per fare la stessa cosa da dentro verso fuori
> > iptables -t nat -A POSTROUTING -o indirizzo_interno -j SNAT --to
> > a.b.c.236
e questo NON mi funziona !
se dall'interno faccio un treceroute mi risponde
kyoto:/home/leo# traceroute a.b.c.3
traceroute: Warning: findsaddr: error sending netlink message: 
Connection refused
traceroute: Warning: ip checksums disabled
traceroute to extern (a.b.c.3), 30 hops max, 38 byte packets
 1  gateway (192.168.1.14)  0.745 ms  0.687 ms  0.669 ms
 2  * * *
(la defaulty route è su gateway) 

> confermo su base pratica che funziona perfettamente in questo modo anche se 
> modificherei le regole con un --to-destination e --to-source rispettivamente 
> (non so se l'istanza --to venga settata automaticamente in base alla catena 
> invocata dalla tabella nat... dovrebbe, ma non ho riscontri pratici in 
> merito).
in uscita non funziona ne con --to ne con --to-source !!!!!!!!

> Unica eccezione potrebbe essere legata alla connessione del gw su qualche 
> server interno alla lan che costringerebbe a chiamare in causa anche la 
> catena OUTPUT della tabella nat, ma, da quanto leggo, non mi sembra sia il 
> tuo caso.
se devono collagarsi a un server INTERNO usano gli indirizzi privati

> Altra questione è l'attivazione delle macchine autorizzate ad uscire... mi sa 
> che la via più semplice sia un'assegnazione statica degli ip sulla lan per 
> evitare di dover procedere manualmente volta per volta. L'alternativa di uno 
> script che riconfiguri caso per caso la tabella nat in base all'ip assegnato 
> agli host autorizzati ad uscire, mi pare un tantino complicata visto che non 
> è possibile operare un filtraggio a livello di mac address sulla tabella nat 
> e che eventuali marcature (tabella mangle di iptables) non "sopravvivono" al 
> di fuori dell'host che le ha generate (per chiarimenti ulteriori vedi il 
> LARTC HOW-TO su http://www.lartc.org). Esistono due alternative a 
> quest'ultimo problema: la prima potrebbe essere una marcatura degli ip-header 
> modificando il TOS dei pacchetti che partono dagli host autorizzati ad uscire 
> su internet, ma rischi di incorrere in spiacevoli "effetti collaterali". La 
> seconda, più semplice e più fattibile, consiste nel reinstradare (a livello 
> di host autorizzati ad uscire) i datagrammi estranei alla lan su una piccola 
> sottorete "virtuale" dedicata alle macchine che possono uscire su internet
> usando iptables con regole simili a quelle riportate sopra.

La cosa è molto più semplice: siccome l'accesso esterno è dato a 
livello di utente e non di macvchina, chi è su una macchina interne 
e deve uscire si collega al gateway e da li lancia lo script che 
collega o scollega..

--
Leonardo Boselli
Nucleo informatico e Telematico 
Dipartimento Ingegneria Civile
Universita` di Firenze
Via Santa Marta 3
I-50139 Firenze
+39 055-4796-431
+39 348-8605-348
fax 055-495-333