Newsgroup: it.comp.os.linux.sys
Titolo: proxy_arp e nat statico

Ciao a tutti
una curiosità:
per eseguire il nat statico da un IP pubblico ad un IP in DMZ devo aver 
attivato il proxy_arp sulle eth vero ?
echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
perchè senno chi mi risolve la chiamata arp per l'ip su cui devo fare il 
redirect ? No ?
Grazie
-- 
Rizio

 redirect ? No ?
puoi aggiungere l'alias dell'ip pubblico alla interfaccia esterna del
firewall, che è meno intrusiva, come soluzione...
Hola...
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Skull says:
The old signature is gone...
Won't you suggest me a new one?!?

 Hola...
Tnk's
-- 
Rizio

 piuttosto che mettere un alias sull'eth ?
Non è questione di pericolosità, se le cose son fatte con la testa non
cambia nulla:
ifconfig eth0:webserver 10.1.1.4
o, meglio ancora:
ip addr add 10.1.1.1 dev eth0
iptables -A PREROUTING -t nat -d 10.1.1.1 -i eth0 -j DNAT
--to-destination 192.168.0.4
iptables -A POSTROUTING -t nat -s 192.168.0.4 -o eth0 -j SNAT
--to-source 10.1.1.1
dopodichè apri quello che serve in forward.
Il che implica che qualsiasi cosa viaggi su ip (quindi >= layer 3) viene
rigirata all'interno, e all'ip alias non risponde *mai* il firewall
stesso.
In questi termini l'ip-alias serve solamente per le arp-reply, nulla andrà
mai a cozzare su quell'ip...
Il motivo è solo che potresti *non* volere il proxy arp, che tende a
routare un po' tutto.
Questione di gusti, cmq...


 Questione di gusti, cmq...
Si, in effetti mentre facevo le prove ho già incasinato un paio di volte 
l'arp table di un pc, ma pensavo fosse uno scotto da pagare.
Grazie mille per ora, caso mai intanto faccio così poi vedo di capire 
confrontare i pro e i contro.
Ad majora Skull
-- 
Rizio

 confrontare i pro e i contro.
Forse è meglio concentrarsi su cosa ti serve realmente e realizzarlo 
nella fomra più minimale possibile.
Dico questo perchè traslare tutto è quasi sempre inutile e queste cose, 
  in termini di sicurezza, possono costare care.

   in termini di sicurezza, possono costare care.
'nn te seguo... :-)
-- 
Emanuele Balla  aka Skull
+----------------------------------------------------------------------+
Actually without signature.
Any idea?!?

   in termini di sicurezza, possono costare care.
Brematurato alla supercazzola o scherziamo? E' un po' come se fosse
antani anche per loro che sono in due :-)))))
Un Banana che tapioca a scarpallacia

 'nn te seguo... :-)
E' molto semplice, es: se devo nattare il webserver 192.168.0.4 su 
10.1.1.1 č utile forwardare solo le porte tcp 80 e 443 (le udp 
corrispondenti credo che siano completamente inutili) e nulla di piů.
Quindi
iptables -A PREROUTING -t nat -p tcp -d 10.1.1.1 --dport 80 \
-j DNAT --to 
192.168.0.4:80
e
iptables -A PREROUTING -t nat -p tcp -d 10.1.1.1 --dport 443 \
-j DNAT --to 
192.168.0.4:443

 -j DNAT --to 
192.168.0.4:443
Personalmente anch'io "dnatto" solo il necessario, ma se si ha la forward
chiusa, il problema da te sollevato non si pone, o perlomeno non si pone
in questi termini. Tutto cio' ovviamente fintanto che le regole in
forward consentano il transito solo di determinate porte, anche se in
prerouting si e' "dnattato" tutto il traffico possibile e
immaginabile.     :-)
bye G.L.
--
« E' assolutamente evidente che l'arte del cinema
 si ispira alla vita, mentre la vita si ispira alla TV »
(Woody Allen)

    :-)
Aggiungo: eviti di impazzire a gestirti a mano anche il nat di tutti gli
icmp che possano uscire dalla macchina nattata in risposta a pacchetti che
finiscono su un servizio momentaneamente non disponibile (altrimenti lo
state RELATED lo usi solo per ftp!?!?), per non parlare di eventuali
problemi di mtudp, o di nat su applicazioni multiporta prive di supporto
come modulo ip_XXX_nat.
Se ci son costretto (ovvero voglio che allo stesso ip rispondano due
macchine diverse su porte diverse) natto le singole porte, sennň natto
tutto e poi chiudo in forward.
Giusto per dire che la motivazione di nattare tutto non č casuale o dovuta
a pigrizia, ma a precise ragioni implementative.
Peraltro sotto openbsd esiste l'apposita regola di binat, non penso sia
lě perchč insucura ;-)
Che poi si possa fare in altri X modi č vero, ma, IMHO, piů dispendioso in
termini di setup e problem solving quando poi le cose iniziano a
comportarsi in modo strano...
Hola...
