EoIP printr-o legătură VPN LTE: construirea unui laborator RouterOS mic

EoIP preia un cadru Ethernet complet, îl înfășoară în GRE și îl trimite la o adresă îndepărtată configurată, de aceea rezultatul se comportă ca un cablu și nu ca o rută. Ce iese din router este protocolul IP 47 cu cadrul original ca încărcătură utilă, așa că difuziunile, ARP și protocoalele care nu sunt IP trec toate. GRE nu adaugă o confidențialitate proprie, iar cadrul rămâne lizibil pentru orice vede pachetul exterior. Acest singur fapt decide ordinea acestui laborator: construiește mai întâi calea criptată, apoi transportă Ethernet în interiorul ei.

Ce înfășoară EoIP și ce nu

Encapsularea este întregul mecanism. Un cadru ajunge pe un port din punte, primește un antet GRE și un antet IP exterior, și este livrat routerului partener, care le elimină pe amândouă și injectează cadrul în propria punte. Puntea receptoare învață MAC-ul sursă exact cum ar face-o de la un port local. Nimic din acel proces nu autentifică cadrul și nu îl ascunde.

Prin urmare, confidențialitatea trebuie să vină de pe calea pe care călătorește pachetul GRE. În acest proiect stratul inferior este un tunel WireGuard sau IPsec între cele două routere, iar EoIP este transportat în interiorul lui. MikroTik expune și o opțiune de IPsec automat pe interfața EoIP însăși, ceea ce este o altă aranjare și nu este ceea ce configurează acest laborator.

Pentru servicii IP rutate, un VPN rutat este proiectul mai mic și cel care trebuie preferat. Apelați la stratul doi doar când un dispozitiv are într-adevăr nevoie să vadă cadre Ethernet din cealaltă locație.

Condiții prealabile: un strat inferior criptat și două porturi neutilizate

Ambele routere au nevoie de o legătură criptată stabilită și de o adresă pe ea pe care partenerul o poate atinge. Partea LTE inițiază conexiunea exterioară, așa că hubul nu formează niciodată numărul rețelei mobile, iar routerul LTE menține starea NAT cerută de operator. Confirmați că tunelul funcționează înainte de a adăuga ceva deasupra, pentru că o interfață EoIP care nu își atinge adresa îndepărtată arată identic cu una configurată greșit.

Fiecare router are nevoie și de un port care nu este deja membru al unei punți, trunk VLAN, interfață de administrare sau legătură de producție. Un laborator care împrumută un port activ nu este laborator, iar modul de eșec este o furtună de difuziune într-o rețea funcțională. Mutați administrarea pe altă interfață sau pe consolă înainte de a începe.

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

Aceste valori sunt un exemplu și nu o cerință. Ele trebuie să se afle pe interfețele tunelului și să fie rutate prin calea protejată. Politica firewall-ului de pe ambele routere trebuie să permită GRE între cele două adrese ale tunelului, iar GRE este protocolul IP 47, nu un port TCP sau UDP cu numărul 47. Acest proiect nu expune niciodată GRE brut niciuneia dintre cele două WAN.

Creați perechea de tuneluri cu ID-uri potrivite

Cele două capete sunt o singură interfață logică definită de două ori, așa că fiecare câmp de identificare trebuie să coincidă. Pe 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

Pe routerul LTE adresele se inversează, iar MAC-ul este diferit:

/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

ID-ul tunelului trebuie să coincidă la ambele capete și nu trebuie să se ciocnească cu altă pereche deja configurată pe oricare dintre routere. Adresele MAC sunt valori administrate local, care trebuie să fie unice în domeniul de stratul doi în care intrați, așa că nu reutilizați o valoare dintr-un exemplu de producător. Numele interfețelor sunt locale pentru fiecare router și trebuie să fie consecvente doar pentru scripturile dumneavoastră.

Manualul EoIP actual documentează câmpurile de punct final și de ID al tunelului și spune clar că EoIP este Ethernet peste GRE. Nimic din acea comandă nu criptează nimic, de aceea verificarea stratului inferior vine prima.

Puneți în punte doar porturile de test

O punte este ceea ce transformă tunelul într-un segment, iar compoziția ei este întreaga frontieră de securitate. Pe 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

Pe routerul 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

Aceste comenzi creează punți noi și adaugă exact două porturi la fiecare. Interfața EoIP este membrul de stratul doi; tunelul criptat rămâne un transport rutat și nu trebuie adăugat niciodată ca port de punte. Nu adăugați un port de producție și nu porniți un server DHCP pe puntea laboratorului.

Dați celor două gazde de test adrese într-o subrețea neutilizată și fără server DHCP concurent, cum ar fi 192.168.77.11/24 și 192.168.77.12/24. Nu au nevoie de o poartă implicită pentru a se atinge reciproc în acea subrețea, iar o adresă de interfață a routerului nu este necesară pentru ca frame-urile să treacă.

Bugetați suprasarcina înainte de a extinde un LAN

EoIP peste IPv4 adaugă antete Ethernet, GRE și IP exterior în jurul încărcăturii transportate. Pentru cazul fără etichetă, MikroTik documentează 42 de bytes, așa că un strat inferior cu 1400 de bytes de MTU IP utilizabil lasă 1358 de bytes pentru cadrul interior. Acel număr este un buget, nu o valoare MSS universală, și nu obligă o gazdă din punte să emită cadre mai mici.

Verificați limitele reale de pe cale și apoi testați cu cel mai mare cadru pe care dispozitivul îl trimite efectiv. Un cadru de 1500 de bytes care trebuie fragmentat în interiorul căii protejate se comportă diferit de unul care încape, iar diferența apare ca o blocare a aplicației și nu ca o defecțiune a legăturii.

/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 tratează buclele, nu căi paralele arbitrare, așa că păstrați topologia pilot simplă. Extinderea unei punți extinde și comportamentul de difuziune, multicast și DHCP de-a lungul legăturii mobile, iar acel trafic consumă capacitate indiferent dacă se mișcă vreun cadru util.

Planificați o conectare de producție doar când laboratorul atinge dimensiunea de cadru și comportamentul aplicației de care aveți într-adevăr nevoie. Înainte de acea trecere, conveniți asupra adresării, apartenenței la VLAN, autorității DHCP, prevenirii buclelor și asupra modului în care cineva ajunge la routere atunci când legătura însăși este căzută. O extensie Ethernet unește domenii de eșec la fel ca dispozitivele, așa că merită o fereastră de schimbare și nu încă un port pe o punte funcțională.