Project-Id-Version: Trac 0.12
Report-Msgid-Bugs-To: trac-dev@googlegroups.com
POT-Creation-Date: 2013-01-27 11:21+0900
PO-Revision-Date: 2010-07-19 23:05+0200
Last-Translator: Jeroen Ruigrok van der Werven <asmodai@in-nomine.org>
Language-Team: en_US <trac-dev@googlegroups.com>
Plural-Forms: nplurals=2; plural=(n != 1)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Generated-By: Babel 0.9.6

Discussion/ServicesExternes – Trac ResEl
wiki:Discussion/ServicesExternes

Comme le dirait si bien Guiling, "Il est venu le temps des rires et des chants", alors c'est le temps au ResEl de la migration des services réstants, à savoir majoritairement ceux présents sur baal.

Rappel des faits

L'année dernière, le ResEl fut complètement virtualisé. Après le travail de la promo 2009 (et d'autres plus vieux), la majorité des services du ResEl furent migrés. Entre temps, un nouveau plan d'adressage a été établi. On peut le retrouver ici : https://trac.resel.fr/wiki/Discussion/Routage.

Il reste ainsi à migrer les services restants sur baal, à savoir le site du resel (sur cyric), les sites de clubs (sur golf), Jabber (cherche migrateur ;)) et le SSH de l'extérieur pour les admins.

The problem

Comme au ResEl on a pas beaucoup d'IP publiques (aux nombres de 4 me dit-on : 192.44.76.{8,34,35} pour Brest, et 192.44.77.81 pour Rennes), on est obligé de faire du DNAT/SNAT depuis l'extérieur. La situation acutelle (à Brest) n'utilise qu'une seule de ces IP : 192.44.76.8, qui arrive, après routage de la DISI, sur lily.

Il faut de plus qu'un service donné (HTTP par exemple, port 80, celui que nous prendrons pour exemple par la suite) soit accessible de l'intérieur et extérieur de manière transparente (utilisant le même DNS, resel.fr par exemple pour le site du ResEl :) , mail.resel.fr pour les mails), et que, si une requête vient de l'intérieur, on puisse avoir l'IP source de la demande (et non par exemple celle de lily).

Aujourd'hui, cela est réalisé grâce à une DMZ. Le tout est expliqué en détail là : https://trac.resel.fr/wiki/Configuration/Firewall mais en résumé, pour la DMZ, ça donne ceci :

  • si l'on demande resel.fr (résolue en interne en 192.44.76.8) sur le port 80 de l'intérieur, alors lily le DNAT vers 10.0.1.2, l'IP de baal dans la DMZ pour les requêtes internes.
  • si l'on demande resel.fr sur le port 80 de l'extérieur, alors même combat, sauf que le DNAT se fait vers 10.0.1.3
  • pour la réponse de baal, elle repasse nécessairement par lily (car elle essaie d'envoyer à une IP externe à la DMZ), et ainsi lily le SNAT (car la machine source attend une réponse de lily)

Ainsi, baal voit bien une requête venir de l'IP source (la vraie, celle du 999, ou l'IP provenant d'internet).

Et si on vire la DMZ actuelle ?

Imaginons que baal meurt, et que tous les services aient été virtualisés entre temps. Il n'y aura plus rien dans la DMZ actuelle, on la supprimerait donc. On pourrait la garder, mais pas comme elle est réalisée maintenant. En effet, tout repose sur le fait que sur lily, une interface réseau est dédiée à la DMZ. Avec la virtualisation actuelle, les serveurs qui seraient dans la DMZ ou non seraient tous sur la même interface (l'interface dite "intérieur" sur lily). On pourrait néanmoins faire un VLAN pour la "DMZ" (qui ne serait plus ainsi une vraie DMZ). Celà est étudié plus en détail ci-dessous.

Ensuite, si on garde les DNS comme actuellement (resel.fr qui résout en 192.44.76.8), on serait obligé de faire comme ceci :

  • si une IP 999 demande le 80 de resel.fr, alors lily doit DNATer et SNATer vers le port 80 de cyric.
  • le problème est que cyric voit la requête comme émanent de lily... pas terrible.

Une idée (ebzao powered, encore et toujours..) est d'utiliser une vue interne et externe des DNS. Ainsi, si la requête DNS est faite de l'extérieur, alors l'IP retournée est l'IP publique du ResEl (la fameuse 192.44.76.8), mais, si elle est faite de l'intérieur, on retourne directement l'IP 994 de cyric. Ainsi, de l'extérieur, on DNAT vers le 80 de cyric, et, de l'intérieur, lily ne rentre pas en jeu, car le DNS résout directement vers cyric. C'est ce qui est fait actuellement avec mail.resel.fr, qui résout sur lily de l'extérieur (et lily DNAT le 25 vers mercure), et vers mercure.pub.maisel.tb de l'intérieur.

Edit (Jeb): C'est un peu pour ca aussi qu'on a fait des vues pour le DNS. Actuellement un a globalement une vues / vlan. Internet c'est qu'un Vlan de plus..
La solution me plait bien :)

Et avec plein d'IP publique ?

On peut aussi se la faire différemment, et considérer que les machines du 994 possède aussi une IP publique. Alors là, tout va bien, on fait résoudre les bon services (mail.resel.fr, clubs.resel.fr, resel.fr) vers les IP publiques correspondantes, et on rajoute des règles de ce type sur GO :

  • Règle actuelle pour lily : ip route 192.44.76.8 255.255.255.255 172.16.29.1.
  • Par exemple pour Golf, avec 192.44.76.9 en ext et 172.22.42.88 en IP 994 : ip route 192.44.76.9 255.255.255.255 172.22.42.88.

Edit (Jeb): C'est pas si simple du tout, le 76.0 c'est un reseau en /24 utilisé sur lily, Il faudrait etendre le vlan 76 (internet) de l'école sur GO, ainsi Lily et Golf deviendrait directly connected et donc il n'y aurai pas besoin de route spécifique sur GO. (Ou alors faire porter tous le routage par Lily, cf en bas de la page Routage)

On pourrait aussi éviter de passer par GO et réutiliser le concept des vues DNS expliqués ci-dessus.

Edit (Jeb): Tu peux pas eviter de passer par GO :)
Edit (Geekou): Je voulais dire, éviter de mettre des règles sur GO ;)

De plus, un firewall bien configuré sur chacune de ces machines ne peut pas faire de mal.

Lily ne s'occuperait ainsi plus que de l'accès internet à partir du 999.

Edit (Jeb): Cette solution me parait très mauvaise car la Disi est plutôt dans une optique de nous virer de leur plage d'IP. A terme je pense qu'on risque de se retrouver avec 1 seul IP. Voir un jour avec un provider autre que l'école qui nous donnera surement qu'une IP. La solution ne me parait donc pas viable à long terme.

Un peu de sécurité

Pour rappel, chaque machine du ResEl est au moins sur le VLAN 997 d'administration des machines. Ce VLAN est complètement fermé du VLAN user, mais permet d'accéder à toutes les machines du ResEl. Ainsi, si une machine du VLAN 994 (VLAN publiques des serveurs, là où par exemple est bindé le port 80 de cyric) se voit rooté, se serait dommage qu'elle ait accès au 997. Il faudrait ainsi reprendre un peu le principe de DMZ et confiner ces machines dans un VLAN, prenons par exemple le 992 (sur suggestion d'ebzao :) ). Ainsi, le SSH des machines dans le 994 écouterait sur le 992, et si on ne peut pas sortir du 992 ni du 994, seulement "entrer" par les VLAN adéquats, alors on confine la "menace". De plus, le SSH des switchs écoute sur le 998, qui est complètement fermé et n'est accessible que depuis les machines ayant une pate dedans (actuellement pegase, echelon et sauternes). En résumé, ça donnerait ceci :

  • 999 -> 994 : OK
  • 997 -> 992 : OK
  • tout le reste serait droppé
  • si pas d'IP publiques : 994 -> internet : pour l'instant ouvert seulement pour les machines en ayant besoin (mercure par exemple). Le choix se fait sur lily.

Remarque de Jeb qui tue tout :

Grandours n'est pas, comme dirait Jeb, "statefull", c'est-à-dire qu'en gros il n'existe pas d'équivalent du module tcp_conntrack d'iptables par exemple. Ainsi, si on veut autoriser le sens 997->992:22, il faut aussi autoriser 992:22->997, ce qui reste quasi-équivalent à autoriser 992->997 (vu qu'il faudrait ainsi seulement faire des connexions avec un port source 22 après avec killé sshd). Donc on a plus qu'à oublier l'idée, ou changer GO..

Remarque de Lo0 : Jeb a tord :p Re Remarque de Jeb : Entre temps on m'as dit que les reflexive ACL pourrissait pas mal les perf et n'était pas super secure... à voir donc

=> Justement, on a regardé, et donc :

Avec ces ACL qui feraient un VLAN 992 sur la plage 172.22.92.0/24 (qui, soit dit en passant, auraient dû plus être quuelque chose comme 172.22.4.0/23, pour être en accord avec ce qui existe déjà, mais c'est un détail) :

interface Vlan992
 ip address 172.22.92.254 255.255.255.0
 ip access-group FROM_PUBLIC_DMZ in
 ip access-group TO_PUBLIC_DMZ out

interface Vlan997
 ip address 172.22.3.254 255.255.254.0
 ip access-group FROM_ADM_NETWORK in
 ip access-group TO_ADM_NETWORK out

ip access-list extended FROM_ADM_NETWORK
 [...]
 permit tcp 172.22.2.0 0.0.1.255 172.22.92.0 0.0.0.255
 deny   ip any any log
ip access-list extended FROM_PUBLIC_DMZ
 evaluate ACL_RFLX_FROMDMZ
 deny   ip any any log
ip access-list extended TO_ADM_NETWORK
 permit tcp 172.22.92.0 0.0.0.255 172.22.2.0 0.0.1.255
 [...]
 deny   ip any any log
ip access-list extended TO_PUBLIC_DMZ
 permit tcp 172.22.2.0 0.0.1.255 172.22.92.0 0.0.0.255 reflect ACL_RFLX_FROMDMZ
 deny   ip any any log

le tout marche, mais il y a ces messages d'erreurs dans les logs :

Jan  7 14:38:48: %ACLMGR-3-INVALIDPARAM: Invalid ACL type 5 encountered
-Traceback= CD923C CD9950 48914C 4594AC 937990 92E658
Jan  7 14:38:48: %ACLMGR-3-INVALIDPARAM: Invalid ACL type 0 encountered (grandours-2)
-Traceback= CD923C CD9950 48914C 4594AC 937990 92E658 (grandours-2)

Après contact du support de Cisco (merci Jeb sur ce coup là ;)), ceux-ci nous ont affirmé qu'en fait, les ACL reflexives n'étaient pas supportés au niveau "hardware" du switch, et donc c'est son CPU qui traite entièrement l'ACL. De plus, officiellement, ces ACL ne sont pas supportées (cf. http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/configuration/guide/swacl.html#wp1031180 , au 09/01/09).

Ainsi, on peut tenter le diable et laisser le 992 comme ça (on "espérant" qu'il n'y ait pas trop de transfert entre le 992 et le 997, normalement non, mais bon..), ou alors acheter un vrai routeur (demandez à Jeb et/ou Lo0 pour le choix..), ou déporter le routage entre les VLAN sur une box Linux/BSD (le moins cher en soi..), voir une VM, et reswitcher le routage sur GO si jamais cette VM tombe.

Edit (Jeb) : C'est un firewall qui faut, pas un routeur, en l'occurrence il faut un ASA 5510 (ou mieux). Sinon il faut de l'HSRP ou du VRRP car les user point sur une gateway fixe. Ou alors il faudrait faire des VRF sur GO pour isoler le routage du Vlan 999 (sinon, comme les autre vlan sont directly connected, le routage est fait directement) et ensuite faire du routage OSPF entre la VRF du vlan 999, la VRF des autres vlan et le firewall. (en fait il faudrait même une VRF / vlan, c'est overkill)

Conclusion

Oui, j'avais promis quelques schémas, mais j'ai pas vraiment le temps là. Il y a sûrement quelques subtilités de routes bizarres avec la DISI/le RIRE que j'ai oubliées, et c'est pour ça qu'a été faite cette page, pour que chacun puisse critiquer/contribuer ;)

Last modified 9 years ago Last modified on Jan 12, 2009, 1:22:26 PM