Une NIC ou deux ? Comment choisir la disposition des interfaces d'un serveur VPN

Un seul adaptateur physique suffit pour beaucoup de serveurs VPN, et ce n'est pas non plus une conception universelle. La connexion chiffrée arrive sur cet adaptateur, le processus VPN la déchiffre, et le trafic intérieur sort par une interface virtuelle avant d'atteindre un service local ou un LAN routé. Que cela fonctionne dépend de trois conditions : où se trouve la destination, si le LAN dispose d'un chemin de retour vers le pool de clients et si un lien physique partagé vous donne l'isolation que vous revendiquez. Répondez à ces trois et le nombre d'adaptateurs suit.

Les trois conditions qui le décident

La première condition est la destination. Un service sur l'hôte VPN lui-même n'est atteint que par l'interface du tunnel, alors qu'un hôte sur le LAN exige du transfert et un chemin de retour. La deuxième condition est ce chemin de retour, car l'équipement du LAN doit savoir comment joindre le pool de clients, soit par une route, soit par traduction sur le serveur.

La troisième condition est la séparation. Un adaptateur signifie que chaque paquet, chiffré ou non, partage un lien et généralement une chaîne de politiques, donc une revendication d'isolation qui dépend d'un matériel séparé n'est pas satisfaite par une seule interface. C'est un fait sur le chemin, pas sur la configuration du système d'exploitation. Vous pouvez toujours filtrer le trafic du tunnel, mais pas revendiquer une frontière que vous n'avez pas.

Aucune des trois ne porte sur le nombre de ports du châssis. Elles portent sur le routage, la propriété des adresses et la mesure dans laquelle la conception dépend d'une séparation physique.

Deux adaptateurs restent un choix légitime lorsque des zones physiques, des liens montants distincts, du débit ou un chemin de récupération hors bande le justifient. Ce sont des exigences concrètes, et elles valent d'être énoncées avant que quiconque commande du matériel.

Quand le service tourne sur l'hôte VPN

Le cas le plus simple ne nécessite aucun transfert. Le démon reçoit les paquets du client sur l'interface du tunnel et les remet à une socket locale, et la réponse repart par la même interface. L'adresse du pool de clients est une véritable adresse locale du point de vue de l'hôte.

Deux choses doivent néanmoins être correctes : le service doit écouter sur une adresse que le tunnel peut atteindre, et le pare-feu de l'hôte doit accepter le trafic arrivant sur l'interface du tunnel. Les deux sont visibles dans les commandes ci-dessous.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Lier un service à la seule adresse publique, ou filtrer l'interface du tunnel par erreur, produit une connexion qui atteint l'hôte puis meurt. Cela ressemble à une panne de VPN et c'est généralement une décision de socket ou de pare-feu.

Quand la destination se trouve sur le LAN

C'est ici qu'une conception à un seul adaptateur gagne sa réputation de délicate. Le serveur doit transférer les paquets du client vers le LAN, et l'équipement du LAN doit renvoyer les réponses vers le pool de clients. Soit vous portez ce pool comme une route sur le LAN, soit vous traduisez l'adresse source sur le serveur pour que les réponses reviennent au serveur lui-même.

Les deux réponses sont légitimes et elles échouent différemment. Une route de retour garde l'adresse d'origine du client visible pour la destination, ce qui est bon pour les journaux et mauvais pour les règles de pare-feu qui supposent des adresses du LAN. La traduction garde le LAN simple et cache l'identité du client à la destination.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Un chemin asymétrique est le symptôme classique : la requête du client arrive, la réponse part par un autre routeur et la connexion expire sans erreur à l'une ou l'autre extrémité. Capturez des deux côtés avant de conclure quoi que ce soit sur le tunnel.

Pourquoi un alias ne crée pas une seconde zone

Ajouter une seconde adresse au même adaptateur, ou créer une interface factice pour imiter un second port, ne change presque rien. Les paquets sortent toujours par le même lien physique, le même port de commutateur et généralement la même chaîne de pare-feu, donc aucune nouvelle frontière n'existe entre eux. C'est une commodité de configuration, pas une segmentation. La traiter comme une frontière de zone, c'est ainsi qu'une revendication d'isolation ne survit que sur le papier.

Une zone séparée exige une vraie séparation dans le chemin, et c'est l'exigence qu'un second adaptateur satisfait. Si une règle dépend du fait que le trafic orienté VPN ne partage jamais un domaine de diffusion avec le trafic orienté LAN, un seul câble ne peut pas offrir cette propriété, quelle que soit l'adressage de l'hôte.

Lorsqu'un produit documente une topologie multi-interface pour un mode donné, suivez la documentation de ce produit au lieu d'inventer un contournement. Les fournisseurs changent aussi leurs topologies prises en charge d'une version à l'autre, autre raison de lire le guide actuel plutôt qu'une ancienne capture de l'assistant.

Vérifiez la disposition par rapport au trafic que vous autorisez

Listez les classes de trafic que le serveur doit porter : client vers hôte, client vers LAN, hôte vers LAN et la connexion extérieure chiffrée. Chaque classe a une source, une destination et une interface, et la disposition doit satisfaire les quatre à la fois. Une conception qui en traite trois est généralement celle qui génère des tickets.

Confirmez ensuite les interfaces réelles et la capture réelle, plutôt que le schéma du document de conception. Les commandes ci-dessous impriment les deux vues.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Si la capture extérieure montre le trafic chiffré et que la capture intérieure montre le trafic déchiffré sur l'interface du tunnel tandis que l'adaptateur physique porte les deux, une seule NIC fait le travail. Si la capture intérieure est vide, le problème est dans le tunnel ou dans les règles de transfert, pas dans le nombre d'adaptateurs. Décidez la topologie à partir de ces deux captures et de la table de routage, et le prochain changement aura de quoi être mesuré.