[gull] Changement d'adresse IP, routage IP Intranet

Ph. Voirol philm at netsystel.ch
Tue Jan 10 12:58:22 CET 2006


J'ai fait qqch de similaire recemment pour une migration d'un reseau
hoste par Urbanet vers des adresses Cablecom.
Mes machines (Debian, woody et sarge a l'epoque) avaient deja
plusieurs adresses IP "bindees" sur la meme carte ethernet mais elles
avaient aussi une carte ethernet supplementaire que je pouvais plugger
sur le nouveau switch.
On peut donc facilement dupliquer la structure d'adresses virtuelles
dans le nouveau reseau, le probleme c'est la gestion de deux routes
par defaut (en fait, on veut que le traffic qui rentre par une carte
ressorte par la meme).
On peut faire cela avec iproute2.
J'ai utilise le script ci-dessous, appele apres l'activation des
interfaces (il faut desactiver aussi les entrees gateway dans
/etc/network/interfaces, le script installe ses propres routes)


 #!/bin/sh

echo "NOT USING SPLITROUTING"
exit 0

set -u

PATH=/bin:/usr/bin:/sbin:/usr/local/bin

#
# urbanet
#
INTF_URBANET=eth0

# service addresses
ADDR_URBANET_0=
ADDR_URBANET_1=
ADDR_URBANET_2=

NET_URBANET=
GW_URBANET=
TABLE_URBANET=urbanet

#
# cablecom
#
INTF_CABLECOM=eth1

# corresponding service addresses
ADDR_CABLECOM_0=
ADDR_CABLECOM_1=
ADDR_CABLECOM_2=

NET_CABLECOM=
GW_CABLECOM=
TABLE_CABLECOM=cablecom


function define_routes
{
   echo "100  $TABLE_URBANET" >> /etc/iproute2/rt_tables
   echo "200  $TABLE_CABLECOM" >> /etc/iproute2/rt_tables

}
function install_routes
{
   ip route add $NET_URBANET \
        dev $INTF_URBANET src $ADDR_URBANET_0 table $TABLE_URBANET
   ip route add default via $GW_URBANET table $TABLE_URBANET

   ip route add $NET_CABLECOM \
        dev $INTF_CABLECOM src $ADDR_CABLECOM_0 table $TABLE_CABLECOM
   ip route add default via $GW_CABLECOM table $TABLE_CABLECOM


   ip route add $NET_URBANET dev $INTF_URBANET src $ADDR_URBANET_0
   ip route add $NET_CABLECOM dev $INTF_CABLECOM src $ADDR_CABLECOM_0
   ip route add default via $GW_CABLECOM
}

function install_rules
{
   for ADDR in \
        $ADDR_URBANET_0 \
        $ADDR_URBANET_1 $ADDR_URBANET_2
   do
      ip rule add from $ADDR table $TABLE_URBANET
   done

   for ADDR in \
        $ADDR_CABLECOM_0 \
        $ADDR_CABLECOM_1 $ADDR_CABLECOM_2
   do
      ip rule add from $ADDR table $TABLE_CABLECOM
   done
}

#####################################################################


case "$1" in
  define)
  #### DO THIS ONCE MANUALLY BEFORE ANYTHING ELSE
    echo -n "Defining split routing : "
    define_routes
    echo " done."
    ;;
  start)
    echo -n "Installing split routing : "
    install_routes
    install_rules
    echo " done."
    ;;
  special)
    echo -n "Installing routing rules: "
    install_rules
    echo " done."
    ;;
  stop)
    ;;
  *)
    echo "Usage: /etc/init.d/splitrouting {start|stop}"
    exit 1
esac


HTH

  --phv




On Wed, 4 Jan 2006 19:32:33 +0100
"Paul Veuve" <vep at cdisa.ch> wrote:

> Mesdames, Messieurs,
> 
>  
> 
> Notre provider internet par le téléréseau NET2000 va changer notre adresse
> IP fixe dans les prochains jours.
> 
> Nous utilisons cette IP fixe pour nos serveurs mail et web.
> 
>  
> 
> Actuellement les 2 adresses, l’actuelle et la nouvelle sont disponibles.
> 
>  
> 
> Durant la période de propagation de la nouvelle adresse dans les DNS, qui
> durera plusieurs jours, des requêtes parviendront par les 2 adresses.
> 
>  
> 
> J’ai pensé pouvoir résoudre le probléme en connectant 2 routeurs derrière un
> switch connecté au modem du téléreseau, l’un avec l’adresse actuelle A et le
> second avec la nouvelle adresse B.
> 
>  
> 
> Pour ce qui est des sorties, cela fonctionne sans problème en utilisant A ou
> B comme passerelle.
> 
>  
> 
> Cela ce complique, entre autre avec le serveur web avec les requêtes
> externes :
> 
> 1)         Une requête entre par A, qui la redirige vers le server web qui
> repond par sa passerelle vers A Ok
> 
> 2)         Une requête entre par B, qui la redirige vers le server web qui
> repond par sa passerelle vers A
> 
>             Est là, le pauvre emetteur de la requête qui attend une reponse
> de l’adresse B la reçois de l’adresse A
> 
>             et le browser et dans les choux. Il en vas de même avec le
> serveur mail.
> 
>  
> 
> Pour que cela fonctionne il faut que les requêtes provenant de A sortent par
> A et celle provenant de B sortent par B.
> 
>  
> 
> J’ai à disposition le serveur web qui tourne Debian. Le serveur mail et sur
> NT4 mais pourrait être transféré sur le serveur web.
> 
>  
> 
> Quelqu’un aurait-il une idée command résoudre ce problème autrement qu’en
> doublant momentanément les serveurs ?.
> 
>  
> 
> Merci pour votre aide.
> 
>  
> 
> Avec nos meilleures salutations.
> 
> Paul Veuve
> HYPERLINK "mailto:vep at cdisa.ch"vep at cdisa.ch
> 
> CDI CONSEILS ET DEVELOPPEMENTS
> INDUSTRIELS SA
> Chemin de la Justice 15
> CH-2000 NEUCHATEL
> 
> http://www.cdisa.ch
> 
> Phone  (+41 32) 733 31 31 or (+41 78) 600 31 31
> 
> Fax (+41 32) 733 31 32
> 
>  
> 
> 
> -- 
> <No virus found in this outgoing message cdi at cdisa.ch>
> Checked by AVG Free Edition.
> Version: 7.1.371 / Virus Database: 267.14.12/220 - Release Date: 03.01.2006
>  



More information about the gull mailing list