VPN routé ou ponté : choisissez selon ce que le client doit atteindre

Deux tickets arrivent le même jour : un utilisateur a besoin d’une application web interne, et un ingénieur a besoin qu’un instrument de paillasse se comporte comme s’il se trouvait sur le même segment Ethernet. On répond aux deux par mettez-les sur le VPN, et c’est là que les ennuis commencent. Un tunnel routé et un tunnel ponté étendent des relations différentes, et une seule convient à chaque demande. Choisir la topologie est une décision d’accès, pas un réglage de cryptographie.

Deux demandes qui se ressemblent au guichet

Le besoin de l’employé est un service, joignable par IP, depuis un appareil que vous ne contrôlez pas. Le besoin de l’ingénieur est au niveau de la liaison : l’instrument s’attend à voir des trames Ethernet et une découverte par diffusion, et peut-être du DHCP depuis le segment où il croit se trouver.

Ce sont des questions différentes, et répondre aux deux par un pont élargit sans raison l’accès de l’employé à tout le LAN du bureau.

Écrivez le besoin sous forme de phrase avant de choisir : quelles destinations, quels protocoles et quels pairs doivent paraître locaux. Si la réponse est un hôte et un port, le routage la couvre. Si la réponse est une relation au niveau de la trame avec des appareils qui ne parlent que par diffusion, le pont est peut-être la seule option. Tout ce qui se situe entre les deux mérite un segment de test plutôt que le LAN de production.

Une route est plus étroite que l’appartenance au LAN

Un client routé reçoit une adresse sur un sous-réseau de tunnel et des routes pour les préfixes que vous choisissez. Il peut atteindre le serveur d’application et rien d’autre, si c’est ce que dit la politique. La passerelle devient le point d’application, à condition que chaque chemin pertinent la traverse.

Ne confondez pas une route avec une autorisation. Dire à un client comment atteindre un sous-réseau ne l’empêche pas d’essayer une autre destination.

Appliquez le contrôle d’accès là où il peut réellement faire respecter le flux, et conservez les permissions propres à l’application. Une règle de transfert large ou une seconde interface oubliée peuvent accorder plus que le schéma ne le suggère. Lisez les règles effectives plutôt que les règles prévues. Testez ensuite une destination qui devrait échouer, car une politique que personne n’a tenté de violer est une hypothèse.

Un pont change la question de l’admission

Le pontage combine une interface physique et un périphérique TAP en un commutateur logiciel, de sorte que les appareils distants rejoignent le même domaine de diffusion. C’est une capacité réelle et un risque réel : l’appareil distant n’est plus un invité routé, c’est un participant.

Décidez quels appareils peuvent se joindre, quels types de trames doivent traverser et où l’interaction indésirable est bloquée. L’adressage et l’autorité DHCP font partie du réseau partagé, et deux serveurs DHCP sur un même segment produisent exactement le désordre que vous attendez.

Pour l’instrument, un segment de test dédié convient généralement mieux que le LAN du bureau. Gardez l’accès de gestion hors de l’expérience, et définissez comment le participant temporaire est retiré à la fin du travail.

Le filtrage existe dans les deux topologies

Un pont n’est pas intrinsèquement non filtrable, et une route n’est pas intrinsèquement sûre. Le filtrage de pont sous Linux a ses propres points d’ancrage et sa propre syntaxe de règles, et une règle écrite pour le transfert IP routé ne s’applique pas automatiquement aux trames pontées.

Vérifiez ce que la plateforme prend réellement en charge avant de promettre une frontière :

bridge link show
nft list ruleset

TUN et TAP décrivent le trafic de l’interface, pas le chiffrement. Changer d’interface ne corrige rien de tout cela : l’authentification des pairs, une clé volée et une politique cryptographique obsolète survivent toutes au changement. Les deux extrémités ont encore besoin de réglages qui correspondent et qui sont encore pris en charge.

Prouvez la frontière par trois essais

L’acceptation, ce sont trois observations, pas une revue de schéma. L’opération requise doit fonctionner, une destination sans rapport doit échouer, et les services de gestion de la passerelle elle-même doivent rester hors de portée.

Exécutez le chemin autorisé et le chemin refusé depuis le même client, et consignez les deux :

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

Pour un pont, ajoutez les vérifications au niveau de la liaison : si le trafic de découverte autorisé passe, si l’adressage vient de l’autorité prévue et si le participant temporaire a disparu après son retrait. Quand l’IP routé simple satisfait déjà le besoin, rejoindre le segment Ethernet du bureau demande une justification distincte, et elle doit être écrite avant le changement.