Supports de cours
Projet :
Theme 1: répartition de charge
On vous demande de mettre en place une maquette
LVS-DR. Dans votre rapport, vous décrirez votre maquette et les outils
à mettre en place ainsi que leur configuration. Vous expliquerez ensuite
en vous appuyant si nécessaire sur des captures de trâmes la façon dont
fonctionne le mode DR et les transformations subies par les paquets
d'une requête.
Date de rendu: vendredi 4/11 au soir.
Theme 2: tolérance de panne
On vous demande de mettre en place une maquette
haute disponibilité LVS-DR en utilisant l'outil keppalived. Dans votre rapport, vous décrirez votre maquette et les outils
à mettre en place ainsi que leur configuration. Vous expliquerez ensuite
en vous appuyant si nécessaire sur des captures de trâmes la façon dont
fonctionne le mode DR et les transformations subies par les paquets
d'une requête.
Date de rendu: lundi 28/11 au soir par mail (1 point de moins par jour de retard)
vous fournirez les fichiers .cap des captures utilisées dans le rapport
l'objet (Subejct:) de votre mail sera "M1ASR THEME2 votre nom"
pas de fichier .rar SVP
Thème 3 : tolérance de panne avec Packet Filter
On vous demande de monter une maquette avec des routeurs-coupe feu
statefull supportant la tolérance de panne via le protocole CARP : si 'lun des routeurs tombe
en panne, l'autre prend le relais. Vous êtes libres du choix des
systèmes d'exploitation (OpenBSD ou FreeBSD). Vous
expliquerez et mettrez en évidence :
- les protocoles en jeu
- l'intérêt et les cénarios d'utilisation des ip/Mac virtuelles
- les cas de figure où un dialogue entre coupe-feu est nécessaire et ce qui contient ce dialogue.
- vous ferez des tests pour illuster l'impact sur un poste client
de la mise hors service d'un coupe feu puis de la remise en service
d'un coupe feu.
- une comparaison avec vrrp/keepalived du thème 2
Vous fournirez les captures de trames wireshark utilisées dans votre
rapport. A noter : ces captures doivent être personnelles. Il n'est pas
autorisé à un étudiant d'utiliser les captures réalisées sur la
maquette d'un autre étudiant.
Un exemple de maquette :

Date de rendu : 15/12/2010
Liens et documents
une boîte à outils de liens en vrac, certains
utilisés et lus, d'autres mis là au cas où ils
puissent me servir. Ce qui suit est plutôt là pour
mon usage personnel ce qui explique le côté un peu
désordonné de la chose.
traduction d'adresses
- 2005-11-une page claire en français qui résume les
RFC3022
et RFC2663 : http://www.securiteinfo.com/conseils/nat.shtml
- "rfc
2663:
IP Network Address Translator (NAT) Terminology and Considerations": ce
document place tant le vocabulaire et que les concepts. C'est un
document à lire
- "rfc
3022:Traditional
IP Network Address Translator (Traditional NAT)": précise
certains points de la rfc 2663 dans le cadre du NAT traditionnel
(sortant ou port forwarding)
- "rfc
3027:
Protocol Complications with the IP Network Address Translator":
problèmes et solutions posés par le NAT décrit sur
des exemples concrets de protocoles.
- "rfc
2993:
Architectural Implications of NAT": bilan sur le NAT après
quelques années de déploiement
- "rfc
3235:Network
Address Translator (NAT)-Friendly Application Design
Guidelines":
ràf
- "rfc
1579:
Firewall-Friendly FTP"
- "rfc
959:
FILE TRANSFER PROTOCOL (FTP)"
- "rfc
3489:
STUN: Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs): comment permettre à des clients et
à des serveurs de communiquer s'ils sont tous deux
derrières des routeurs NAT. Une variante est utilisée par
Skype (cf http://www-sop.inria.fr/semir/personnel/Didier.Benza/skype/skype.pdf)
filtre de paquets, firewall