Défi geek
Ce défi est une expérience, il n'y aucun prix pour le moment. Si la sauce prend, il est envisagé d'organiser des concours dans un cadre plus intéressant.
Ce problème a été soulevé par une grosse entreprise. La solution est déjà connue, je ne le pose ici que pour le jeu. Bien entendu le problème a été ramené à un cas d'école pour faciliter la compréhension et la réflexion.
Il est inutile de tester votre solution et vous pouvez en proposer plusieurs via les commentaires. Ces derniers sont modérés pour garder le secret quelques jours. Bien sûr cela ne vous empêche pas de commenter que je suis une personne excécrable ou que le multicast marche mieux sous NetBSD. Quiconque laisse un commentaire sera averti par E-mail de la mise en ligne de la solution.
Une version de ce problème correspondant à l'environnement réel de l'entreprise arrivera peu après la résolution de ce premier problème. La complexité et la difficulté seront supérieures.
Objectif :
Les clients envoient des requêtes en broadcast, un service déjà configuré sur le serveur doit y répondre.
Contexte :
- Serveur Linux avec une carte Ethernet, configuré comme suit :
- Distribution moderne générique (Debian, Ubuntu, Fedora, etc.) dont noyau Linux 2.6 ;
- La carte Ethernet est configurée avec
ifconfig eth0 10.0.0.1 netmask 255.255.255.0, addresse de broadcast par défaut soit 10.0.0.255 ; - L'interface de loopback (lo) est disponible ;
- Chaînes netfilter vides, politique par défaut ACCEPT, le reste de la configuration est celle de l'installation par défaut de la distribution ;
- Les clients sont sur le même segment Ethernet (i.e. aucun routeur), sur 10.0.0.0/16, addresse broadcast par défaut soit 10.0.255.255 ;
- Les ports utilisés ne sont pas connus (par exemple rpc.bootparamd).
Contraintes :
- Le serveur ne peut écouter que sur 10.0.0.0/24 et 10.0.255.255, ne peut émettre que sur 10.0.0.0/24 (les raisons pour ce type de contraintes seront plus claires dans la version complexe) ;
- La configuration réseau du serveur est librement modifiable tant que la règle précédente est respectée et assurée dans l'espace noyau ;
- La configuration réseau des clients ne peut pas être changée ;
- Pas de patchs ou de paquets ésotériques ;
- La solution tient sur 3 commandes exécutées en root. Elles ne peuvent reposer que sur des outils disponibles sur toute distribution moderne générique. Inutile de faire en sorte que les changements persistent après un redémarrage, de toute façon un serveur ne crashe pas et n'a pas besoin de redémarrer.
Si vous autorisez le serveur à émettre sur 10.0.255.255 et acceptez d'êtres crades (mais compatibles avec au moins Solaris et Linux), une commande suffit.
Edit du 17 avril 2010, aka « La soluce »
Xav l'emporte avec sauf erreur de ma part 2 fautes d'étourderie sur iptables (il faudrait utiliser -A au lieu de -l et –to-destination au lieu de -to) !
Je préfère ne pas créer de VLAN et reposer sur du SNAT pour que les logiciels « voient » l'adresse de destination des requêtes, c'est plus transparent et ça pourrait jouer un rôle avec une implémentation de bootparamd par exemple (puisque le client demande entre autres quel routeur utiliser).
On peut attacher des IP individuelles à une interface existante sans créer d'interface virtuelle (eg eth0:1) et avec un masque implicite de /32 avec ip addr add.
Ma solution favorite est donc (avec :0-1023 pour désactiver le mécanisme de changement de ports) :
# ip addr add 10.0.255.255 dev eth0
# iptables -t nat -A POSTROUTING -s 10.0.255.255 -j SNAT –-to-source 10.0.0.1:0-1023

Vous aussi, bénéficiez d’un accès à Internet partout en France pour pas cher ! Bien sûr, l’« illimité » de mon titre est à prendre au sens opérateur : pas d’interruption stricte du service en cas de dépassement d’un quota. Par contre, Orange vous interdit la voix sur IP, le partage de documents de pair à pair, se réserve le droit de brider (encore plus) la connexion si vous l’utilisez trop, y tutti quanti. Il faudra que je vérifie personnellement pour ce contrat précis, mais le contraire m’étonnerait.
