Accès réseaux

Trois cas sont possibles :

  • Type 1 le réseau fourni est privé et non routé, l’accès extérieur utilise les IPs flottantes

  • Type 2 le réseau fourni est privé, routé au CC-IN2P3, avec un accès SNAT vers internet

  • Type 3 le réseau est public

Chaque projet se voit attribué à sa création un réseau de l’un de ces types, en fonction des besoins du use case (orienté service HA, R&D…).

Déterminer le mode réseau configuré

Votre projet Openstack s’est vu attribué à la création un réseau dédié. Si vous ne savez pas quel est le mode réseau défini, démarrez une VM et déterminez l’adresse IP qui lui a automatiquement été attribuée (commande openstack server show).

  • l’IP appartient à un subnet privé (172.16.0.0/12, 10.0.0.0/8, 192.168.0.0/16), le réseau est de type 1 ou 2

    • l’IP peut être pingée depuis une interactive : le réseau est de type 2

    • l’IP n’est pas pingable, le réseau est de type 1 (non routé + IPs flottantes)

  • l’IP est publique, le réseau est de type 3 (public)

Important

Réseau privé, non routé avec IPs flottantes

Lorsqu’une instance est démarrée, elle obtient une IPv4 privée qui n’est pas routable. Elle peut communiquer avec le reste des VMs instanciées mais pas avec l’extérieur. Pour obtenir une IP publique routable, il faut associer une floating ip NATée.

Les IP publiques ne sont pas filtrées en sortie, ce qui signifie qu’il est possible de se connecter depuis une instance à n’importe quel service hébergé à l’extérieur du CC-IN2P3. Par contre ces IP sont filtrées en entrée, le seul port ouvert est le 22 depuis les serveurs interactifs.

IPV6

Il est possible d’obtenir des adresses IPV6 sur le cloud. Cela passe pour l’instant par une configuration manuelle.

ACLs réseau

Il y a deux niveaux de pare-feu :

  • le premier niveau est géré sur le coeur de réseau du CC. L’ajout d’ACLs est réalisé à la demande (au support utilisateurs) et dans la mesure où la demande réalisée est compatible avec la politique de sécurité du centre de calcul. La fixation d’ACLs est également dépendante de ce qui a été convenu avec le CC-IN2P3 au moment de la création du projet.

  • le second niveau est implémenté dans le cloud via le mécanisme des groupes de sécurité (secgroups). Les utilisateurs du cloud sont maitres de la définition des règles en place à ce niveau.