[Tech] SNATsemistatico

Morpheus morpheus@mydotcomaddress.com
Mer 19 Mar 2003 14:57:14 CET


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alle 09:59, mercoledì 19 marzo 2003, Nicola Mersi (Uff. CED) ha spippolato:

[snip]

> LB> ci credo, ma la domanda era un'altra: io ho fatto quello come
> LB> esempio per dire che il NAT deve essere completo e bidirezionale.
> LB> ossia che la chiamata potrebbe venire non soo dalla 3306 ma
> LB> anche dalla 19856 19 22 3456 56001 e così via ... e lo stesso la
> LB> macchina all'interno potrebbe volere accedere a QAULUNQUE
> LB> macchina allésterno su QUALUNQUE porta e dovrebbe aspparire
> LB> all'esterno con l'indirizzo che gli ho assegnato.
> LB> Ossia: al'interno ho diverse centinaia di macchine, con indirizzi
> LB> abbastanza causali, solo 15 di queste possono uscire [ma non è
> LB> detto che becchino sempre lo stesso indirizzo al'interno] e quindi
> LB> volta per volta debbo "abilitarle".Queste, a tutti gli effetti,
> all'esterno LB> debbnono essere viste con uno dei 15 indirizzi "aggiuntivi"
> e
> LB> cisacuno di questi, in ogni momento,  deve corrispondere a una e
> LB> una sola.

> 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 per fare la stessa cosa da dentro verso fuori
>
> iptables -t nat -A POSTROUTING -o indirizzo_interno -j SNAT --to
> a.b.c.236

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).
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.
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.
Spero di averti dato qualche idea e di non avertele confuse più di prima... se 
fosse così dimmelo che proverò a spiegarmi un po' meglio.

> Per il ppp non ti posso aiutare mi spiace, non so se si possono
> attivare indirizzi virtuali su ppp (point-to-point-protocol).

Qua credo di non aver capito bene... non puoi attivare tu indirizzi virtuali 
su ppp, è il provider che assegna gli indirizzi su questa interfaccia.

Saluti
Paolo
- -- 
***********************************
  Powered by Red Hat Linux 8.0

   Linux Registered User 223916
 Linux Registered Machine 106779
***********************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+eHdDE8+EZeDD8mQRAvYFAKCNnlSA6xRs85add0EXXtGJ/7BqEgCfZX7P
PS/QuaMLLfb8m5s6JiTIGVM=
=RIYY
-----END PGP SIGNATURE-----




Maggiori informazioni sulla lista flug-tech