Newsgroup: it.comp.os.linux.sys
Titolo: cambio rete senza disservizio

Devo migrare la server farm e quindi dovrò cambiare gli IP di tutti i server:
Esiste la possibilità di mettere un unico pc che sia configurato con tutti 
gli ip della vecchia classe e li rigiri a quella nuova?
dovrebbe in sostanza fare un dnat in base all'ip chiamato (es da x.x.x.4 a 
y.y.y.4, x.x.x.5 a y.y.y.5 ecc ecc)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
- Signor Andreotti, come fa ad avere la coscienza sempre pulita?
- Basta non usarla mai.
		-- Chiappori

 a y.y.y.4, x.x.x.5 a y.y.y.5 ecc ecc)
Questo non lo fa anche iptables ?
O cercavi qualcosa di meno laborioso, perche' imho userei un router vero 
e proprio (anche un vecchio cisco 1630 o similare con 2 eth)

Rizio ha scritto:

Il problema è che le 2 reti sono "distanti", ovvero devo spostare un po' di 
server internet da una web farm ad un' altra e volevo limitare il 
disservizio dovuto alla propagazione dei dns
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Che se io saprei che mio figlio mi diventerebbe un orecchione,
vivo glielo faccio mangiare il ritratto di Dorian Gray!
		-- Giorgio Faletti

 disservizio dovuto alla propagazione dei dns
si, lo mettevo come router interno, proprio per fare solo dnat tra due 
reti, non configurando tutti gli altri mestieri che puo' fare.

Rizio ha scritto:

ma il client che si connette a 10.0.0.4 non si arrabbia se la risposta 
arriva da 192.168.0.4? e poi il router da solo riesce a modificare l'ip di 
destinazione?
Se non ricordo male iptables (almeno quello vecchio) non prendeva in 
considerazione le varie eth:x
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
O quest'uomo e' morto, o il mio orologio si e' fermato!
		-- Groucho Marx

 considerazione le varie eth:x
Perche' ? Se lavori sugli IP (perche' li devi cambiare) le eth0 ci vanno 
dietro no ?!

 dietro no ?!
Se invece del cisco ci metto un linux con iptables dovrň dargli gli ip che 
deve vedere e non ricordo se gestiva gli alias
Comunque dovrebbe fungere con iptables, basta fare una regola per ogni ip 
(certo che se la facesse lui...), viene mascherato l'ip con quello del fw e 
viene reindirizzato al giusto server. Stesso percorso al ritorno
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
C'e' gente che nasce mediocre.  Dukakis ha dovuto studiare ad Harvard
per diventarlo.
		-- Pat Buchanan

 del fw e viene reindirizzato al giusto server. Stesso percorso al ritorno
io avevo queste regole in iptables per effettuare il nat _da_ e _verso_ 
il mailserver in dmz:
$IPTABLE -t nat -A PREROUTING -d $MAILEXT -p tcp -m multiport --dports 
25,110 -j DNAT --to $MAILINT
$IPTABLE -t nat -A POSTROUTING -o eth3 -s $MAILINT -j SNAT --to $MAILEXT

 disservizio dovuto alla propagazione dei dns
problema facilmente risolvibile.
metti il TTL a 120 (ad esempio) in tutte le zone qualche giorno prima e sei
sufficientemente sicuro di migrare tutto.
Per la posta, invece, ad esempio, puoi configurare postfix con delle
transport maps per spostare ciò che arriva sui nuovi servers e perdition
per proxare imap e pop sui nuovi server in maniera trasparente.
Fatto decine di volte e a parte qualche Rarissimo caso di proxy M$ che
perpetrava a cacharsi gli ip vecchi (parlo dei siti) tutto è sempre andato
per il meglio.
Se ti serve una mano fammi un fischio, tanto siamo pure vicini !
Max
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 
Oddio, non ci avevo pensato :-(
Se metto il ttl a 120 secondi non ci dovrebbero essere problemi neanche con 
la posta (tanto il dns primario lo migro prima su un nuovo server), al 
limite dovrei reindirizzare (o lasciare in piedi giusto per qualche giorno) 
il solo secondario.
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Volare e' utile, atterrare e' necessario.
		-- Eros Drusiani

 giorno) il solo secondario.
Boh io non farei molto affidamento sui TTL: ne ho spostati di domini con 
TTL a 10 minuti, ma alcuni dns server ci mettono comunque giorni a 
cancellare la cache. Aiuta, per caritą, ma non aspettarti che ti risolva 
il problema.

 il problema.
un pņ di considerazioni:
1) se i DNS malfunzionanti danno problemi, non sono problemi miei... esiste 
il TTL per essere usato
2) quello che di solito fa casino sono i proxy http che si 
memorizzano il valore ben oltre il tempo di cache. ovviamente sono
programmati male.
3) proprio per eliminare eventuali problemi sui TTL (ma chi se ne frega) 
avevo consigilato le transport maps && perdition.
4) mettere un TTL molto basso č utilerrimo, ma ovviamente va fatto con un 
pņ di sale in zucca! Non č che passare da 86400 a 120 ti permette di girare 
Subito i DNS.


 
Mi sembra che tu te la sia presa per il mio intervento, ma guarda che 
non volevo essere provocatorio, e neppure ho detto che stai consigliando 
cose sbagliate.
1) In un mondo ideale ti darei ragione, ma visto che se faccio una 
modifica ai DNS e qualcosa non funziona per colpa di altri il cliente si 
incazza con me non posso dirgli "guarda che è colpa di quelli la che non 
gestiscono bene la cache" perchè tanto non serve a nulla.
2) Vedi punto 1), sbattersene di un problema perchè tanto non è generato 
da me non mi sembra bello;
3) Non sono entrato in merito e comunque ribadisco: non ho detto che 
usare i TTL è una stronzata, ho detto che aiuta ma non mette al riparo 
da qualunque problema;
4) Concordo con te, ma se anche abbasso i TTL 3 mesi prima cè sempre 
qualche server per il mondo che in un modo o nell'altro non si aggiorna 
per tempo;

 per tempo;
certo.
Quindi devi mantenere 2 pool di IP in 2 farm per 3 mesi ?
una volta l'ho fatto.
Pagava il cliente !
Fosse per me, quelli sono soldi bucati.
Per mia esperienza, comunque, dopo 3 giorni sull'SMTP arriva solo spam.


 I  miei clienti di solito capiscono 
Beato te...a me scassano la m....a anche quando non riescono a navigare 
e nota che non offriamo connettività:
Cliente: "Non riusciamo a scaricare la posta"
Io: "Riuscite a navigare?"
Cliente: "No, non ci va nulla"
Io: "Dovreste provare a sentire chi vi gestisce la rete o il vostro 
provider per la connettività"
Cliente: "Ma lei non può fare niente?"
Io: "No, se il problema è nella vostra rete o causato dalla vostra 
connessione dati no..."
Cliente: "E ma io non riesco nemmeno a scaricare la posta che è li da voi!"

 il mailserver in dmz:
A me cosi' funziona (vd. sotto)...
Avevo provato (velocemente) perche' devo fare una cosa del genere a 
breve... quindi se vedete errori /dite[mc]elo/ :-) , grazie.
======================
# server esterno
EXT_REDIR_IP="x.x.x.x"
# questo server ip/eth
INT_IP="x.x.x.x"
INT_ETH="eth1"
# porte/servizi da redirigere al server esterno
# (deve essere caricato ipt_multiport)
REDIR_DPORTS="25,110,143,993,995"
iptables -A FORWARD -m multiport -p tcp -d $EXT_REDIR_IP --dports 
$REDIR_DPORTS -j ACCEPT
iptables -t nat -A PREROUTING -d $INT_IP -m multiport -p tcp --dports 
$REDIR_DPORTS -j DNAT --to-destination $EXT_REDIR_IP
iptables -t nat -A POSTROUTING -m multiport -p tcp --dports 
$REDIR_DPORTS -o $INT_ETH -d $EXT_REDIR_IP -j SNAT --to-source $INT_IP
# se necessario. (per vedere le porte remote anche localmente)
iptables -t nat -A OUTPUT -d $INT_IP -m multiport -p tcp --dports 
$REDIR_DPORTS -j DNAT --to-destination $EXT_REDIR_IP
========================
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

bla ha scritto:

Non è che lavori accanto a me e non lo sapevo????
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Che ci crediate o no, la morte e' ancora il peggior flagello degli Stati
Uniti.
		-- Henry Gibson