VPN de site à site ou accès distant : ce que chacun relie

Les deux conceptions s’appellent VPN et résolvent des problèmes différents. Un tunnel de site à site relie deux passerelles, de sorte que chaque hôte derrière elles peut atteindre les adresses autorisées de l’autre côté sans rien installer. Un tunnel d’accès distant relie des appareils individuels à un réseau, un client à la fois. La comparaison compte parce que la plupart des erreurs de déploiement viennent du fait de configurer l’une en attendant le comportement de l’autre, et le symptôme est généralement un délai d’attente dépassé sur un service que le tunnel a bel et bien atteint.

Deux conceptions, deux frontières

Aucune des deux conceptions n’étend un domaine de diffusion LAN. Les appareils de l’autre côté n’apparaissent pas dans une liste de découverte locale, et attendre qu’ils le fassent est la première hypothèse à abandonner. Les noms DNS privés que vous publiez délibérément sont plus prévisibles que n’importe quel protocole de découverte et survivent à un changement de fournisseur.

Prenez 10.10.0.0/24 sur un site et 10.20.0.0/24 sur l’autre. La passerelle A a besoin d’une route ou d’un sélecteur de trafic qui envoie le préfixe 10.20.0.0/24 dans le tunnel, et la passerelle B a besoin de son image miroir. Les hôtes des deux côtés utilisent alors une connectivité IP ordinaire et n’apprennent jamais qu’un tunnel existe. Cette invisibilité est la fonctionnalité, et c’est aussi pourquoi les pannes ressemblent à des erreurs réseau ordinaires plutôt qu’à des erreurs de tunnel.

À base de politique et à base de route ne sont pas le même tunnel

Dans un déploiement IPsec à base de politique, les sélecteurs de trafic négociés définissent exactement quelles paires source-destination sont protégées. Si un nouveau sous-réseau apparaît derrière une passerelle et qu’aucun sélecteur ne le couvre, le tunnel reste actif et le nouveau sous-réseau n’est simplement pas transporté. Dans une conception à base de route, une interface reçoit le trafic et la table de routage décide, ce qui fait que l’ajout d’un préfixe est un changement de routage et non une renégociation du tunnel.

StrongSwan expose directement les deux vues, et les lire ensemble est le moyen de savoir quel modèle vous avez réellement déployé.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Une liste de sélecteurs qui omet le préfixe qui vous importe explique la panne sans aucune capture de paquets, et une route pointant vers la mauvaise interface explique la panne miroir au retour. Lisez les deux avant de renégocier quoi que ce soit, car un renouvellement de clé n’ajoutera pas un sélecteur que vous n’avez jamais configuré.

Planifiez l’adressage avant le tunnel

Les plages qui se chevauchent sont l’erreur de conception qu’aucune configuration ne corrige. Si les deux sites utilisent 192.168.1.0/24, un hôte qui a besoin de 192.168.1.50 a deux candidats et aucun moyen de choisir. Le tunnel s’authentifiera, les associations de sécurité s’établiront, et la décision de routage sera malgré tout erronée ou ambiguë.

Choisissez l’une de trois options honnêtes : renuméroter un site, traduire la plage qui se chevauche au niveau de la passerelle pour que chaque côté voie un préfixe distinct, ou renoncer au routage direct pour ces hôtes et publier le service autrement. Chacune a un coût, et la première est généralement la moins chère sur un horizon de deux ans. Décidez avant que le tunnel existe, car ensuite le changement touche chaque appareil qui possède l’ancienne adresse.

Réglez aussi la question du MTU tôt. Un tunnel réduit la charge utile, et une conception qui repose sur la fragmentation se comporte différemment d’une qui fixe le MSS aux passerelles.

Le transfert et la politique se situent hors du tunnel

La passerelle doit accepter de transférer des paquets entre l’interface du tunnel et l’interface LAN, et les deux directions ont besoin d’une politique qui autorise le service. Sous Linux, ce sont deux réglages distincts, plus les règles de pare-feu qui décident si le flux transféré est autorisé tout court.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

L’hôte récepteur ajoute une troisième couche : son propre pare-feu doit encore accepter un client du sous-réseau distant. Un serveur de fichiers qui n’autorise que son /24 local rejettera le trafic transféré depuis 10.20.0.7, aussi sain que le tunnel paraisse, et ce rejet se lit facilement comme une panne de routage.

Testez depuis un hôte, pas depuis la passerelle

Un ping émis par la passerelle elle-même peut suivre une adresse source et une politique différentes de celles du trafic utilisateur transféré. Cela en fait un test faible et, parfois, trompeur : il réussit alors que l’application échoue, ou échoue alors que l’application fonctionne.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Utilisez un hôte réel, une adresse source réelle et le protocole réel qu’utilise l’application. Lisez ensuite le chemin de retour séparément, car une direction aller qui fonctionne sans route retour produit un délai d’attente dépassé identique à celui d’un service bloqué.

Choisissez la conception selon la question à laquelle vous répondez : reliez-vous des réseaux ou admettez-vous des appareils ? Tout le reste, y compris le fournisseur que vous configurez, découle de cette réponse.