Planifiez les sous-réseaux avant un VPN inter-sites : renumérotez ou traduisez

Deux bureaux utilisent tous deux 192.168.1.0/24 parce que personne n’a planifié autre chose, et l’on attend du tunnel qu’il règle cela. Il ne le peut pas : un routeur ne peut pas faire signifier à la même adresse privée deux endroits différents. Le travail qui l’empêche se fait avant la saisie du premier paramètre du tunnel.

Inventoriez chaque plage, y compris celles que vous avez oubliées

Recensez les LAN, les segments de serveurs, les pools de clients d’accès distant, les plages VPC du cloud et tout réseau de conteneurs ou superposé que les hôtes doivent atteindre. Les pools de clients sont ceux que l’on oublie, et ils chevauchent étonnamment souvent une plage de bureau parce que les deux ont été choisis dans le même réglage par défaut. Incluez le réseau de gestion et tout segment hors bande.

Notez le propriétaire, la passerelle, l’usage et le fait que le préfixe doive ou non être joignable depuis l’autre site. Un préfixe qui n’a jamais besoin de traverser le tunnel n’a pas à être unique, et le savoir réduit le travail de renumérotation.

Traitez IPv6 à part, car son plan et ses chevauchements sont indépendants.

Comparez les préfixes, pas les adresses familières

Deux réseaux ayant des adresses d’hôtes différentes peuvent quand même se chevaucher, car le chevauchement est une propriété des masques et non des nombres dont on se souvient. 10.20.0.0/16 contient 10.20.30.0/24, que quelqu’un le dise à voix haute ou non. Comparez des paires de préfixes complètes et vérifiez les agrégats par rapport aux réseaux plus petits qu’ils contiennent. C’est pourquoi le contrôle relève d’un tableur et non de la tête de quelqu’un.

Le même contrôle s’applique au pool de clients du VPN lui-même et à toute plage traduite que vous prévoyez d’introduire, car une plage traduite qui entre en collision est pire que le chevauchement d’origine.

Un tableau de préfixes avec masques suffit ; un schéma sans masques non.

Décidez ce qui doit réellement traverser

Un site peut contenir trente sous-réseaux alors qu’un réseau de service a besoin d’un accès distant. Partez de cette exigence et n’annoncez que ce dont elle a besoin, car des annonces plus petites et des règles d’accès correspondantes sont plus faciles à relire et plus difficiles à élargir par accident. Annoncer toutes les plages privées utilisées est une habitude qui transforme un tunnel en pont. Plus l’annonce est étroite, plus le rayon d’impact d’une erreur future est petit.

Le DNS privé doit renvoyer des adresses que les clients prévus peuvent joindre, donc un nom pointant vers une plage non annoncée ou chevauchante reste cassé même lorsque la résolution réussit.

Écrivez la liste d’accès avant la configuration du tunnel, pas après son échec.

Renumérotez ou traduisez, et connaissez le coût

La renumérotation d’un réseau est généralement le remède le plus clair à long terme, et elle touche les réservations, les appareils, le DNS, les règles de pare-feu et tout ce qui a une adresse gravée dans une configuration. La traduction d’une plage d’accès est l’alternative lorsque la renumérotation est peu pratique, et elle coûte l’identité de la source plus une classe de protocoles qui intègrent des adresses dans les charges utiles. Choisissez-en une et terminez-la, car un réseau à moitié renuméroté est pire que l’une ou l’autre option.

Quel que soit votre choix, documentez à la fois l’adresse d’origine et l’adresse présentée, car chaque conversation de dépannage ultérieure a besoin des deux.

Un contournement sans chemin de retour n’est pas un contournement.

Terminez par une matrice comme test d’acceptation

Terminez par une matrice : préfixe local, préfixe distant, service autorisé et passerelle de retour. Ce tableau constitue le test d’acceptation à l’établissement du tunnel, et c’est aussi le document que l’ingénieur suivant lira. Testez depuis de vrais hôtes sur les sous-réseaux choisis plutôt que depuis les passerelles.

Un ping entre adresses de tunnel prouve que le tunnel existe et rien sur le plan d’adressage derrière.

Conservez la matrice avec la configuration du tunnel, et le prochain ajout de site partira de données plutôt que de mémoire. Le guide de transfert de strongSwan couvre le côté passerelle une fois le plan établi.