Newsgroup: it.comp.os.linux.sys
Titolo: Transparent proxy via iptables

Ciao a tutti,
devo migrare un server web su una nuova macchina, con IP diverso, e su 
una farm diversa.
Ho pensato a una cosa: dopo aver copiato tutti i siti e i relativi 
database e aver configurato apache coi relativi VirtualHost sulla nuova 
macchina, per accelerare l'entrata in funzione, visto che non ho il 
diretto controllo di tutti i DNS, di fare cosi` sulla vecchia maccina:
iptables -t nat -A POSTROUTING -p tcp --dport 80 -j DNAT nuovoip:80
A parte l'aumento di traffico (temporaneo) sulla vecchia macchina, vedete 
controindicazioni?
Non ci sono siti in https o altre cose strane, solo normali siti (con 
rewrite e cgi, ma non penso creino problemi)
Grazie.
Bye.

Alessandro Pellizzari wrote:

E usare apache con proxypass? Mi sembra piu' configurabile e gestibile.
-- 
Nobusama 

 rewrite e cgi, ma non penso creino problemi)
Non stai prima a usare mod_proxy puro e semplice?
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

 Non stai prima a usare mod_proxy puro e semplice?
Non l'ho mai usato. Dovrei studiarmelo e fare esperimenti prima di 
metterlo in produzione.
Se mi dici che e` banale configurarlo mi ci metto subito (appena ho 
finito la configurazione del nuovo server). :)
Pero` il problema dei log che solleva Davide potrebbe essere importante. 
Apache logga l'ip del client o quello del vecchio server, quando arrivano 
le connessioni?
Non sarebbe una cosa del tutto bloccante, perche` comunque hanno tutti 
analytics, e per una settimana di log sballati forse si puo` anche 
sopportare, ma devo valutare la cosa.
Grazie a tutti per l'aiuto. :)
Bye.

 
Mi sa che logga l'ip del vecchio server.
In alternativa potresti configurare sul vecchio server un software di 
balancing tipo crossroads o ha-proxy e indicare come unico backend il server 
nuovo. Questo dovrebbe mantenerti gli ip di provenienza nei log. L'ho 
provato per test prima di una migrazione e sembrava funzionare ma poi non ho 
avuto occasione di usarlo in produzione.
-- 
Nobusama

 le connessioni?
Il vecchio server loggherà l'IP "vero", il nuovo loggherà l'Ip del vecchio.
Ma volendo, nella definizione dei vhost sul server nuovo...
LogFormat "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\""
combined
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %s %b \"%{Referer}i\"
\"%{User-agent}i\"" combined_forwarded
SetEnvIfNoCase X-Forwarded-For "." from_proxy=1
CustomLog /path_to/access_log combined env=!from_proxy
CustomLog /path_to/access_log combined_forwarded env=from_proxy
...dovrebbe funzionare...


controindicazioni?
Se la macchina vecchia fa da router per la nuova, no. Gli indirizzi IP
visti dalla macchina nuova sono quelli originali.
Ma, proprio per questo, la macchina nuova rispondera' a loro, e quindi
i client (vedendo una risposta provenire dall'IP sbagliato) invieranno
un RST e butteranno giu' la connessione.
Senza impegno e ricordando che non tocca a me farlo <grin>:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT
	--to nuovoip[:80]
iptables -t nat -A POSTROUTING -p tcp --dst nuovoip --dport 80 -j SNAT
	--to mioip[:80]
iptables -t nat -A OUTPUT --dst mioip -p tcp --dport 80 -j DNAT
	--to nuovoip[:80]
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

Ma, proprio per questo, la macchina nuova rispondera' a loro...
Boja, stavolta ho fatto davvero cappotto :-)
1. Quanto sopra è spiegato da canidi. Il mio secondo paragrafo era da
   intendersi "Se INVECE, come è quasi certo, la macchina vecchia NON
   fa da router...". L'ha detto molto meglio il maieutico Skull.
2. Il quale ha anche fatto un'osservazione assai giusta, ovvero: cosa
   ti garantisce che la rete di ${VECCHIOPROVIDER} instradi bene quel
   rimbalzino?
3. In tutti i casi, stai messo assai meglio a usare mod_proxy.
4. Vado a scrivere mille volte "PRIMA fare il sync del NG, POI andare
   a rispondere"


 iptables -t nat -A POSTROUTING -p tcp --dport 80 -j DNAT nuovoip:80
Niet.
Innanzitutto, il DNAT va nella catena di PREROUTING; come seconda cosa, non
potrebbe comunque funzionare e ti spiego perché.
Pacchetto originario: A.B.C.D SYN -> X.Y.W.Z:80
X.Y.W.Z, a fronte di una regola
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to E.F.G.H
inoltrerebbe un pacchetto TCP siffatto:
A.B.C.D SYN -> E.F.G.H:80
e il nuovo web server risponderebbe quindi con un
E.F.G.H SYN ACK -> A.B.C.D
Poiché A.B.C.D non ha mai mandato alcun SYN a E.F.G.H, quel che accadrebbe è che
A.B.C.D risponderebbe con un bel reset.
Se proprio vuoi quindi procedere in questa maniera, devi anche prevedere un source nat, perdendo
però la possibilità di loggare, a livello di apache, la sorgente effettiva del traffico web.
Una roba tipo
iptables -t nat -A POSTROUTING -d E.F.G.H -p tcp --dport 80 -j SNAT --to X.Y.W.Z
Se invece non vuoi perdere la possibilità di loggare a livello di apache la sorgente reale
delle sessioni, dovresti ricorrere a qualcosa di decisamente più complesso, ovvero
policy routing sul nuovo web server (marcare i pacchetti in output che abbiano porta
sorgente 80 con iptables, scrivere una ip rule che forzi i pacchetti con quel fwmark a
utilizzare una specifica tabella di routing e definire quindi questa nuova tabella di routing
con default gateway il vecchio web server, ammesso che i due host siano sulla stessa subnet, altrimenti
ti tocca, come ulteriore complicazione, creare una qualche forma di tunnel tra i due host)

 occasione di usarlo in produzione.
Grazie a tutti per l'aiuto.
Rispondo a Nobusama perche` ho seguito il suo consiglio e ho messo 
haproxy. La config Debian e` gia` praticamente pronta, basta commentare 
le parti inutili e cambiare la porta di quella utile.
E tanti auguri a tutti. :)
Bye.