Un sélecteur IPsec large n’est pas une autorisation pour chaque service

Deux pairs s’accordent pour protéger tout un sous-réseau, et quelqu’un lit cet accord comme une autorisation d’atteindre chaque service à l’intérieur. C’est le mythe : le sélecteur indique quel trafic le tunnel accepte de transporter, et il ne dit rien des services que l’organisation autorise. Une paire d’équipements peut légitimement négocier une plage d’adresses large alors que la politique d’accès à l’intérieur autorise deux ports, et les deux affirmations restent vraies en même temps.

La couverture protégée n’est pas une autorisation

Un sélecteur de trafic fait partie de l’accord de tunnel. Il restreint ou confirme ce que les pairs chiffreront entre eux, et un sélecteur large est souvent la chose la plus simple à exploiter lorsque les deux côtés ont beaucoup de flux à transporter. Le filtre de services est un autre contrôle, à un autre point du chemin, et il décide de ce qui peut réellement être utilisé une fois le paquet déchiffré. Retirer le filtre pour faire passer un test transforme une décision de politique en accident.

Gardez les deux enregistrements séparés dans le document de conception, car un lecteur qui ne voit que le sélecteur en déduira une autorisation qui n’a jamais été accordée. Deux lignes dans un journal de modification l’empêchent, et elles prennent moins de temps que la discussion qui suit.

Décrivez un flux depuis les deux extrémités

Notez l’initiateur, le répondeur, la source et la destination tels qu’ils sont présentés, le protocole et les deux ports. Inversez ensuite chacune de ces étiquettes pour l’autre extrémité, car le port source éphémère d’un client devient le port de destination d’une réponse et le réseau distant devient le réseau local. Une configuration copiée d’un côté vers l’autre sans cette inversion est la façon dont les filtres finissent par autoriser exactement la mauvaise direction. Écrivez le tableau une fois et construisez les deux filtres à partir de lui.

Mettez-vous d’accord sur le modèle de sélection avant de copier quoi que ce soit, car une conception fondée sur des politiques et une conception fondée sur des routes expriment la même intention au moyen d’objets différents. Écrivez le nom du modèle à côté du flux, sinon l’ingénieur suivant passera un après-midi à faire correspondre des objets qui n’ont jamais été comparables.

Trouvez le filtre qui s’applique réellement

Sur un ASA, le filtre VPN est une ACL attachée à une politique de groupe et appliquée au trafic après déchiffrement et avant chiffrement. La documentation Cisco des politiques de groupe décrit aussi l’héritage, dont une valeur au niveau utilisateur qui remplace celle de la politique de groupe. L’ACL que vous avez modifiée n’est donc peut-être pas celle qui régit la session devant vous. Il en va de même pour l’objet utilisateur, qui peut supplanter le groupe sans laisser beaucoup de traces visibles.

Inspectez la session effective plutôt que l’objet dont vous vous souvenez avoir modifié, et notez quel objet de politique la fournit. Cette seule étape résout un nombre surprenant de rapports du type le filtre est correct mais il ne fonctionne pas.

Direction, ports et cas inverse

La convention documentée place le réseau distant, ou les adresses attribuées aux clients distants, en position de source et le réseau local en position de destination, les réponses s’exprimant par échange des positions d’adresses. Les règles de ports se superposent à cette convention et méritent plus de soin que les adresses.

Le modèle documenté peut laisser une règle de port de destination affecter une initiation inverse qui utilise ce même port source, ce qui signifie que le filtre n’est pas simplement une règle de requête unidirectionnelle assortie de réponses inoffensives. Raisonnez explicitement les deux sens d’initiation et incluez le cas que vous voulez refuser.

La même documentation limite le filtre aux connexions initiales, ce n’est donc pas une application universelle de chaque canal secondaire qu’ouvre une application inspectée. Là où la politique complète exige cette couverture, elle relève d’une frontière distincte plutôt que d’une ACL étirée au-delà de son objet.

Testez trois cas avant de le déclarer terminé

Acceptez le flux prévu, refusez un service que la politique interdit et exercez le cas de direction inverse que vous avez raisonné. Exécutez-les selon un plan approuvé, avec les identités et les sélecteurs que vous allez déployer. Un test qui montre seulement que le service autorisé fonctionne démontre le tunnel, pas la politique.

Gardez la couverture négociée et la décision d’accès comme deux enregistrements, car expliquer ce qu’un VPN autorise exige les deux.