Pourquoi un VPN TAP partagé a toujours besoin de HTTPS sur le portail

Deux appareils détiennent des identifiants VPN valides et partagent un seul segment Ethernet ponté. Un seul d’entre eux est censé répondre du portail du bureau, et l’autre peut encore revendiquer l’adresse du portail sur ce segment. Le tunnel a fait son travail : il a authentifié les deux pairs et chiffré chaque chemin vers le serveur. Ce qu’il n’a pas fait, c’est certifier lequel des deux possède un nom de service, et c’est cette lacune qui explique pourquoi le portail a toujours besoin d’un certificat valide.

Ce que le VPN authentifie réellement

Une poignée de main VPN répond à une question : quel pair a terminé ce tunnel, et avec quel matériel de clé. Cette réponse vaut par pair et par connexion, et elle ne dit rien des services que ce pair expose ensuite. Sur un segment TAP, le pair n’est même pas une seule adresse, car il peut présenter n’importe quelle MAC et n’importe quelle IP que le pont est prêt à apprendre. L’authentification s’arrête au point de terminaison du tunnel, pas à l’application.

Séparez les trois questions au lieu de les fusionner en une. Chacune a son propre mécanisme et son propre mode de défaillance.

Un déploiement peut avoir un tunnel parfaitement authentifié et un service totalement non authentifié derrière. Il peut aussi avoir un certificat validé sur un hôte dont l’adresse de couche deux est revendiquée par un autre pair, et c’est pourquoi les deux contrôles appartiennent à la conception plutôt que de se remplacer l’un l’autre. Le tableau est tout l’argument en trois lignes.

ARP sur un segment partagé n’est pas un annuaire

ARP associe une adresse IPv4 à une MAC sur le lien local et accepte les réponses de n’importe qui sur ce lien. Sur un segment ponté permissif, un pair peut revendiquer une adresse qui appartient à un autre appareil, et le pont transmet les trames à celui qui a répondu le plus récemment. Chiffrer chaque chemin client vers le serveur n’y change rien, car les trames sont déchiffrées avant d’atteindre le pont. La frontière de confiance d’ARP est le segment, pas le tunnel.

Regardez ce que l’hôte a réellement appris : ip neigh show liste les correspondances actuelles et leur état, et une entrée qui bascule entre deux adresses MAC en fonctionnement normal est un symptôme qui mérite une enquête plutôt qu’un rejet. Sur un petit segment sain, ces entrées restent stables longtemps.

L’isolement des pairs et la politique du pont existent exactement pour ce cas. Une conception routée est généralement la meilleure réponse lorsque le service est uniquement IP et que les appareils n’ont aucune raison de voir les trames des autres.

Gardez la validation du certificat là où se trouve le service

Le TLS de l’application répond à la question que le tunnel ne peut pas trancher : est-ce le service que je voulais atteindre ? Le navigateur vérifie le nom d’hôte par rapport au certificat, et cette vérification est la seule partie de la chaîne qui nomme le portail plutôt que le pair.

Examinez ce que le serveur présente avant de décider que l’avertissement est cosmétique. openssl s_client -connect portal.example.internal:443 -servername portal.example.internal imprime la chaîne et les noms alternatifs du sujet. Si le nom que vous avez saisi est absent de cette liste, l’avertissement est correct et c’est le certificat qu’il faut corriger. Apprendre aux utilisateurs à le contourner transforme un contrôle fonctionnel en décoration.

Le guide de pontage d’OpenVPN décrit le modèle Ethernet et les options de politique qui l’entourent, et c’est la bonne référence pour ce que le segment est censé autoriser. Lisez-le avant d’assouplir une règle de pont, car le modèle qu’il décrit est ce que chaque vérification ci-dessus suppose.

Décidez si ces pairs doivent partager un segment

Le correctif le moins coûteux consiste généralement à cesser de partager la couche deux lorsque l’exigence n’est que l’accessibilité IP. Un VPN routé donne à chaque client sa propre adresse, supprime le domaine de diffusion partagé et transforme le trafic entre pairs en décision de politique plutôt qu’en valeur par défaut. Le portail a alors une adresse à protéger et aucun voisin qui puisse la revendiquer.

Si le segment doit rester, vérifiez le réglage côté serveur qui permet aux clients de s’atteindre : grep -n client-to-client /etc/openvpn/server.conf. Lorsqu’il est désactivé, le trafic des clients passe par le serveur et peut y être filtré. Lorsqu’il est activé, les pairs échangent des trames directement via le pont, et vos points de filtrage sont le pont et le pare-feu de l’hôte.

Notez les protections sur lesquelles chaque hôte s’appuie réellement : authentification du tunnel, isolement du segment ou TLS de l’application. Un hôte qui dépend des trois va bien. Un hôte qui dépend de la première et suppose que les deux autres sont venues avec elle est celui qui finit par servir le mauvais contenu.