WireGuard et les Allowed IPs
Les Allowed IPs sont un élément essentiel de la configuration d'un tunnel VPN avec WireGuard.
Ce paramètre est nécessaire pour chacun des pairs et joue un double rôle, en entrée et en sortie pour les paquets qui transitent par le tunnel.
WireGuard fonctionne comme une interface réseau (ex: wg0), et pour lui :
📤 Un paquet sortant est un paquet qui passe par l’interface WireGuard pour être chiffré et envoyé à un pair distant.
📥 Un paquet entrant est un paquet chiffré reçu, qui est déchiffré, puis injecté dans l’interface (et donc dans le système).
Les Allowed IPs jouent donc un double rôle dans WireGuard :
🎯 Routage des paquets sortants (de notre système) : on regarde la destination des paquets pour savoir si le peer est approprié ; donc l'adresse de destination doit être contenue dans les IP autorisées. S'il y a plusieurs peers dans l'interface cela peut permettre de choisir le bon.
🚦 Filtrage des paquets entrants (dans notre système) : on regarde si le paquet qui arrive dans l'interface est autorisé, au sens de sa provenance. Si ce paquet est autorisé alors on peut le décrypter et lui faire poursuivre sa route. Sinon il est rejeté.
On analyse toujours l’IP de destination pour le trafic sortant, et l’IP source pour le trafic entrant. Les deux sont comparées à la même liste de Allowed IPs, mais avec des usages différents selon le sens du paquet.
Documentation traduite
Dans la configuration du serveur, chaque pair (un client) pourra envoyer des paquets vers l’interface réseau avec une adresse IP source correspondant à sa liste d’IP autorisées. Par exemple, lorsqu’un paquet est reçu par le serveur en provenance du pair gN65BkIK..., après avoir été déchiffré et authentifié, si son IP source est 10.10.10.230, alors il est autorisé à accéder à l’interface ; sinon, il est rejeté.
Dans la configuration du serveur, lorsque l’interface réseau souhaite envoyer un paquet à un pair (un client), elle examine l’adresse IP de destination de ce paquet et la compare avec les listes d’IP autorisées de chaque pair afin de déterminer à quel pair l’envoyer. Par exemple, si l’interface réseau doit envoyer un paquet à l’IP de destination 10.10.10.230, elle va l’encrypter avec la clé publique du pair gN65BkIK..., puis l’envoyer au dernier point de connexion Internet connu de ce pair.
Dans la configuration du client, son unique pair (le serveur) pourra envoyer des paquets vers l’interface réseau avec n’importe quelle adresse IP source (car 0.0.0.0/0 est un joker). Par exemple, lorsqu’un paquet est reçu du pair HIgo9xNz..., s’il est correctement déchiffré et authentifié, peu importe l’adresse IP source, il est autorisé à passer par l’interface ; sinon, il est rejeté.
Dans la configuration du client, lorsque l’interface réseau souhaite envoyer un paquet à son unique pair (le serveur), elle chiffrera les paquets pour ce pair unique avec n’importe quelle adresse IP de destination (puisque 0.0.0.0/0 est un joker). Par exemple, si l’interface réseau doit envoyer un paquet avec n’importe quelle IP de destination, elle l’encryptera avec la clé publique de son unique pair HIgo9xNz..., puis l’enverra au dernier point de connexion Internet connu de ce pair.
En d'autres termes, lors de l’envoi de paquets, la liste des IP autorisées fonctionne comme une sorte de table de routage, et lors de la réception de paquets, elle agit comme une sorte de liste de contrôle d’accès.
C’est ce que l’on appelle une table de routage cryptographique (Cryptokey Routing Table) : l’association simple entre des clés publiques et des adresses IP autorisées.
Toute combinaison d’adresses IPv4 et IPv6 peut être utilisée pour n’importe lequel des champs. WireGuard est entièrement capable d’encapsuler l’un dans l’autre si nécessaire.
Comme tous les paquets envoyés sur l’interface WireGuard sont chiffrés et authentifiés, et qu’il existe un lien étroit entre l’identité d’un pair et l’adresse IP autorisée de ce pair, les administrateurs système n’ont pas besoin d’extensions de pare-feu complexes, comme c’est le cas avec IPsec. Ils peuvent simplement faire correspondre "est-ce que ça vient de cette IP ? sur cette interface ?", et être assurés qu’il s’agit d’un paquet sécurisé et authentique. Cela simplifie grandement la gestion du réseau et le contrôle d’accès, tout en offrant une bien plus grande certitude que vos règles iptables fonctionnent comme prévu.
https://www.wireguard.com/#cryptokey-routing
Point d'attention : masquerading
Quand il y a un masquerade avant d’entrer dans le tunnel, l’adresse d’origine visible à la sortie du tunnel (côté serveur) est celle après NAT, pas l’originale.
Et donc, c’est cette IP post-NAT (par exemple 10.0.0.2) qui doit figurer dans les Allowed IPs sur le serveur. WireGuard ne verra jamais l’IP originale (192.168.1.10), donc il ne peut pas l’utiliser pour filtrer.