EoIP su un collegamento VPN LTE: costruire un piccolo laboratorio RouterOS

EoIP prende un frame Ethernet completo, lo incapsula in GRE e lo invia a un indirizzo remoto configurato, ed è per questo che il risultato si comporta come un cavo e non come una rotta. Ciò che esce dal router è il protocollo IP 47 con il frame originale come payload, quindi broadcast, ARP e protocolli non IP passano tutti. GRE non aggiunge alcuna riservatezza propria, e il frame resta leggibile a qualunque cosa veda il pacchetto esterno. Quel singolo fatto decide l'ordine di questo laboratorio: prima costruisci il percorso cifrato, poi trasporta Ethernet al suo interno.

Cosa incapsula EoIP, e cosa no

L'incapsulamento è l'intero meccanismo. Un frame arriva su una porta in bridge, riceve un'intestazione GRE e un'intestazione IP esterna, e viene consegnato al router pari, che rimuove entrambe e inietta il frame nel proprio bridge. Il bridge ricevente apprende il MAC di origine esattamente come farebbe da una porta locale. Nulla in quel processo autentica il frame o lo nasconde.

La riservatezza deve quindi venire dal percorso su cui viaggia il pacchetto GRE. In questo progetto il sottostante è un tunnel WireGuard o IPsec tra i due router, ed EoIP viene trasportato al suo interno. MikroTik espone anche un'opzione IPsec automatica sulla stessa interfaccia EoIP, che è una disposizione diversa e non è quella configurata da questo laboratorio.

Per i servizi IP instradati, una VPN instradata è il progetto più piccolo e quello da preferire. Ricorri al livello due solo quando un dispositivo ha davvero bisogno di vedere i frame Ethernet dell'altro sito.

Prerequisiti: un sottostante cifrato e due porte inutilizzate

Entrambi i router hanno bisogno di un collegamento cifrato stabilito e di un indirizzo su di esso che il pari possa raggiungere. Il lato LTE avvia la connessione esterna, quindi l'hub non chiama mai la rete mobile, e il router LTE mantiene lo stato NAT richiesto dall'operatore. Conferma che il tunnel è attivo prima di aggiungere qualcosa sopra, perché un'interfaccia EoIP che non raggiunge il proprio indirizzo remoto appare identica a una mal configurata.

Ogni router ha anche bisogno di una porta che non sia già membro di un bridge, un trunk VLAN, un'interfaccia di gestione o un collegamento di produzione. Un laboratorio che prende in prestito una porta attiva non è un laboratorio, e la modalità di guasto è una tempesta di broadcast su una rete in funzione. Sposta l'amministrazione su un'altra interfaccia o sulla console prima di iniziare.

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

Quei valori sono un esempio e non un requisito. Devono stare sulle interfacce del tunnel ed essere instradati attraverso il percorso protetto. La politica del firewall su entrambi i router deve consentire GRE tra i due indirizzi del tunnel, e GRE è il protocollo IP 47, non una porta TCP o UDP con il numero 47. Questo progetto non espone mai GRE grezzo a nessuna delle due WAN.

Crea la coppia di tunnel con ID corrispondenti

Le due estremità sono un'unica interfaccia logica definita due volte, quindi ogni campo identificativo deve coincidere. Sull'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

Sul router LTE gli indirizzi si invertono e il MAC è diverso:

/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 del tunnel deve coincidere su entrambe le estremità e non deve entrare in collisione con un'altra coppia già configurata su uno dei router. Gli indirizzi MAC sono valori amministrati localmente che devono essere unici nel dominio di livello due a cui ti unisci, quindi non riutilizzare un valore di un esempio del fornitore. I nomi delle interfacce sono locali a ciascun router e devono essere coerenti solo per i tuoi script.

Il manuale EoIP attuale documenta i campi dell'endpoint e dell'ID del tunnel, e afferma chiaramente che EoIP è Ethernet su GRE. Nulla in quel comando cifra qualcosa, ed è per questo che il controllo del sottostante viene per primo.

Bridge solo le porte di test

Un bridge è ciò che trasforma il tunnel in un segmento, e la sua composizione è l'intero confine di sicurezza. Sull'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

Sul router 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

Questi comandi creano nuovi bridge e aggiungono esattamente due porte a ciascuno. L'interfaccia EoIP è il membro di livello due; il tunnel cifrato resta un trasporto instradato e non deve mai essere aggiunto come porta di bridge. Non aggiungere una porta di produzione e non avviare un server DHCP sul bridge del laboratorio.

Assegna ai due host di test indirizzi in una sottorete inutilizzata e senza server DHCP concorrenti, come 192.168.77.11/24 e 192.168.77.12/24. Non hanno bisogno di un gateway predefinito per raggiungersi dentro quella sottorete, e un indirizzo di interfaccia del router non è necessario perché i frame passino.

Preventiva l'overhead prima di estendere una LAN

EoIP su IPv4 aggiunge intestazioni Ethernet, GRE e IP esterna attorno al payload trasportato. Per il caso senza tag MikroTik documenta 42 byte, quindi un sottostante con 1400 byte di MTU IP utilizzabile lascia 1358 byte per il frame interno. Quel numero è un budget e non un valore MSS universale, e non obbliga un host in bridge a emettere frame più piccoli.

Verifica i limiti reali sul percorso, poi prova con il frame più grande che il dispositivo invia davvero. Un frame di 1500 byte che deve essere frammentato nel percorso protetto si comporta diversamente da uno che ci sta, e la differenza si manifesta come un blocco dell'applicazione e non come un guasto del collegamento.

/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 gestisce i loop, non percorsi paralleli arbitrari, quindi mantieni semplice la topologia pilota. Estendere un bridge estende anche il comportamento di broadcast, multicast e DHCP sul collegamento mobile, e quel traffico consuma capacità indipendentemente dal fatto che si muova un frame utile.

Pianifica un collegamento di produzione solo quando il laboratorio raggiunge la dimensione del frame e il comportamento applicativo che ti servono davvero. Prima di quel passaggio, concordare indirizzamento, appartenenza alle VLAN, autorità DHCP, prevenzione dei loop e come qualcuno raggiunge i router quando il collegamento stesso è caduto. Un'estensione Ethernet unisce domini di guasto oltre che dispositivi, quindi merita una finestra di cambiamento e non una porta in più su un bridge in funzione.