Groupes de pairs WireGuard au concentrateur : propriété de la source et politique

Un concentrateur qui exécute WireGuard peut garder les groupes de pairs séparés sans interface ni table de routage distincte par groupe. Deux mécanismes font le travail, et les confondre est la raison habituelle pour laquelle une politique paraît correcte et ne fait rien. Une couche décide qui peut revendiquer une adresse source. L'autre décide où ce paquet est autorisé à aller.

Deux tâches, tenues à part

La couche tunnel répond à une question étroite : la clé de ce pair a-t-elle autorisé cette adresse source interne. La couche de transfert répond à une question plus large : ce paquet peut-il sortir vers cette destination. Ni l'une ni l'autre ne répond à la question de l'autre, et aucune n'est à elle seule une politique d'accès complète.

Cette séparation explique qu'un pair puisse être authentifié, correctement adressé et néanmoins incapable d'atteindre un hôte qu'il ne devrait pas atteindre. Elle explique aussi l'inverse : une règle de pare-feu qui autorise tout ne prouve rien sur qui peut revendiquer quelle adresse.

Concevez les deux couches ensemble, puis testez les deux. Une configuration correcte sur une couche et non testée sur l'autre échoue ouverte ou fermée selon la valeur par défaut.

N'accordez à chaque pair que sa propre adresse

Les pairs multi-hôtes vous incitent à accorder toute la plage du groupe côté serveur. Cette autorisation est une revendication d'adresse source, si bien qu'un client compromis ou mal configuré peut présenter n'importe quelle adresse de la plage et le tunnel l'acceptera. Attribuez un /32 par pair pour sa propre adresse interne. Ne définissez les plages de groupe que sur les clients, où elles décrivent quelles destinations ce client peut atteindre plutôt que quelles sources il peut utiliser.

Le pare-feu compare alors une source à laquelle il peut se fier. Une règle écrite pour la plage du groupe reste un regroupement utile, et elle ne devient significative que lorsque aucun pair isolé ne peut revendiquer une adresse appartenant à un autre membre.

Écrivez la politique de transfert qui sépare les groupes

Le trafic intéressant entre et sort ici par la même interface de tunnel, il traverse donc le chemin de transfert et non le chemin d'entrée de l'hôte. Les règles appartiennent à la chaîne de transfert existante du gestionnaire de pare-feu qui possède l'hôte, et ce sont des fragments, pas un jeu de règles complet.

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

Les deux premières règles autorisent le trafic au sein de chaque groupe. La dernière bloque tout le reste qui traverse cette interface, et c'est ce qui produit l'isolation entre les groupes. Ajoutez des règles explicites pour l'autre famille d'adresses si vous en avez besoin, car un rejet écrit pour IPv4 n'autorise ni ne décrit le comportement d'IPv6.

L'ordre décide si la politique s'applique

L'ordre des règles compte plus que le fragment lui-même. Une règle générique qui accepte les connexions établies et placée avant ces entrées laisse un ancien flux inter-groupes continuer, si bien que l'isolation ne s'applique qu'aux nouvelles connexions. Décidez lequel de ces deux résultats vous voulez avant de recharger.

Un verdict d'acceptation n'est pas non plus toujours définitif entre chaînes sur le même point d'ancrage. Si une autre chaîne de base s'exécute plus tard, la politique effective est la combinaison, donc inspectez les compteurs plutôt que le fichier que vous avez modifié. Les compteurs sont la preuve la moins chère disponible. Une règle sans comptage de paquets ne correspond pas, et une règle qui correspond alors qu'une chaîne ultérieure accepte vous indique que le rejet est au mauvais endroit.

Testez la matrice, pas le nombre de fichiers

Construisez une petite matrice de résultats attendus et vérifiez chaque cellule. Du groupe A au groupe A devrait fonctionner, du groupe B au groupe B devrait fonctionner, et de A à B ne devrait pas, dans les deux sens et pour les deux familles d'adresses si vous les prenez en charge.

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

Les deux premières montrent ce qui est configuré. Le ping depuis un membre du mauvais groupe montre ce qui se passe réellement. La liste conntrack montre si un flux plus ancien est encore accepté, et c'est ainsi qu'un changement d'isolation échoue silencieusement à prendre effet.

Les services hôtes sur le concentrateur et l'accès à un LAN derrière lui sont des chemins distincts avec une politique distincte. Notez lesquels la matrice couvre, car un test qui ne vérifie que le trafic entre pairs ne dit rien de l'un ni de l'autre.