Help : chgt d'IP publique et serveur de messagerie -
5 réponses
Jazzoroastre
Bonjour, j'ai essayé de formuler mon pb du mieux que j'ai pu :
Je dois changer d'accès internet et donc d'IP publique.
J'ai actuellement deux connections internet ADSL et SDSL avec deux IP fixes
disons IP1 et IP2 et donc deux modems-routeurs MR1 et MR2.
J'ai ensuite un réseau local LAN2 (192.168.2.X) avec deux firewall Redhat
FW1 et FW2 routant le traffic vers MR1 et MR2 (respectivement).
MR1 et MR2 ont donc tous les deux une adresse sur le LAN2 (peu importe
laquelle)
FW1 possède 2 cartes reseau :
eth0 : avec lP1 comme IP publique sur le net.
eth1 : avec 192.168.2.3 locale sur LAN2
FW2 possède 2 cartes reseau :
eth0 : avec lP2 comme IP publique sur le net.
eth1 : avec 192.168.2.4 locale sur LAN2
Il y a ensuite un serveur de messagerie POP1 (entre autres serveurs
internet) sur ce LAN2 qui a pour adresse IP 192.168.2.8
Ce serveur de messagerie a actuellement pour passerelle FW1 (donc l'IP de la
gateway est 192.168.2.3, patte interne de FW1).
actuellement FW1 re-route (iptables) tout le fluw smtp et pop sur
192.168.2.8 et tout se passe très bien jusqu'à présent.
j'ai également configuré FW2 pour qu'il reroute tout le traffic smtp et pop
sur 192.168.2.8
Le hic, c'est qu'on change d'adresse IP publique pour notre nom de domaine
(on passe de IP1 à IP2 pour "mondomaine.com" par ex).
En effet , je vais donc demander à mon registrar d'effectuer le changement
d'association "mondomaine.com <-> IP1" en "mondomaine.com <-> IP2". Et avec
le temps de replication dans les differents DNS, il faut compter 48h avant
que ça soit ok.
Durant cette transition, je risque de perdre des mails. Je souhaite donc que
les deux passerelles restent actives durant ce temps. En gros que l'on
attaque le serveur pop de l'exterieur sur IP1 ou sur IP2, que l'on puisse
recuperer les mails dans les deux cas. Que l'on tombe bien sur la bone
machine et qu'elle puisse nous répondre quoi...
J'ai donc effectué le même reroutage (du traffic pop et smtp ) de FW2 sur
POP1. J'ai testé en donnant comme passerelle 192.168.2.4 à POP1. ça marche.
J'ai fait la même chose avec un serveur ftp FTP1 sur le même reseau LAN2. ça
marche si je donne comme gateway l'adresse de FW2 sur le LAN (192.168.2.4)
Par contre si je conserve l'ancienne IP1 (192.168.2.3) et les anciens DNS
(car ils different ) ça ne marche pas.
En gros si ça rentre par un des deux accès internet, il faut que ça ressorte
par le même.
C'est comme s'il fallait définir deux passerelles et dire que le traffic qui
vient de l'une doit repartir par la même.
Mon problème : comment faire comprendre ça à POP1 ?
Dans le message <news:431f1332$0$27405$, *Jazzoroastre* tapota sur f.c.r.ip :
En gros si ça rentre par un des deux accès internet, il faut que ça ressorte par le même.
C'est comme s'il fallait définir deux passerelles et dire que le traffic qui vient de l'une doit repartir par la même.
Mon problème : comment faire comprendre ça à POP1 ?
En faisant du source routing ?
Mon petit grain de sel. :-)
Pour les distraits, attention à ne pas confondre le "source routing", routage imposé par l'émetteur d'un paquet, prévu dans le protocole IP mais non utilisé à ma connaissance, avec une politique de routage (routing policy) par l'adresse source, dont il est question ici.
J'apporte quelques précisions qui peuvent être utiles à Jazzoroastre :
Comme tu as deux routeurs distincts, une politique de routage ne peut se faire que sur le serveur. Pour pouvoir utiliser l'adresse source comme critère pour router les paquets sortants vers l'un ou l'autre routeur, le serveur doit avoir deux adresses distinctes, chacune utilisée comme adresse de redirection par un routeur.
Autrement, il y a un moyen simple, rapide et sale (quick and dirty) de faire repartir les paquets de réponse par le bon routeur sans politique de routage, mais tu n'en voudras sûrement pas à cause de son "léger" défaut. Il suffit de faire du NAT source (SNAT) avec iptables sur les flux entrants redirigés par les deux routeurs. Ainsi l'adresse de destination d'un paquet de réponse émis par le serveur sera directement l'adresse du routeur à utiliser. Il y a cependant un inconvénient majeur évident : le serveur ne voit pas l'adresse source réelle des connexions qu'il reçoit.
Pour finir, il y a peut-être moyen d'éviter tout ça en jouant sur le TTL au niveau DNS. En le réduisant suffisamment à l'avance avant de faire la transition de l'adresse IP, les caches expireront rapidement (la "réplication" est instantanée, c'est l'expiration qui prend du temps). Et pendant ce temps, le(s) MX secondaire(s) garderont les mails en attente.
Salut,
Dans le message <news:431f1332$0$27405$8fcfb975@news.wanadoo.fr>,
*Jazzoroastre* tapota sur f.c.r.ip :
En gros si ça rentre par un des deux accès internet, il faut que ça
ressorte par le même.
C'est comme s'il fallait définir deux passerelles et dire que le traffic
qui vient de l'une doit repartir par la même.
Mon problème : comment faire comprendre ça à POP1 ?
En faisant du source routing ?
Mon petit grain de sel. :-)
Pour les distraits, attention à ne pas confondre le "source routing",
routage imposé par l'émetteur d'un paquet, prévu dans le protocole IP
mais non utilisé à ma connaissance, avec une politique de routage
(routing policy) par l'adresse source, dont il est question ici.
J'apporte quelques précisions qui peuvent être utiles à Jazzoroastre :
Comme tu as deux routeurs distincts, une politique de routage ne peut se
faire que sur le serveur. Pour pouvoir utiliser l'adresse source comme
critère pour router les paquets sortants vers l'un ou l'autre routeur,
le serveur doit avoir deux adresses distinctes, chacune utilisée comme
adresse de redirection par un routeur.
Autrement, il y a un moyen simple, rapide et sale (quick and dirty) de
faire repartir les paquets de réponse par le bon routeur sans politique
de routage, mais tu n'en voudras sûrement pas à cause de son "léger"
défaut. Il suffit de faire du NAT source (SNAT) avec iptables sur les
flux entrants redirigés par les deux routeurs. Ainsi l'adresse de
destination d'un paquet de réponse émis par le serveur sera directement
l'adresse du routeur à utiliser. Il y a cependant un inconvénient majeur
évident : le serveur ne voit pas l'adresse source réelle des connexions
qu'il reçoit.
Pour finir, il y a peut-être moyen d'éviter tout ça en jouant sur le TTL
au niveau DNS. En le réduisant suffisamment à l'avance avant de faire la
transition de l'adresse IP, les caches expireront rapidement (la
"réplication" est instantanée, c'est l'expiration qui prend du temps).
Et pendant ce temps, le(s) MX secondaire(s) garderont les mails en attente.
Dans le message <news:431f1332$0$27405$, *Jazzoroastre* tapota sur f.c.r.ip :
En gros si ça rentre par un des deux accès internet, il faut que ça ressorte par le même.
C'est comme s'il fallait définir deux passerelles et dire que le traffic qui vient de l'une doit repartir par la même.
Mon problème : comment faire comprendre ça à POP1 ?
En faisant du source routing ?
Mon petit grain de sel. :-)
Pour les distraits, attention à ne pas confondre le "source routing", routage imposé par l'émetteur d'un paquet, prévu dans le protocole IP mais non utilisé à ma connaissance, avec une politique de routage (routing policy) par l'adresse source, dont il est question ici.
J'apporte quelques précisions qui peuvent être utiles à Jazzoroastre :
Comme tu as deux routeurs distincts, une politique de routage ne peut se faire que sur le serveur. Pour pouvoir utiliser l'adresse source comme critère pour router les paquets sortants vers l'un ou l'autre routeur, le serveur doit avoir deux adresses distinctes, chacune utilisée comme adresse de redirection par un routeur.
Autrement, il y a un moyen simple, rapide et sale (quick and dirty) de faire repartir les paquets de réponse par le bon routeur sans politique de routage, mais tu n'en voudras sûrement pas à cause de son "léger" défaut. Il suffit de faire du NAT source (SNAT) avec iptables sur les flux entrants redirigés par les deux routeurs. Ainsi l'adresse de destination d'un paquet de réponse émis par le serveur sera directement l'adresse du routeur à utiliser. Il y a cependant un inconvénient majeur évident : le serveur ne voit pas l'adresse source réelle des connexions qu'il reçoit.
Pour finir, il y a peut-être moyen d'éviter tout ça en jouant sur le TTL au niveau DNS. En le réduisant suffisamment à l'avance avant de faire la transition de l'adresse IP, les caches expireront rapidement (la "réplication" est instantanée, c'est l'expiration qui prend du temps). Et pendant ce temps, le(s) MX secondaire(s) garderont les mails en attente.
Jazzoroastre
Autrement, il y a un moyen simple, rapide et sale (quick and dirty) de faire repartir les paquets de réponse par le bon routeur sans politique de routage, mais tu n'en voudras sûrement pas à cause de son "léger" défaut. Il suffit de faire du NAT source (SNAT) avec iptables sur les flux entrants redirigés par les deux routeurs. Ainsi l'adresse de destination d'un paquet de réponse émis par le serveur sera directement l'adresse du routeur à utiliser. Il y a cependant un inconvénient majeur évident : le serveur ne voit pas l'adresse source réelle des connexions qu'il reçoit
Heu pourquoi pas puisque c'est temporaire. Si c'est sale mais temporaire ça peut aller... Je ne maîtrise pas rès bien les commandes iptables pour le masquerading. Il faudrait faire quoi comme commande sur le serveur mail ? Un truc comme ça ? iptables -t snat -A POSTROUTING -d 192.168.2.0/24 -o eth1 -j MASQUERADE
.
Pour finir, il y a peut-être moyen d'éviter tout ça en jouant sur le TTL au niveau DNS. En le réduisant suffisamment à l'avance avant de faire la transition de l'adresse IP, les caches expireront rapidement (la "réplication" est instantanée, c'est l'expiration qui prend du temps). Et pendant ce temps, le(s) MX secondaire(s) garderont les mails en attente. A ce moment là, il faut que je demande ça au registrar c'est bien ça ?
Merci en tout cas de vos conseils avisés
Autrement, il y a un moyen simple, rapide et sale (quick and dirty) de
faire repartir les paquets de réponse par le bon routeur sans politique de
routage, mais tu n'en voudras sûrement pas à cause de son "léger" défaut.
Il suffit de faire du NAT source (SNAT) avec iptables sur les flux
entrants redirigés par les deux routeurs. Ainsi l'adresse de destination
d'un paquet de réponse émis par le serveur sera directement l'adresse du
routeur à utiliser. Il y a cependant un inconvénient majeur évident : le
serveur ne voit pas l'adresse source réelle des connexions qu'il reçoit
Heu pourquoi pas puisque c'est temporaire. Si c'est sale mais temporaire ça
peut aller...
Je ne maîtrise pas rès bien les commandes iptables pour le masquerading.
Il faudrait faire quoi comme commande sur le serveur mail ?
Un truc comme ça ?
iptables -t snat -A POSTROUTING -d 192.168.2.0/24 -o eth1 -j MASQUERADE
.
Pour finir, il y a peut-être moyen d'éviter tout ça en jouant sur le TTL
au niveau DNS. En le réduisant suffisamment à l'avance avant de faire la
transition de l'adresse IP, les caches expireront rapidement (la
"réplication" est instantanée, c'est l'expiration qui prend du temps). Et
pendant ce temps, le(s) MX secondaire(s) garderont les mails en attente.
A ce moment là, il faut que je demande ça au registrar c'est bien ça ?
Autrement, il y a un moyen simple, rapide et sale (quick and dirty) de faire repartir les paquets de réponse par le bon routeur sans politique de routage, mais tu n'en voudras sûrement pas à cause de son "léger" défaut. Il suffit de faire du NAT source (SNAT) avec iptables sur les flux entrants redirigés par les deux routeurs. Ainsi l'adresse de destination d'un paquet de réponse émis par le serveur sera directement l'adresse du routeur à utiliser. Il y a cependant un inconvénient majeur évident : le serveur ne voit pas l'adresse source réelle des connexions qu'il reçoit
Heu pourquoi pas puisque c'est temporaire. Si c'est sale mais temporaire ça peut aller... Je ne maîtrise pas rès bien les commandes iptables pour le masquerading. Il faudrait faire quoi comme commande sur le serveur mail ? Un truc comme ça ? iptables -t snat -A POSTROUTING -d 192.168.2.0/24 -o eth1 -j MASQUERADE
.
Pour finir, il y a peut-être moyen d'éviter tout ça en jouant sur le TTL au niveau DNS. En le réduisant suffisamment à l'avance avant de faire la transition de l'adresse IP, les caches expireront rapidement (la "réplication" est instantanée, c'est l'expiration qui prend du temps). Et pendant ce temps, le(s) MX secondaire(s) garderont les mails en attente. A ce moment là, il faut que je demande ça au registrar c'est bien ça ?
Merci en tout cas de vos conseils avisés
Pascal
Autrement, il y a un moyen simple, rapide et sale (quick and dirty) de faire repartir les paquets de réponse par le bon routeur sans politique de routage, mais tu n'en voudras sûrement pas à cause de son "léger" défaut. Il suffit de faire du NAT source (SNAT) avec iptables sur les flux entrants redirigés par les deux routeurs. Ainsi l'adresse de destination d'un paquet de réponse émis par le serveur sera directement l'adresse du routeur à utiliser. Il y a cependant un inconvénient majeur évident : le serveur ne voit pas l'adresse source réelle des connexions qu'il reçoit
Heu pourquoi pas puisque c'est temporaire. Si c'est sale mais temporaire ça peut aller...
OK, c'est toi qui vois.
Je ne maîtrise pas rès bien les commandes iptables pour le masquerading. Il faudrait faire quoi comme commande sur le serveur mail ?
Il n'y a rien à faire du tout sur le serveur lui-même. Les règles iptables sont à mettre en place sur les deux routeurs FW1 et FW2.
Sur FW2, remplacer l'adresse SNAT par 192.168.2.4. Pour le protocole POP3, remplacer le port destination par 110.
Pour finir, il y a peut-être moyen d'éviter tout ça en jouant sur le TTL au niveau DNS. En le réduisant suffisamment à l'avance avant de faire la transition de l'adresse IP, les caches expireront rapidement (la "réplication" est instantanée, c'est l'expiration qui prend du temps). Et pendant ce temps, le(s) MX secondaire(s) garderont les mails en attente.
A ce moment là, il faut que je demande ça au registrar c'est bien ça ?
Plutôt au gestionnaire technique du domaine, celui qui gère la zone sur le serveur DNS maître. Ça peut être le registrar mais pas forcément.
Autrement, il y a un moyen simple, rapide et sale (quick and dirty) de
faire repartir les paquets de réponse par le bon routeur sans politique de
routage, mais tu n'en voudras sûrement pas à cause de son "léger" défaut.
Il suffit de faire du NAT source (SNAT) avec iptables sur les flux
entrants redirigés par les deux routeurs. Ainsi l'adresse de destination
d'un paquet de réponse émis par le serveur sera directement l'adresse du
routeur à utiliser. Il y a cependant un inconvénient majeur évident : le
serveur ne voit pas l'adresse source réelle des connexions qu'il reçoit
Heu pourquoi pas puisque c'est temporaire. Si c'est sale mais temporaire ça
peut aller...
OK, c'est toi qui vois.
Je ne maîtrise pas rès bien les commandes iptables pour le masquerading.
Il faudrait faire quoi comme commande sur le serveur mail ?
Il n'y a rien à faire du tout sur le serveur lui-même. Les règles
iptables sont à mettre en place sur les deux routeurs FW1 et FW2.
Sur FW2, remplacer l'adresse SNAT par 192.168.2.4.
Pour le protocole POP3, remplacer le port destination par 110.
Pour finir, il y a peut-être moyen d'éviter tout ça en jouant sur le TTL
au niveau DNS. En le réduisant suffisamment à l'avance avant de faire la
transition de l'adresse IP, les caches expireront rapidement (la
"réplication" est instantanée, c'est l'expiration qui prend du temps). Et
pendant ce temps, le(s) MX secondaire(s) garderont les mails en attente.
A ce moment là, il faut que je demande ça au registrar c'est bien ça ?
Plutôt au gestionnaire technique du domaine, celui qui gère la zone sur
le serveur DNS maître. Ça peut être le registrar mais pas forcément.
Autrement, il y a un moyen simple, rapide et sale (quick and dirty) de faire repartir les paquets de réponse par le bon routeur sans politique de routage, mais tu n'en voudras sûrement pas à cause de son "léger" défaut. Il suffit de faire du NAT source (SNAT) avec iptables sur les flux entrants redirigés par les deux routeurs. Ainsi l'adresse de destination d'un paquet de réponse émis par le serveur sera directement l'adresse du routeur à utiliser. Il y a cependant un inconvénient majeur évident : le serveur ne voit pas l'adresse source réelle des connexions qu'il reçoit
Heu pourquoi pas puisque c'est temporaire. Si c'est sale mais temporaire ça peut aller...
OK, c'est toi qui vois.
Je ne maîtrise pas rès bien les commandes iptables pour le masquerading. Il faudrait faire quoi comme commande sur le serveur mail ?
Il n'y a rien à faire du tout sur le serveur lui-même. Les règles iptables sont à mettre en place sur les deux routeurs FW1 et FW2.
Sur FW2, remplacer l'adresse SNAT par 192.168.2.4. Pour le protocole POP3, remplacer le port destination par 110.
Pour finir, il y a peut-être moyen d'éviter tout ça en jouant sur le TTL au niveau DNS. En le réduisant suffisamment à l'avance avant de faire la transition de l'adresse IP, les caches expireront rapidement (la "réplication" est instantanée, c'est l'expiration qui prend du temps). Et pendant ce temps, le(s) MX secondaire(s) garderont les mails en attente.
A ce moment là, il faut que je demande ça au registrar c'est bien ça ?
Plutôt au gestionnaire technique du domaine, celui qui gère la zone sur le serveur DNS maître. Ça peut être le registrar mais pas forcément.
Pascal
[Supersedes]
Autrement, il y a un moyen simple, rapide et sale (quick and dirty) de faire repartir les paquets de réponse par le bon routeur sans politique de routage, mais tu n'en voudras sûrement pas à cause de son "léger" défaut. Il suffit de faire du NAT source (SNAT) avec iptables sur les flux entrants redirigés par les deux routeurs. Ainsi l'adresse de destination d'un paquet de réponse émis par le serveur sera directement l'adresse du routeur à utiliser. Il y a cependant un inconvénient majeur évident : le serveur ne voit pas l'adresse source réelle des connexions qu'il reçoit
Heu pourquoi pas puisque c'est temporaire. Si c'est sale mais temporaire ça peut aller...
OK, c'est toi qui vois.
Je ne maîtrise pas rès bien les commandes iptables pour le masquerading. Il faudrait faire quoi comme commande sur le serveur mail ?
Il n'y a rien à faire du tout sur le serveur lui-même. Les règles iptables sont à mettre en place sur les deux routeurs FW1 et FW2.
Sur FW2, remplacer l'adresse SNAT par 192.168.2.4. Pour le protocole POP3, remplacer le port destination par 110.
Pour finir, il y a peut-être moyen d'éviter tout ça en jouant sur le TTL au niveau DNS. En le réduisant suffisamment à l'avance avant de faire la transition de l'adresse IP, les caches expireront rapidement (la "réplication" est instantanée, c'est l'expiration qui prend du temps). Et pendant ce temps, le(s) MX secondaire(s) garderont les mails en attente.
A ce moment là, il faut que je demande ça au registrar c'est bien ça ?
Plutôt au gestionnaire technique du domaine, celui qui gère la zone sur le serveur DNS maître. Ça peut être le registrar mais pas forcément.
[Supersedes]
Autrement, il y a un moyen simple, rapide et sale (quick and dirty) de
faire repartir les paquets de réponse par le bon routeur sans politique de
routage, mais tu n'en voudras sûrement pas à cause de son "léger" défaut.
Il suffit de faire du NAT source (SNAT) avec iptables sur les flux
entrants redirigés par les deux routeurs. Ainsi l'adresse de destination
d'un paquet de réponse émis par le serveur sera directement l'adresse du
routeur à utiliser. Il y a cependant un inconvénient majeur évident : le
serveur ne voit pas l'adresse source réelle des connexions qu'il reçoit
Heu pourquoi pas puisque c'est temporaire. Si c'est sale mais temporaire ça
peut aller...
OK, c'est toi qui vois.
Je ne maîtrise pas rès bien les commandes iptables pour le masquerading.
Il faudrait faire quoi comme commande sur le serveur mail ?
Il n'y a rien à faire du tout sur le serveur lui-même. Les règles
iptables sont à mettre en place sur les deux routeurs FW1 et FW2.
Sur FW2, remplacer l'adresse SNAT par 192.168.2.4.
Pour le protocole POP3, remplacer le port destination par 110.
Pour finir, il y a peut-être moyen d'éviter tout ça en jouant sur le TTL
au niveau DNS. En le réduisant suffisamment à l'avance avant de faire la
transition de l'adresse IP, les caches expireront rapidement (la
"réplication" est instantanée, c'est l'expiration qui prend du temps). Et
pendant ce temps, le(s) MX secondaire(s) garderont les mails en attente.
A ce moment là, il faut que je demande ça au registrar c'est bien ça ?
Plutôt au gestionnaire technique du domaine, celui qui gère la zone sur
le serveur DNS maître. Ça peut être le registrar mais pas forcément.
Autrement, il y a un moyen simple, rapide et sale (quick and dirty) de faire repartir les paquets de réponse par le bon routeur sans politique de routage, mais tu n'en voudras sûrement pas à cause de son "léger" défaut. Il suffit de faire du NAT source (SNAT) avec iptables sur les flux entrants redirigés par les deux routeurs. Ainsi l'adresse de destination d'un paquet de réponse émis par le serveur sera directement l'adresse du routeur à utiliser. Il y a cependant un inconvénient majeur évident : le serveur ne voit pas l'adresse source réelle des connexions qu'il reçoit
Heu pourquoi pas puisque c'est temporaire. Si c'est sale mais temporaire ça peut aller...
OK, c'est toi qui vois.
Je ne maîtrise pas rès bien les commandes iptables pour le masquerading. Il faudrait faire quoi comme commande sur le serveur mail ?
Il n'y a rien à faire du tout sur le serveur lui-même. Les règles iptables sont à mettre en place sur les deux routeurs FW1 et FW2.
Sur FW2, remplacer l'adresse SNAT par 192.168.2.4. Pour le protocole POP3, remplacer le port destination par 110.
Pour finir, il y a peut-être moyen d'éviter tout ça en jouant sur le TTL au niveau DNS. En le réduisant suffisamment à l'avance avant de faire la transition de l'adresse IP, les caches expireront rapidement (la "réplication" est instantanée, c'est l'expiration qui prend du temps). Et pendant ce temps, le(s) MX secondaire(s) garderont les mails en attente.
A ce moment là, il faut que je demande ça au registrar c'est bien ça ?
Plutôt au gestionnaire technique du domaine, celui qui gère la zone sur le serveur DNS maître. Ça peut être le registrar mais pas forcément.
