Deux groupes de clients, un serveur : où appliquer la politique

Mettre deux groupes de clients sur des sous-réseaux différents ressemble à de l’isolation, et ce n’en est pas. Les adresses décrivent d’où un paquet semble venir, alors que la permission est une décision prise par ce qui le transfère. Cette question trouve sa réponse dans la configuration et non dans le masque, alors décidez quel composant transfère le trafic entre pairs avant d’écrire la moindre règle.

Un sous-réseau est une étiquette, pas une règle

Affecter un pool par groupe vous donne des adresses lisibles et rien d’autre. Un client qui accepte une route supplémentaire a gagné en joignabilité, et la joignabilité n’est pas une autorisation. La permission de parler réside dans la décision de transfert, qui peut vivre dans le démon ou dans le noyau selon la configuration du serveur.

La propriété de l’adresse est ce qui rend un préfixe utilisable comme sélecteur de groupe. Chaque identité authentifiée doit correspondre à une adresse ou à une plage prévisible, et ce mappage échoue dès que plusieurs appareils partagent un identifiant et une affectation. Réglez l’identité et la concurrence avant de vous fier à un préfixe source, car une politique qui devine quelle machine appelle autorise la mauvaise au pire moment.

Choisissez le chemin qui porte le trafic entre pairs

Lorsque le démon transfère les paquets entre pairs dans son propre processus, ces paquets n’atteignent jamais le crochet de transfert de l’hôte, si bien qu’une règle du noyau ne peut pas les voir. Désactivez ce transfert interne et le noyau devient le point de transfert, où les règles de transfert ordinaires s’appliquent.

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

Les canaux de données déchargés et les serveurs gérés par le produit publient leurs propres modèles d’application, alors confirmez lequel vous exploitez plutôt que de supposer le comportement de la communauté. La panne qu’il vaut la peine d’éviter est une règle qui semble correcte en revue et n’est jamais consultée à l’exécution.

Écrivez la matrice avant d’écrire les règles

Une matrice courte est plus facile à relire qu’un jeu de règles, et c’est le contrat que la mise en œuvre doit satisfaire : pairs du même groupe autorisés, pairs entre groupes refusés, les deux groupes autorisés vers un service partagé nommé, tout le reste refusé. Écrivez ces quatre lignes avant d’ouvrir un éditeur de pare-feu. Un relecteur qui ne lit pas la syntaxe des règles peut tout de même vérifier la matrice. La mise en œuvre n’a plus qu’à correspondre aux lignes.

Gardez les trois classes de destination séparées pendant que vous l’écrivez. Un service sur l’hôte VPN est une entrée locale, un autre client est un transit entre pairs, et une machine derrière la passerelle est un autre chemin de transfert. Une seule règle généreuse peut accorder les trois par accident, et c’est ainsi qu’une politique de groupe devient un réseau plat avec des étapes en plus. Écrivez la classe à côté de chaque ligne pour que l’intention survive à la prochaine modification.

Placez les règles là où elles survivent

Ajoutez les décisions au même endroit où le reste du pare-feu est maintenu, avant toute règle permissive qui les avalerait sinon. L’ordre des règles fait partie de la politique, et une règle correcte placée après une acceptation large n’applique rien du tout. Notez les numéros de règle avant et après la modification. Une politique qui existe dans un éditeur mais pas dans le jeu de règles en cours est un plan, pas un contrôle.

Décidez ce qu’il advient des flux déjà existants lorsque la politique change, car une session ouverte avant le changement peut continuer après. Si un membre parti doit perdre l’accès immédiatement, le jeu de règles a besoin d’un moyen de terminer cet état plutôt que d’attendre que la connexion se ferme d’elle-même.

Rendez les règles persistantes via le mécanisme qui possède le reste du pare-feu, et consignez la matrice à côté. Une politique non consignée est redérivée de mémoire lors du prochain incident, généralement par quelqu’un pressé.

Prouvez-le des deux côtés

Testez la joignabilité au sein d’un même groupe, l’échec entre groupes et le service partagé depuis un client de chaque groupe. Un seul test depuis un seul client prouve la moitié de la matrice, et la moitié qu’il laisse de côté est généralement celle qui est fausse. Répétez le sens de refus deux fois, car une session en cache peut masquer une erreur d’application. Consignez la paire testée pour que la personne suivante ne la répète pas.

Répétez le contrôle sur IPv6 si le tunnel le transporte, et maintenez l’authentification applicative ordinaire. Un préfixe source n’est pas un compte, donc passer la politique réseau ne signifie pas qu’un service doive faire confiance à l’appelant.