Que consigner pour un VPN de site à site : sélecteurs et portée

Six mois après la mise en service d'un tunnel, un nouveau sous-réseau cesse de correspondre à la stratégie et le seul document sur le partage dit VPN de bureau. C'est la défaillance qu'un registre de sélecteurs évite, et elle est précise : un ensemble d'adresses a changé alors que la paperasse non. Écrire correctement le registre suppose de savoir lequel de plusieurs ensembles d'adresses vous décrivez, et de consigner celui que le pair applique réellement plutôt que celui que vous avez configuré.

Configuré n'est pas négocié

Dans un tunnel IPsec basé sur des stratégies, chaque côté propose des sélecteurs de trafic : des plages source et destination pour l'association enfant. Le côté qui répond peut restreindre cette proposition , si bien que l'association installée peut couvrir moins que ce que la configuration énumère. Un registre qui recopie la configuration décrit donc une intention, pas la portée de protection actuelle. Les deux divergent en silence, et rien sur la page d'état du tunnel ne le signale.

Conservez les deux colonnes, avec la date à laquelle vous les avez observées. Le sélecteur configuré est ce que vous vouliez ; celui qui est négocié est ce que le noyau applique en ce moment. Quand ils diffèrent, cet écart explique une défaillance surprenante bien plus souvent qu'un défaut de routage.

Une association ne représente pas non plus chaque paire configurée. Un tunnel comportant plusieurs combinaisons de sélecteurs peut aboutir à plusieurs associations enfants, et un registre qui n'en énumère qu'une est un inventaire partiel. Énumérez-les au lieu de les résumer.

Les tunnels basés sur les routes sélectionnent autrement

Avec une interface basée sur les routes, la table de routage décide de ce qui entre dans le tunnel et les sélecteurs peuvent être volontairement larges. C'est une conception légitime et non de la négligence, et le registre doit la décrire comme telle. Notez la route, l'interface vers laquelle elle pointe et la stratégie de pare-feu qui limite les services joignables. La portée de protection est large à dessein, et la portée de service opère le resserrement.

Recopier un modèle basé sur les stratégies sur un tunnel basé sur les routes produit un document qui décrit un mécanisme que le déploiement n'utilise pas. L'ingénieur suivant cherche alors des sélecteurs qui n'auraient jamais dû être là, et conclut que le tunnel est mal configuré alors qu'il est seulement mal documenté.

La traduction relève du même tableau

Quand le NAT présente une autre plage au pair, consignez ensemble les préfixes d'origine et traduits. Notez l'étape à laquelle les sélecteurs et les règles d'accès les mettent en correspondance, car l'ordre décide si le côté distant voit jamais l'adresse que vous avez notée. Un tableau qui ne contient qu'une des deux plages est pire que pas de tableau, puisqu'il paraît complet.

C'est le détail qui casse un tunnel qui fonctionnait après un changement de NAT : le sélecteur correspond toujours au préfixe d'origine, le pair reçoit désormais un préfixe traduit, et sa route de retour pointe vers une adresse qui n'existe plus. Rien ne journalise d'erreur au moment où les deux cessent de s'accorder.

Le DNS privé relève du même endroit. Un nom qui résout vers une adresse inutilisable depuis le site concerné est une erreur de documentation assortie d'un ticket d'assistance, et on en accusera le tunnel.

Joignez l'exigence de service

Une plage protégée n'est pas une liste d'autorisations. Notez quels services doivent être joignables depuis quelle source, et qui possède l'application derrière eux. Ces deux champs répondent à des questions différentes, et les confondre est la façon dont une revue de sécurité finit par débattre du routage au lieu de l'accès.

Nommez ensuite l'administrateur réseau qui maintient la règle. Un inventaire de sélecteurs sans propriétaire vieillit en silence, et l'obsolète ne se distingue pas de l'erroné quand le tunnel tombe à deux heures du matin. Le propriétaire est aussi la personne qui peut confirmer qu'un changement était délibéré.

Transformez le registre en plan de test

Pour chaque chemin requis, choisissez un hôte source et un hôte de destination représentatifs et notez la route, le service et la passerelle de réponse attendus. Cela transforme le document en plan de test plutôt qu'en description. Relisez l'association active avec la commande ci-dessous, et comparez-la à la ligne négociée que vous avez notée.

swanctl --list-sas

Un squelette de cinq lignes suffit généralement à garder le registre honnête. La version ci-dessous tient dans un ticket de changement sans troncature :

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Un ping vers la passerelle seule n'est pas le test d'acceptation. Il n'exerce jamais le chemin de transit, il peut donc réussir alors que chaque flux transféré échoue. Testez depuis un hôte d'un côté vers un service de l'autre et confirmez que la réponse arrive par le tunnel. Si seul le ping passe, le registre vient de trouver le problème de transfert qu'il devait prévenir. documentation de transfert de strongSwan explique comment sélecteurs, routes et transfert interagissent sur un pair Linux.