EoIP sur une liaison VPN LTE : monter un petit laboratoire RouterOS

EoIP prend une trame Ethernet complète, l'enveloppe dans GRE et l'envoie vers une adresse distante configurée, ce qui explique que le résultat se comporte comme un câble et non comme une route. Ce qui quitte le routeur est le protocole IP 47 avec la trame d'origine en charge utile, si bien que les diffusions, ARP et les protocoles non IP passent tous. GRE n'ajoute aucune confidentialité propre, et la trame reste lisible pour tout ce qui voit le paquet extérieur. Ce seul fait décide de l'ordre de ce laboratoire : construisez d'abord le chemin chiffré, puis transportez Ethernet à l'intérieur.

Ce qu'EoIP enveloppe, et ce qu'il n'enveloppe pas

L'encapsulation est tout le mécanisme. Une trame arrive sur un port ponté, reçoit un en-tête GRE et un en-tête IP extérieur, et est livrée au routeur pair, qui retire les deux et injecte la trame dans son propre pont. Le pont récepteur apprend la MAC source exactement comme depuis un port local. Rien dans ce processus n'authentifie la trame ni ne la cache.

La confidentialité doit donc venir du chemin que parcourt le paquet GRE. Dans ce montage, la couche inférieure est un tunnel WireGuard ou IPsec entre les deux routeurs, et EoIP est transporté à l'intérieur. MikroTik expose aussi une option IPsec automatique sur l'interface EoIP elle-même, ce qui est une autre disposition et non ce que configure ce laboratoire.

Pour des services IP routés, un VPN routé est le montage le plus petit et celui à préférer. Ne recourez à la couche deux que lorsqu'un appareil a réellement besoin de voir les trames Ethernet de l'autre site.

Prérequis : une couche inférieure chiffrée et deux ports inutilisés

Les deux routeurs ont besoin d'une liaison chiffrée établie et d'une adresse dessus que le pair peut joindre. Le côté LTE initie la connexion extérieure, donc le concentrateur n'appelle jamais le réseau mobile, et le routeur LTE maintient l'état NAT que l'opérateur exige. Vérifiez que le tunnel est actif avant d'ajouter quoi que ce soit dessus, car une interface EoIP qui n'atteint pas son adresse distante ressemble à s'y méprendre à une interface mal configurée.

Chaque routeur a aussi besoin d'un port qui n'est pas déjà membre d'un pont, un trunk VLAN, une interface de gestion ou une liaison de production. Un laboratoire qui emprunte un port en service n'est pas un laboratoire, et le mode de défaillance est une tempête de diffusion sur un réseau en production. Déplacez l'administration vers une autre interface ou vers la console avant de commencer.

Hub tunnel address:    10.44.7.1/32
LTE tunnel address:    10.44.7.2/32
Lab ports:             ether7 on both routers, unused
Test hosts:            192.168.77.11/24 and 192.168.77.12/24

Ces valeurs sont un exemple et non une obligation. Elles doivent se trouver sur les interfaces du tunnel et être routées par le chemin protégé. La politique de pare-feu des deux routeurs doit autoriser GRE entre les deux adresses du tunnel, et GRE est le protocole IP 47, pas un port TCP ou UDP portant le numéro 47. Ce montage n'expose jamais GRE brut à l'un ou l'autre des WAN.

Créez la paire de tunnels avec des ID identiques

Les deux extrémités sont une seule interface logique définie deux fois, donc chaque champ identifiant doit concorder. Sur le concentrateur :

/interface eoip add name=eoip-lab local-address=10.44.7.1 remote-address=10.44.7.2 tunnel-id=37 mac-address=02:1A:2B:00:00:01

Sur le routeur LTE, les adresses s'inversent et la MAC diffère :

/interface eoip add name=eoip-lab local-address=10.44.7.2 remote-address=10.44.7.1 tunnel-id=37 mac-address=02:1A:2B:00:00:02

L'ID du tunnel doit concorder aux deux extrémités et ne doit pas entrer en collision avec une autre paire déjà configurée sur l'un ou l'autre routeur. Les adresses MAC sont des valeurs administrées localement qui doivent être uniques dans le domaine de couche deux auquel vous vous rattachez, donc ne réutilisez pas une valeur d'un exemple de constructeur. Les noms d'interface sont locaux à chaque routeur et ne doivent être cohérents que pour vos propres scripts.

Le manuel EoIP actuel documente les champs de point d'extrémité et d'ID de tunnel, et dit clairement qu'EoIP est de l'Ethernet sur GRE. Rien dans cette commande ne chiffre quoi que ce soit, c'est pourquoi la vérification de la couche inférieure vient en premier.

Ne pontez que les ports de test

Un pont est ce qui transforme le tunnel en segment, et sa composition est toute la frontière de sécurité. Sur le concentrateur :

/interface bridge add name=br-eoiphub protocol-mode=rstp auto-mac=no admin-mac=02:1A:2B:00:01:01
/interface bridge port add bridge=br-eoiphub interface=ether7
/interface bridge port add bridge=br-eoiphub interface=eoip-lab

Sur le routeur LTE :

/interface bridge add name=br-eoiplte protocol-mode=rstp auto-mac=no admin-mac=02:1A:2B:00:01:02
/interface bridge port add bridge=br-eoiplte interface=ether7
/interface bridge port add bridge=br-eoiplte interface=eoip-lab

Ces commandes créent de nouveaux ponts et ajoutent exactement deux ports à chacun. L'interface EoIP est le membre de couche deux ; le tunnel chiffré reste un transport routé et ne doit jamais être ajouté comme port de pont. N'ajoutez pas de port de production et ne lancez pas de serveur DHCP sur le pont du laboratoire.

Donnez aux deux hôtes de test des adresses dans un sous-réseau inutilisé et sans serveur DHCP concurrent, par exemple 192.168.77.11/24 et 192.168.77.12/24. Ils n'ont pas besoin de passerelle par défaut pour s'atteindre dans ce sous-réseau, et une adresse d'interface de routeur n'est pas nécessaire pour que les trames traversent.

Budgetez la surcharge avant d'étendre un LAN

EoIP sur IPv4 ajoute des en-têtes Ethernet, GRE et IP extérieur autour de la charge transportée. Pour le cas non étiqueté, MikroTik documente 42 octets, donc une couche inférieure avec 1400 octets de MTU IP utilisable laisse 1358 octets pour la trame interne. Ce chiffre est un budget et non une valeur MSS universelle, et il ne force pas un hôte ponté à émettre des trames plus petites.

Vérifiez les limites réelles sur le chemin, puis testez avec la plus grande trame que l'appareil envoie vraiment. Une trame de 1500 octets qui doit être fragmentée dans le chemin protégé se comporte différemment de celle qui tient, et la différence se manifeste comme un blocage applicatif et non comme une panne de lien.

/interface eoip print detail where name=eoip-lab
/interface bridge host print where bridge=br-eoiphub
/ping 192.168.77.12 count=4 interface=br-eoiphub

RSTP gère les boucles, pas les chemins parallèles arbitraires, gardez donc la topologie pilote simple. Étendre un pont étend aussi le comportement de diffusion, de multicast et de DHCP sur la liaison mobile, et ce trafic consomme de la capacité, qu'une trame utile circule ou non.

Ne planifiez un raccordement de production qu'une fois que le laboratoire atteint la taille de trame et le comportement applicatif dont vous avez réellement besoin. Avant ce basculement, convenez de l'adressage, de l'appartenance VLAN, de l'autorité DHCP, de la prévention des boucles et de la manière dont quelqu'un joint les routeurs lorsque la liaison elle-même est coupée. Une extension Ethernet relie des domaines de panne autant que des appareils, elle mérite donc une fenêtre de changement plutôt qu'un port de plus sur un pont en service.