TAP sans pont : un segment virtuel avec un lien montant routé

TAP remet les trames Ethernet au système d’exploitation, ce qui est plus de capacité que la plupart des conceptions d’accès distant n’en ont besoin et moins qu’un pont. Le noyau peut l’adresser, router à travers lui et le protéger par un pare-feu sans le rattacher à un segment physique. Cette disposition vaut la peine d’être comprise d’abord : un segment Ethernet virtuel isolé dont le serveur agit comme routeur vers un LAN réel. Il offre un comportement de deuxième couche à l’intérieur du tunnel et un transfert IP ordinaire à l’extérieur, qui sont deux promesses différentes. Le reste est la construction, la route, le chemin de retour et le retour arrière.

Construire le segment isolé

Sous Linux, l’interface prend trois commandes : la créer, la monter, lui donner une adresse à l’intérieur du segment que vous visez. Choisissez un préfixe qui n’entre pas en collision avec le LAN du bureau et notez-le, car la collision est invisible jusqu’à ce qu’un hôte qui ne devrait pas exister réponde.

ip tuntap add dev tap0 mode tap
ip link set tap0 up
ip addr add 10.77.0.1/24 dev tap0

Rien ici n’exige un pont, et rien n’empêche d’en ajouter un plus tard. La documentation du noyau sur TUN/TAP décrit l’interface elle-même ; l’appartenance au pont et la politique de transfert sont des décisions distinctes que vous prenez ensuite.

Router au-delà de la frontière

Activez le transfert, autorisez les deux préfixes dans la chaîne de transfert, et ajoutez une route vers le préfixe du bureau avec le routeur du LAN comme saut suivant. Le côté VPN envoie alors le trafic vers le bureau au serveur comme sa passerelle, et le serveur transfère ces paquets en tant que lui-même, pas en tant que pont. Une interface TAP avec le transfert désactivé est un segment qui répond localement et n’atteint rien au-delà, ce qui est l’état habituel à moitié terminé. Vérifiez ensuite les compteurs de l’interface des deux côtés, car un compteur de réception qui monte avec un compteur d’émission plat côté LAN signifie une chute dans la chaîne de transfert, pas une mauvaise route.

Écrivez la route et la règle de pare-feu comme un seul changement, car chacune seule produit un état qui, du côté du client, ressemble à une panne de routage.

Décider le chemin de retour

Soit le routeur du LAN apprend une route de retour vers le préfixe VPN, soit le serveur traduit les adresses source en sortie. La traduction rend le chemin de retour trivial et détruit l’identité de la source, donc les journaux de destination afficheront l’adresse du serveur pour chaque client derrière lui. Un préfixe routé conserve l’identité et exige un changement sur un équipement que vous ne gérez peut-être pas.

Choisissez délibérément plutôt qu’en fonction de ce qui est plus rapide à taper. Un seul préfixe routé est généralement plus propre que la traduction, et la traduction est généralement meilleure que d’apprendre un nouveau préfixe à un routeur non géré pour un seul laboratoire.

Garder la portée de diffusion délibérée

À l’intérieur du segment virtuel, DHCP, la découverte et l’annonce de voisins se comportent comme sur un commutateur, car c’est un seul lien. Au-delà de la frontière routée, ils ne le font pas, donc le DHCP du bureau et la découverte de services ont besoin d’une conception explicite plutôt que de l’hypothèse que TAP les implique. Le type d’interface n’est pas un relais pour des services qui vivent ailleurs.

C’est la raison honnête de choisir TAP : quelque chose sur le segment virtuel a besoin d’un comportement local au lien. Si rien n’en a besoin, un périphérique TUN avec un préfixe routé est plus petit, et il y a moins à expliquer quand il tombe en panne.

Vérifier, puis écrire le retour arrière

Depuis un client VPN, envoyez un ping au routeur du LAN, un ping à un hôte, et ouvrez un service qui compte sur TCP. Vérifiez ensuite les compteurs et la chaîne de transfert, car une chute due à une politique ressemble de loin exactement à une route manquante. Le retour arrière est l’inverse de la construction et appartient au registre des changements avant de commencer : retirez la route, retirez l’adresse, supprimez l’interface.

Si l’exigence est vraiment un segment Ethernet couvrant deux sites, un pont est la réponse honnête et une conception différente avec un rayon d’impact différent. Si l’exigence est l’accessibilité, le segment isolé avec un lien montant routé fait le travail avec moins d’explications plus tard.