Bonjour,
La situation initiale (simplifiée) est :
ligne ADSL -----> IPCOP - IP 10.1.0.1 ---ORANGE-----> serveur 10.1.0.10
Nous ajoutons une nouvelle ligne SDSL qui remplacera la ligne ADSL. Pendant la migration, la situation sera la suivante :
---Ligne ADSL -----> IPCOP - IP 10.1.0.1 ---ORANGE-----> serveur 10.1.0.10
---Ligne SDSL ------> IPCOP - IP 10.1.0.2 ----ORANGE ------ le même serveur
Le serveur n'a qu'une passerelle par défaut de déclarée et ne peut être joint que par une ligne.
Lorsque j'engagerai la migration, je devrai donc modifier les DNS (externe) et la passerelle par défaut.
Nous seront donc dans le noir pendant la propagation des DNS.
Question : Puis-je ajouter une deuxième passerelle au serveur (sous LINUX) pour qu'il réponde au deux lignes quelque soit l'état de la propagation des DNS.
La conf se joue probablement dans /etc/network/interfaces ..... mais sur quelle syntaxe ?
Migration de ligne SDSL
Modérateur: modos Ixus
4 messages
• Page 1 sur 1
Migration de ligne SDSL
par SNORK » 21 Août 2008 11:01
-
SNORK - Lieutenant de vaisseau
- Messages: 246
- Inscrit le: 12 Mars 2003 01:00
- Localisation: Asnières
par jdh » 22 Août 2008 07:52
Voilà une question intéressante et claire !
nom dns = adresse ip ADSL puis adresse ip SDSL selon le temps de propagation DNS.
En effet, à un instant t, entre 0 (changement du DNS) et environ 2 jours, il est possible que 2 clients aient des correspondances différentes.
Il y a 2 façons de réagir :
- basculer le nom dns un vendredi soir et dire samedi et dimanche "peu importe",
- basculer le nom dns et adopter une architecture "adaptée" puis 2 jours après revenir à une architecture "normale".
L'architecture "adaptée" doit permettre d'utiliser les 2 adresses ip pour accéder au serveur (en DMZ) pour faire en sorte que le serveur réponde quelque soit la correspondance nom dns <-> adresse ip, et ce durant 2 jours.
Tu as bien compris que le trajet du paquet dans le sens VERS le serveur ne pose pas de problème avec 2 firewalls. Mais c'est le paquet retour qui pose problème !
Disposer de 2 passerelles au niveau du serveur NE SERT A RIEN bien évidemment ! Parce que le paquet retour doit être aiguillé selon son adresse d'arrivée ... ce qui ne peut être réalisé qu'au niveau du firewall qui assure un suivi de connection tout en faisant la redirection vers le serveur DMZ.
La seule façon d'y arriver est d'utiliser un firewall à 2 entrées Internet (donc 2 adresses publiques) : le suivi de connection doit tenir compte d'un marquage selon l'interface d'arrivée :
- paquet entrant : adr ip client source -> adr ip dest => marquage interface arrivée + changement adr ip dest pour adr ip serveur
- paquet sortant : adr ip serveur -> adr ip client source => changement ip serveur en ip dest + envoi paquet via MEME interface
IPCOP n'est pas adapté puisqu'il ne sait pas gérer 2 interfaces Internet. Peut-être que pfSense, qui sait faire du multi-wan saurait gérer ce cas ...
Une autre solution serait d'avoir 2 serveurs indépendants donnant le même résultat ... ce qui sera difficile.Ou d'utiliser non pas 2 serveurs mais 2 proxy (ies) s: dépend du protocole !
nom dns = adresse ip ADSL puis adresse ip SDSL selon le temps de propagation DNS.
En effet, à un instant t, entre 0 (changement du DNS) et environ 2 jours, il est possible que 2 clients aient des correspondances différentes.
Il y a 2 façons de réagir :
- basculer le nom dns un vendredi soir et dire samedi et dimanche "peu importe",
- basculer le nom dns et adopter une architecture "adaptée" puis 2 jours après revenir à une architecture "normale".
L'architecture "adaptée" doit permettre d'utiliser les 2 adresses ip pour accéder au serveur (en DMZ) pour faire en sorte que le serveur réponde quelque soit la correspondance nom dns <-> adresse ip, et ce durant 2 jours.
Tu as bien compris que le trajet du paquet dans le sens VERS le serveur ne pose pas de problème avec 2 firewalls. Mais c'est le paquet retour qui pose problème !
Disposer de 2 passerelles au niveau du serveur NE SERT A RIEN bien évidemment ! Parce que le paquet retour doit être aiguillé selon son adresse d'arrivée ... ce qui ne peut être réalisé qu'au niveau du firewall qui assure un suivi de connection tout en faisant la redirection vers le serveur DMZ.
La seule façon d'y arriver est d'utiliser un firewall à 2 entrées Internet (donc 2 adresses publiques) : le suivi de connection doit tenir compte d'un marquage selon l'interface d'arrivée :
- paquet entrant : adr ip client source -> adr ip dest => marquage interface arrivée + changement adr ip dest pour adr ip serveur
- paquet sortant : adr ip serveur -> adr ip client source => changement ip serveur en ip dest + envoi paquet via MEME interface
IPCOP n'est pas adapté puisqu'il ne sait pas gérer 2 interfaces Internet. Peut-être que pfSense, qui sait faire du multi-wan saurait gérer ce cas ...
Une autre solution serait d'avoir 2 serveurs indépendants donnant le même résultat ... ce qui sera difficile.Ou d'utiliser non pas 2 serveurs mais 2 proxy (ies) s: dépend du protocole !
-
jdh - Amiral
- Messages: 4741
- Inscrit le: 29 Déc 2002 01:00
- Localisation: Nantes
par SNORK » 22 Août 2008 13:08
Merci jdh pour cette réponse qui conforte hélas ce que je pensais.
Je ne suis pas certain que même votre solution "d'architecture adaptée' soit d'avantage jouable. En effet, même si les DNS tentent les 2 adresses successivement les 2 IP, le serveur ne pourra jamais être attaché aux deux passerelles.
La bonne solution aurait été comme vous l'indiquez d'utiliser des serveurs équivalents, éventuellement synchronisés mais l'opération serait trop lourde. Mon schéma était simplifié, dans la réalité, il y a plusieurs serveurs, sur des protocoles différents
Pfsense aurait aussi été une bonne solution mais j'ai d'autres problèmes avec Pfsense que je ne sais pas résoudre pour l'instant.
Donc, puisque nous sommes vendredi, nous ferons cette migration ce week-end en gérant au mieux cette zone d'ombre que va générer la propagation DNS.
Au passage, j'ai remarqué que cette question revenait très souvent sur le net, présentée parfois autrement et que beaucoup se perdent à donner des solutions confuses en y ajoutant à tord des histoires de load-balancing, d'agrégation de bande passante, d'ajouts de routes etc...
Chaque fois que je me plonge dans la passionnante lecture de TCP/IP dans le texte, je suis émerveillé par la qualité de cette vieille analyse mais là.... il y a tout de même un os. J'espère toujours qu'un jour quelqu'un m'expliquera que je n'est pas compris et qu'il n'y a rien de plus simple ... je ne marque pas ce post [ résolu ], au cas où mais pour cette fois, c'est plié, je vais commencer ce soir Par prévenir tous les clients, modifier les 80 noms de domaines, ouvrir les ports sur la nouvelle ligne, modifier la conf réseau de chaque serveur et croiser les doigts.
Je ne suis pas certain que même votre solution "d'architecture adaptée' soit d'avantage jouable. En effet, même si les DNS tentent les 2 adresses successivement les 2 IP, le serveur ne pourra jamais être attaché aux deux passerelles.
La bonne solution aurait été comme vous l'indiquez d'utiliser des serveurs équivalents, éventuellement synchronisés mais l'opération serait trop lourde. Mon schéma était simplifié, dans la réalité, il y a plusieurs serveurs, sur des protocoles différents
Pfsense aurait aussi été une bonne solution mais j'ai d'autres problèmes avec Pfsense que je ne sais pas résoudre pour l'instant.
Donc, puisque nous sommes vendredi, nous ferons cette migration ce week-end en gérant au mieux cette zone d'ombre que va générer la propagation DNS.
Au passage, j'ai remarqué que cette question revenait très souvent sur le net, présentée parfois autrement et que beaucoup se perdent à donner des solutions confuses en y ajoutant à tord des histoires de load-balancing, d'agrégation de bande passante, d'ajouts de routes etc...
Chaque fois que je me plonge dans la passionnante lecture de TCP/IP dans le texte, je suis émerveillé par la qualité de cette vieille analyse mais là.... il y a tout de même un os. J'espère toujours qu'un jour quelqu'un m'expliquera que je n'est pas compris et qu'il n'y a rien de plus simple ... je ne marque pas ce post [ résolu ], au cas où mais pour cette fois, c'est plié, je vais commencer ce soir Par prévenir tous les clients, modifier les 80 noms de domaines, ouvrir les ports sur la nouvelle ligne, modifier la conf réseau de chaque serveur et croiser les doigts.
-
SNORK - Lieutenant de vaisseau
- Messages: 246
- Inscrit le: 12 Mars 2003 01:00
- Localisation: Asnières
4 messages
• Page 1 sur 1
Qui est en ligne ?
Utilisateur(s) parcourant actuellement ce forum : Aucun utilisateur inscrit et 1 invité