EoIP over een LTE-VPN-link: een klein RouterOS-lab bouwen

EoIP neemt een compleet Ethernet-frame, wikkelt het in GRE en stuurt het naar een geconfigureerd extern adres, daarom gedraagt het resultaat zich als een kabel en niet als een route. Wat de router verlaat is IP-protocol 47 met het oorspronkelijke frame als payload, zodat broadcasts, ARP en niet-IP-protocollen allemaal passeren. GRE voegt geen eigen vertrouwelijkheid toe, en het frame blijft leesbaar voor alles wat het buitenste pakket ziet. Dat ene feit bepaalt de volgorde van dit lab: bouw eerst het versleutelde pad en draag daarna Ethernet erbinnen.

Wat EoIP inwikkelt, en wat niet

De inkapseling is het hele mechanisme. Een frame arriveert op een gebrugde poort, krijgt een GRE-header en een buitenste IP-header, en wordt aan de partnerrouter afgeleverd, die beide verwijdert en het frame in zijn eigen bridge injecteert. De ontvangende bridge leert het bron-MAC precies zoals van een lokale poort. Niets in dat proces authenticeert het frame of verbergt het.

Vertrouwelijkheid moet dus van het pad komen waarover het GRE-pakket reist. In dit ontwerp is de onderlaag een WireGuard- of IPsec-tunnel tussen de twee routers, en EoIP wordt daarbinnen gedragen. MikroTik biedt ook een automatische IPsec-optie op de EoIP-interface zelf, wat een andere opstelling is en niet wat dit lab configureert.

Voor gerouteerde IP-diensten is een gerouteerd VPN het kleinere ontwerp en het ontwerp dat de voorkeur verdient. Grijp alleen naar laag twee wanneer een apparaat echt Ethernet-frames van de andere locatie moet zien.

Vereisten: een versleutelde onderlaag en twee ongebruikte poorten

Beide routers hebben een bestaande versleutelde verbinding nodig en een adres daarop dat de partner kan bereiken. De LTE-kant start de buitenste verbinding, dus de hub belt nooit het mobiele netwerk, en de LTE-router houdt de NAT-status bij die de operator vereist. Bevestig dat de tunnel actief is voordat je er iets bovenop zet, want een EoIP-interface die zijn externe adres niet bereikt, ziet er identiek uit aan een verkeerd geconfigureerde.

Elke router heeft ook een poort nodig die nog geen bridgelid, VLAN-trunk, beheerinterface of productielink is. Een lab dat een live poort leent is geen lab, en de faalmodus is een broadcaststorm op een werkend netwerk. Verplaats het beheer naar een andere interface of naar de console voordat je begint.

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

Die waarden zijn een voorbeeld en geen vereiste. Ze moeten op de tunnelinterfaces staan en via het beschermde pad worden gerouteerd. Het firewallbeleid op beide routers moet GRE tussen de twee tunneladressen toestaan, en GRE is IP-protocol 47, geen TCP- of UDP-poort met nummer 47. Dit ontwerp stelt nooit ruwe GRE bloot aan een van beide WAN's.

Maak het tunnelpaar met overeenkomende ID's

De twee uiteinden zijn één logische interface die twee keer is gedefinieerd, dus elk identificerend veld moet overeenkomen. Op de hub:

/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

Op de LTE-router draaien de adressen om en verschilt het MAC:

/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

Het tunnel-ID moet aan beide uiteinden overeenkomen en mag niet botsen met een ander paar dat al op een van de routers is geconfigureerd, dus hergebruik geen waarde uit een leveranciersvoorbeeld. MAC-adressen zijn lokaal beheerde waarden die uniek moeten zijn binnen het laag-twee-domein waar je bij aansluit. Interfacenamen zijn lokaal per router en hoeven alleen consistent te zijn voor je eigen scripts.

De huidige EoIP-handleiding documenteert de velden voor eindpunt en tunnel-ID en zegt duidelijk dat EoIP Ethernet over GRE is. Niets in dat commando versleutelt iets, daarom komt de controle van de onderlaag eerst.

Bridge alleen de testpoorten

Een bridge is wat de tunnel tot een segment maakt, en de samenstelling ervan is de hele beveiligingsgrens. Op de hub:

/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

Op de LTE-router:

/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

Deze commando's maken nieuwe bridges en voegen aan elk precies twee poorten toe. De EoIP-interface is het laag-twee-lid; de versleutelde tunnel blijft gerouteerd transport en mag nooit als bridgepoort worden toegevoegd. Voeg geen productiepoort toe en start geen DHCP-server op de labbridge.

Geef de twee testhosts adressen in een ongebruikt subnet zonder concurrerende DHCP-server, bijvoorbeeld 192.168.77.11/24 en 192.168.77.12/24. Ze hebben geen standaardgateway nodig om elkaar binnen dat subnet te bereiken, en een router-interfaceadres is niet nodig om de frames te laten passeren.

Begroot de overhead voordat je een LAN uitbreidt

EoIP over IPv4 voegt Ethernet-, GRE- en buitenste IP-headers toe rond de gedragen payload. Voor het ongetagde geval documenteert MikroTik 42 bytes, dus een onderlaag met 1400 bytes bruikbare IP-MTU laat 1358 bytes over voor het binnenste frame. Dat getal is een budget en geen universele MSS-waarde, en het dwingt een gebrugde host niet om kleinere frames te versturen.

Controleer de werkelijke grenzen op het pad en test dan met het grootste frame dat het apparaat echt verstuurt. Een frame van 1500 bytes dat binnen het beschermde pad gefragmenteerd moet worden, gedraagt zich anders dan een dat past, en het verschil uit zich als een toepassingsstilstand en niet als een linkstoring.

/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 behandelt lussen, niet willekeurige parallelle paden, dus houd de proeftopologie eenvoudig. Een bridge uitbreiden breidt ook broadcast-, multicast- en DHCP-gedrag uit over de mobiele link, en dat verkeer verbruikt capaciteit of er nu een nuttig frame beweegt of niet.

Plan een productieaansluiting pas als het lab de framegrootte en het toepassingsgedrag bereikt die je echt nodig hebt. Vóór die overstap moet je het eens worden over adressering, VLAN-lidmaatschap, DHCP-autoriteit, luspreventie en hoe iemand de routers bereikt wanneer de link zelf plat ligt. Een Ethernet-uitbreiding verbindt faaldomeinen net als apparaten, dus verdient ze een wijzigingsvenster in plaats van nog een poort op een werkende bridge.