EoIP LTE VPN-kapcsolat felett: egy kis RouterOS-labor építése

Az EoIP egy teljes Ethernet-keretet vesz át, GRE-be csomagolja, és egy beállított távoli címre küldi, ezért az eredmény kábelként viselkedik, nem útvonalként. A routerből IP 47-es protokoll lép ki, az eredeti kerettel hasznos teherként, így a broadcastok, az ARP és a nem IP-protokollok mind átjutnak. A GRE nem ad hozzá saját titkosságot, és a keret olvasható marad minden számára, ami látja a külső csomagot. Ez az egyetlen tény határozza meg a labor sorrendjét: először építse fel a titkosított utat, aztán vigye benne az Ethernetet.

Mit csomagol be az EoIP, és mit nem

A beágyazás maga az egész mechanizmus. Egy keret megérkezik egy hídhoz tartozó portra, GRE-fejlécet és külső IP-fejlécet kap, és eljut a partnerrouterhez, amely mindkettőt leveszi, és a keretet a saját hídjába injektálja. A fogadó híd a forrás MAC-címet pontosan úgy tanulja meg, mint egy helyi portról. Ebben a folyamatban semmi nem hitelesíti és nem rejti el a keretet.

A titkosságnak tehát abból az útvonalból kell jönnie, amelyen a GRE-csomag halad. Ebben a tervben az alsó réteg egy WireGuard- vagy IPsec-alagút a két router között, és az EoIP ezen belül halad. A MikroTik magán az EoIP-interfészen is kínál automatikus IPsec-lehetőséget, ami más elrendezés, és nem az, amit ez a labor beállít.

Az útvonalválasztott IP-szolgáltatásokhoz az útvonalválasztott VPN a kisebb terv, és ezt érdemes előnyben részesíteni. Csak akkor nyúljon a második réteghez, ha egy eszköznek valóban látnia kell a másik telephely Ethernet-kereteit.

Előfeltételek: titkosított alsó réteg és két használaton kívüli port

Mindkét routernek szüksége van egy létrejött titkosított kapcsolatra és egy címe rá, amelyet a partner el tud érni. A külső kapcsolatot az LTE-oldal indítja, ezért a hub soha nem tárcsázza a mobilhálózatot, és az LTE-router fenntartja azt a NAT-állapotot, amelyet az operátor megkövetel. Erősítse meg, hogy az alagút működik, mielőtt bármit rátenne, mert az az EoIP-interfész, amely nem éri el a távoli címét, pontosan úgy néz ki, mint egy hibásan beállított.

Mindkét routernek kell egy olyan port is, amely még nem hídtag, nem VLAN-trunk, nem kezelési interfész és nem termelési kapcsolat. Az a labor, amelyik egy élő portot kölcsönöz, nem labor, és a hiba módja egy broadcastvihar egy működő hálózaton. A kezelést indítás előtt helyezze át egy másik interfészre vagy a konzolra.

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

Ezek az értékek példák, nem követelmények. Az alagút interfészein kell lenniük, és a védett útvonalon keresztül kell őket átirányítani. Mindkét router tűzfalházirendjének engedélyeznie kell a GRE-t a két alagútcím között, és a GRE IP 47-es protokoll, nem a 47-es számú TCP- vagy UDP-port. Ez a terv soha nem teszi ki a nyers GRE-t egyik WAN-nak sem.

Hozza létre az alagútpárt egyező ID-kkel

A két vég egyetlen logikai interfész, kétszer definiálva, ezért minden azonosító mezőnek egyeznie kell. A hubon:

/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

Az LTE-routeren a címek megfordulnak, és a MAC eltér:

/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

Az alagút ID-jének mindkét végén egyeznie kell, és nem ütközhet egy másik, már beállított párral egyik routeren sem. A MAC-címek helyileg kezelt értékek, amelyeknek egyedinek kell lenniük abban a második rétegbeli tartományban, amelyhez csatlakozik, ezért ne használjon újra egy értéket egy gyártói példából. Az interfésznevek routerenként helyiek, és csak a saját szkriptjeihez kell következetesnek lenniük.

A jelenlegi EoIP-kézikönyv dokumentálja a végpont és az alagút-ID mezőit, és nyíltan kimondja, hogy az EoIP Ethernet a GRE felett. Ebben a parancsban semmi nem titkosít semmit, ezért az alsó réteg ellenőrzése az első.

Csak a tesztportokat hidalja össze

A híd az, ami az alagutat szegmenssé teszi, és az összetétele a teljes biztonsági határ. A hubon:

/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

Az LTE-routeren:

/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

Ezek a parancsok új hidakat hoznak létre, és mindegyikhez pontosan két portot adnak. Az EoIP-interfész a második réteg tagja; a titkosított alagút útvonalválasztott átvitel marad, és soha nem szabad hídportként hozzáadni. Ne adjon hozzá termelési portot, és ne indítson DHCP-kiszolgálót a labor hídján.

Adjon a két teszthosztnak címeket egy használaton kívüli alhálózatban, versengő DHCP-kiszolgáló nélkül, például 192.168.77.11/24 és 192.168.77.12/24. Nincs szükségük alapértelmezett átjáróra, hogy elérjék egymást azon az alhálózaton belül, és a routerinterfész címe sem kell a keretek átjutásához.

Tervezze meg a többletköltséget, mielőtt LAN-t bővít

Az IPv4 feletti EoIP Ethernet-, GRE- és külső IP-fejlécet ad a szállított hasznos teher köré. A címkézetlen esetre a MikroTik 42 bájtot dokumentál, így egy 1400 bájt hasznos IP MTU-val rendelkező alsó réteg 1358 bájtot hagy a belső keretnek. Ez a szám költségkeret, nem univerzális MSS-érték, és nem kényszeríti a hídhoz kapcsolt hostot kisebb keretek küldésére.

Ellenőrizze az útvonal valódi határait, majd teszteljen a legnagyobb kerettel, amelyet az eszköz ténylegesen küld. Az 1500 bájtos keret, amelyet a védett útvonalon belül fel kell darabolni, másképp viselkedik, mint az, amelyik befér, és a különbség az alkalmazás megakadásaként jelenik meg, nem kapcsolathibaként.

/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

Az RSTP a hurkokat kezeli, nem tetszőleges párhuzamos utakat, ezért tartsa egyszerűnek a kísérleti topológiát. A híd bővítése a broadcast-, a multicast- és a DHCP-viselkedést is kiterjeszti a mobilkapcsolaton át, és ez a forgalom kapacitást fogyaszt, akár mozog hasznos keret, akár nem.

Csak akkor tervezzen termelési csatlakozást, amikor a labor eléri azt a keretméretet és alkalmazásviselkedést, amelyre valóban szüksége van. A váltás előtt egyeztessen a címzésről, a VLAN-tagságról, a DHCP-jogosultságról, a hurkok megelőzéséről és arról, hogyan ér el valaki a routerekhez, amikor maga a kapcsolat áll. Az Ethernet-bővítés a meghibásodási tartományokat is összekapcsolja az eszközökkel együtt, ezért változási ablakot érdemel, nem még egy portot egy működő hídon.