Trois serveurs dédiés et un cluster Public Cloud communiquent en « privé » via vRack. Personne ne filtre le trafic entre la base et les sauvegardes ; le monitoring ne voit que l'Internet public. Un compromis sur une machine virtuelle applicative devient un mouvement latéral gratuit — zone aveugle créée par confiance implicite. Le vRack résout un problème de câblage, pas de gouvernance : sans segmentation, vous avez seulement déplacé le risque à l'intérieur du périmètre OVHcloud.
Le vRack OVHcloud résout la connectivité privée entre services. Il ne résout pas la gouvernance des flux — c'est votre architecture.
vRack : ce qu'il fait et ne fait pas
| Capacité | vRack | À ajouter vous-même |
|---|---|---|
| Réseau privé L2 multi-services | Oui | — |
| Isolation Internet | Oui par défaut | Exposition volontaire via IP publique |
| Filtrage inter-VM | Non natif fin | Pare-feu, nftables, groupes de sécurité |
| Détection east-west | Non | Sonde, journaux, accès zero trust |
| Segmentation prod/admin | Non | VLAN logiques, listes de contrôle |
Modèle en zones recommandé
Définissez quatre zones avant le premier rattachement. Zone front : équilibreur de charge ou reverse proxy avec adresse IP publique contrôlée. Zone applicative : machines virtuelles sans route publique, joignables depuis le front uniquement.
Zone données : bases, stockage objet privé ; listes de contrôle strictes depuis la zone applicative seulement. Zone administration : bastion, intégration continue ; accès journalisé, pas de navigation générale.
Documentez une matrice de flux : source, destination, port, justification métier. Revoyez-la à chaque nouvel attach vRack.
Monitoring sans angle mort
Collectez les journaux pare-feu inter-zones (refus et autorisations). Surveillez la latence vRack inter-région si vous êtes multi-datacenter. Configurez des alertes sur nouvelle adresse IP ou port ouvert sur le vRack. Tenez un inventaire des services attachés — le vRack grossit silencieusement avec chaque projet.
Testez une cartographie trimestrielle : tout ce qui est attaché est-il encore nécessaire ?
Erreurs fréquentes
Un vRack plat mélangeant production, préproduction et sauvegarde. Une machine pivot avec adresse IP publique et accès total au vRack. Un DNS interne non documenté qui cache les dépendances. L'absence de chiffrement inter-machines sur données sensibles — le vRack n'est pas du chiffrement.
Pour l'accès administration, voir VPN ou bastion.
Revue trimestrielle : ce qu'il faut retirer
Chaque trimestre, listez les services attachés au vRack et supprimez ceux qui ne sont plus nécessaires. Un environnement de test oublié branché sur le même réseau privé que la production devient un pivot de compromission. Documentez aussi les règles de pare-feu inter-zones et vérifiez qu'aucune règle « temporaire » ouverte pour un debug n'est restée en place. Un vRack bien conçu réduit la surface exposée à Internet ; il ne remplace pas les mises à jour, la gestion des secrets ni le durcissement des machines individuelles — c'est une couche réseau, pas un substitut à la sécurité applicative.
Le sommet : privé ne veut pas dire sûr
Décider et avancer sans angle mort
Dessinez le schéma de zones avant le premier rattachement vRack et appliquez des listes de contrôle minimales dès le jour un. Rendez le monitoring east-west non négociable dans votre budget et votre runbook, planifiez une revue trimestrielle des services attachés, et documentez la matrice de flux pour chaque nouvel environnement. Comparez les architectures via nos guides et la fiche OVHcloud — le vRack connecte, vous filtrez et vous journalisez. Sans revue régulière, le réseau privé grossit jusqu'à devenir aussi opaque qu'Internet — avec moins de visibilité outil standard.
Questions fréquentes
Qu'est-ce que le vRack OVHcloud ?
Réseau privé de couche 2 entre services OVHcloud éligibles (dédiés, Public Cloud attaché, NAS), isolé d'Internet public par défaut, extensible sur une ou plusieurs régions.
vRack remplace-t-il un pare-feu ?
Non : vRack isole le trafic du réseau public ; le filtrage fin entre machines virtuelles reste à configurer via pare-feu, nftables ou groupes de sécurité.
Quelle erreur crée une zone aveugle ?
Un vRack plat sans listes de contrôle ni journaux, ou une machine pivot compromise avec accès total au réseau privé et une adresse IP publique.
Public Cloud et vRack ensemble ?
Oui via interfaces privées — planifiez adressage IP, routage inter-région et latence, et documentez quels projets cloud sont rattachés au vRack.
Le vRack connecte en privé ; vous décidez qui a le droit de parler à qui — sinon c'est un couloir sans caméra. Programmez une revue semestrielle de la matrice de flux avec l'équipe sécurité et l'exploitation pour retirer les attachés obsolètes.