EoIP sobre uma ligação VPN LTE: montar um pequeno laboratório RouterOS

O EoIP pega num frame Ethernet completo, envolve-o em GRE e envia-o para um endereço remoto configurado, e é por isso que o resultado se comporta como um cabo e não como uma rota. O que sai do router é o protocolo IP 47 com o frame original como carga útil, portanto as difusões, o ARP e os protocolos não IP passam todos. O GRE não acrescenta confidencialidade própria, e o frame continua legível para tudo o que veja o pacote exterior. Esse único facto decide a ordem deste laboratório: construa primeiro o caminho cifrado e só depois transporte Ethernet dentro dele.

O que o EoIP envolve, e o que não envolve

O encapsulamento é todo o mecanismo. Um frame chega a uma porta em bridge, recebe um cabeçalho GRE e um cabeçalho IP exterior, e é entregue ao router par, que remove ambos e injeta o frame na sua própria bridge. A bridge recetora aprende o MAC de origem exatamente como faria a partir de uma porta local. Nada nesse processo autentica o frame nem o esconde.

A confidencialidade tem, por isso, de vir do caminho por onde viaja o pacote GRE. Neste desenho a camada inferior é um túnel WireGuard ou IPsec entre os dois routers, e o EoIP é transportado lá dentro. O MikroTik também expõe uma opção de IPsec automático na própria interface EoIP, que é outra disposição e não é o que este laboratório configura.

Para serviços IP encaminhados, uma VPN encaminhada é o desenho mais pequeno e aquele que se deve preferir. Recorra à camada dois apenas quando um dispositivo precisar mesmo de ver frames Ethernet do outro local.

Pré-requisitos: uma camada inferior cifrada e duas portas não utilizadas

Ambos os routers precisam de uma ligação cifrada estabelecida e de um endereço nela que o par consiga alcançar. O lado LTE inicia a ligação exterior, pelo que o hub nunca marca a rede móvel, e o router LTE mantém o estado NAT que o operador exige. Confirme que o túnel está ativo antes de acrescentar algo por cima, porque uma interface EoIP que não alcança o seu endereço remoto parece idêntica a uma mal configurada.

Cada router precisa também de uma porta que não seja já membro de uma bridge, um trunk VLAN, uma interface de gestão ou uma ligação de produção. Um laboratório que pede emprestada uma porta ativa não é um laboratório, e o modo de falha é uma tempestade de difusão numa rede em funcionamento. Mova a administração para outra interface ou para a consola antes de começar.

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

Esses valores são um exemplo e não um requisito. Têm de estar nas interfaces do túnel e ser encaminhados pelo caminho protegido. A política de firewall de ambos os routers tem de permitir GRE entre os dois endereços do túnel, e o GRE é o protocolo IP 47, não uma porta TCP ou UDP com o número 47. Este desenho nunca expõe GRE em bruto a nenhuma das WAN.

Crie o par de túneis com ID coincidentes

As duas extremidades são uma única interface lógica definida duas vezes, pelo que cada campo identificador tem de coincidir. No 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

No router LTE os endereços invertem-se e o MAC é diferente:

/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

O ID do túnel tem de coincidir nas duas extremidades e não pode colidir com outro par já configurado em qualquer dos routers. Os endereços MAC são valores administrados localmente que têm de ser únicos dentro do domínio de camada dois a que se junta, por isso não reutilize um valor de um exemplo de fabricante. Os nomes das interfaces são locais a cada router e só precisam de ser coerentes para os seus próprios scripts.

O manual atual do EoIP documenta os campos de ponto final e de ID de túnel, e diz claramente que o EoIP é Ethernet sobre GRE. Nada nesse comando cifra nada, e é por isso que a verificação da camada inferior vem primeiro.

Faça bridge apenas das portas de teste

Uma bridge é o que transforma o túnel num segmento, e a sua composição é toda a fronteira de segurança. No 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

No 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

Estes comandos criam bridges novas e acrescentam exatamente duas portas a cada uma. A interface EoIP é o membro de camada dois; o túnel cifrado continua a ser um transporte encaminhado e nunca deve ser acrescentado como porta de bridge. Não acrescente uma porta de produção e não inicie um servidor DHCP na bridge do laboratório.

Atribua aos dois anfitriões de teste endereços numa sub-rede não utilizada e sem servidor DHCP concorrente, como 192.168.77.11/24 e 192.168.77.12/24. Não precisam de gateway predefinido para se alcançarem dentro dessa sub-rede, e não é necessária uma morada de interface do router para que os frames passem.

Planeie o overhead antes de estender uma LAN

O EoIP sobre IPv4 acrescenta cabeçalhos Ethernet, GRE e IP exterior em torno da carga útil transportada. Para o caso sem etiqueta, a MikroTik documenta 42 bytes, pelo que uma camada inferior com 1400 bytes de MTU IP utilizável deixa 1358 bytes para o frame interior. Esse número é um orçamento e não um valor MSS universal, e não obriga um anfitrião em bridge a emitir frames mais pequenos.

Verifique os limites reais no caminho e depois teste com o maior frame que o equipamento envia de facto. Um frame de 1500 bytes que tem de ser fragmentado dentro do caminho protegido comporta-se de forma diferente de um que caiba, e a diferença manifesta-se como um bloqueio da aplicação e não como uma falha da ligação.

/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

O RSTP trata de ciclos, não de caminhos paralelos arbitrários, por isso mantenha a topologia piloto simples. Estender uma bridge também estende o comportamento de difusão, multicast e DHCP ao longo da ligação móvel, e esse tráfego consome capacidade quer se mova um frame útil quer não.

Planeie uma ligação de produção só quando o laboratório atingir o tamanho de frame e o comportamento de aplicação de que realmente precisa. Antes dessa mudança, acorde o endereçamento, a pertença a VLAN, a autoridade DHCP, a prevenção de ciclos e a forma como alguém chega aos routers quando a própria ligação está em baixo. Uma extensão Ethernet une domínios de falha além de dispositivos, por isso merece uma janela de alteração e não mais uma porta numa bridge em funcionamento.