1. Wstęp – protokoły tunelowe w RouterOS

RouterOS udostępnia trzy główne protokoły tunelowe do łączenia dwóch routerów przez sieć IP (transport):

• GRE(Generic Routing Encapsulation, RFC 2784) – tunel warstwy 3, przekazuje pakiety IP i IPv6
• IPIP(IP-in-IP, RFC 2003) – tunel warstwy 3, przekazuje tylko pakiety IPv4
• EoIP (Ethernet over IP) – tunel warstwy 2, oparty na RFC 1701 (GRE), przekazuje ramki Ethernet wraz z broadcastami, multicastami i całym ruchem L2. Protokół własnościowy MikroTik (działa między routerami RouterOS)

Ważne różnice w skrócie:

2. GRE vs EoIP – kiedy co wybrać

Kiedy używać GRE (warstwa 3)

• Potrzebujesz routingu między sieciami (site-to-site VPN na warstwie IP)
• Chcesz uruchomić dynamiczne protokoły routingu przez tunel – GRE przekazuje multicasty IP, których wymagają OSPF (224.0.0.5) i RIPv2 (224.0.0.9). Uwaga: BGP NIE używa multicastów (działa na TCP/unicast), więc dla samego BGP wystarczy dowolny tunel IP
• Jeden lub oba końce tunelu to routery nie-MikroTik (Cisco, Juniper, Linux) – GRE jest standardowym protokołem
• Zależy Ci na niskim overheadzie (24 bajty vs 42+ bajty w EoIP)
• Potrzebujesz keepalive do wykrywania przerw w połączeniu

Kiedy używać EoIP (warstwa 2)

• Potrzebujesz rozszerzyć sieć LAN między dwoma lokalizacjami (ten sam broadcast domain, ta sama podsieć)
• Potrzebujesz przekazywać broadcasty (np. DHCP, ARP)
• Potrzebujesz przekazywać ruch nie-IP (IPX, AppleTalk, legacy)
• Chcesz bridgować porty switcha między dwoma routerami jakby były połączone kablem
• Oba routery to MikroTik RouterOS (EoIP jest protokołem własnościowym MikroTik)
• Potrzebujesz przenosić VLANy między lokalizacjami (EoIP przekazuje ramki 802.1Q)

3. Topologia testowa i środowisko

W tym przewodniku konfigurujemy dwa routery MikroTik CHR (Cloud Hosted Router) z RouterOS w wersji 7.16.1 (stable) działające w środowisku wirtualnym (VirtualBox):

Środowisko testowe

Używamy dwóch routerów z dostępem przez SSH. Konfiguracja była weryfikowana na routerze A (192.168.53.83):

# Wersja RouterOS i sprzęt (Router A):
/system resource print

        name: MikroTik
       uptime: 3m32s
      version: 7.16.1 (stable)
 build-time: 2024-10-10 14:03:32
      free-memory: 20.3MiB
   total-memory: 64.0MiB
             cpu: Intel(R)
       cpu-count: 1
  cpu-frequency: 2591MHz
       cpu-load: 3%
  free-hdd-space: 71.1MiB
  total-hdd-space: 89.2MiB
architecture-name: x86_64
     board-name: CHR innotek GmbH VirtualBox

# Interfejsy na routerze A:
/interface print

Flags: R - RUNNING
#   NAME    TYPE      ACTUAL-MTU  MAC-ADDRESS
0 R ether1  ether           1500  08:00:27:E8:30:07
1 R lo      loopback       65536  00:00:00:00:00:00

# Adres IP routera A:
/ip address print

  ADDRESS           NETWORK       INTERFACE
  192.168.53.83/24  192.168.53.0  ether1

4. Scenariusz 1: Tunel GRE (warstwa 3 – routing)

W tym scenariuszu tworzymy tunel GRE między dwoma routerami, który przekazuje pakiety IP. Tunel działa jak wirtualny kabel punkt-do-punkt. Przez tunel GRE można przekazywać multicasty IP (niezbędne dla OSPF/RIPv2), ale NIE można przekazywać broadcastów L2 (ARP, DHCP).

4.1. Tworzenie interfejsu GRE

Router A (192.168.53.83)

/interface gre add name=gre-tunnel-84 \
    remote-address=192.168.53.84 \
    local-address=192.168.53.83 \
    keepalive=10s,10 \
    comment="Tunel GRE do routera B"

Router B (192.168.53.84)

/interface gre add name=gre-tunnel-83 \
    remote-address=192.168.53.83 \
    local-address=192.168.53.84 \
    keepalive=10s,10 \
    comment="Tunel GRE do routera A"

Wyjaśnienie parametrów:

# Wynik po utworzeniu tunelu GRE na routerze A:
/interface gre print detail

Flags: X - disabled; R - running
0    name="gre-tunnel-84" mtu=auto actual-mtu=1476
     local-address=192.168.53.83
     remote-address=192.168.53.84
     keepalive=10s,10 dscp=inherit
     clamp-tcp-mss=yes dont-fragment=no allow-fast-path=yes

4.2. Adresowanie tunelu

Tunel GRE działa jak wirtualny interfejs punkt-do-punkt. Należy mu przypisać adresy IP z sieci punkt-do-punkt (najczęściej /30):

Router A (192.168.53.83)

/ip address add address=172.16.1.1/30 interface=gre-tunnel-84 \
    comment="Adres IP tunelu GRE - koniec A"

Router B (192.168.53.84)

/ip address add address=172.16.1.2/30 interface=gre-tunnel-83 \
    comment="Adres IP tunelu GRE - koniec B"

# Wynik na routerze A po dodaniu adresu IP:
/ip address print

  ADDRESS           NETWORK       INTERFACE
  192.168.53.83/24  192.168.53.0  ether1
  172.16.1.1/30     172.16.1.0    gre-tunnel-84

4.3. Trasy statyczne

Aby routery mogły przekazywać ruch między sieciami lokalnymi przez tunel, potrzebne są trasy statyczne wskazujące na koniec tunelu jako bramę:

Załóżmy, ze sieć lokalna routera A to 10.10.10.0/24, a sieć lokalna routera B to 10.20.20.0/24.

Router A (192.168.53.83)

# Trasa do sieci lokalnej routera B przez tunel GRE
/ip route add dst-address=10.20.20.0/24 gateway=172.16.1.2 \
    comment="Trasa do sieci B przez GRE"

Router B (192.168.53.84)

# Trasa do sieci lokalnej routera A przez tunel GRE
/ip route add dst-address=10.10.10.0/24 gateway=172.16.1.1 \
    comment="Trasa do sieci A przez GRE"

# Tabela routingu na routerze A:
/ip route print

Flags: D - DYNAMIC; I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC; H - HW-OFFLOADED
#      DST-ADDRESS      GATEWAY        DISTANCE
  IsH 10.20.20.0/24    172.16.1.2            1     <--- trasa do sieci B (INACTIVE bo brak lacznosci z .84)
    DAc  10.10.10.0/24  lo                     0     <--- siec lokalna A
    DIcH 172.16.1.0/30  gre-tunnel-84          0     <--- siec tunelu GRE (connected)
    DAc  192.168.53.0/24 ether1                0     <--- siec transportowa (WAN)

4.4. Multicast przez GRE (OSPF, RIPv2 i inne)

Jedna z kluczowych zalet GRE nad IPIP jest możliwość przekazywania ruchu multicastowego IP. Jest to niezbędne dla dynamicznych protokołów routingu, które używają multicastów do wysyłania pakietów Hello i aktualizacji:

• OSPF – używa multicastów 224.0.0.5 i 224.0.0.6
• RIPv2 – używa multicastu 224.0.0.9
• PIM (Protocol Independent Multicast) – używa multicastu 224.0.0.13 (PIM Hello)
• IGMP – zarządzanie grupami multicastowymi (224.0.0.22)
• BGP – NIE używa multicastów. BGP wymienia trasy po TCP (unicast). Tzw. MP-BGP/MBGP może przenosić INFORMACJE o trasach multicastowych, ale sam działa unicastowo. Do uruchomienia BGP przez tunel nie jest potrzebny multicast

GRE przekazuje te pakiety ponieważ są to zwykle pakiety IP z adresem docelowym multicastowym. Router opakowuje je w nagłówek GRE i wysyła do zdalnego końca tunelu. Tam są rozpakowywane i dostarczane do lokalnej tablicy routingu.

Przykład: OSPF przez tunel GRE

Aby uruchomić OSPF przez tunel GRE, wystarczy dodać interfejs tunelu do processu OSPF. Multicastowe pakiety Hello będą automatycznie przekazywane przez tunel:

Router A

/routing ospf instance
add name=default router-id=10.10.10.1

/routing ospf network
add network=172.16.1.0/30 area=backbone
add network=10.10.10.0/24 area=backbone

Router B

/routing ospf instance
add name=default router-id=10.20.20.1

/routing ospf network
add network=172.16.1.0/30 area=backbone
add network=10.20.20.0/24 area=backbone

Pakiety OSPF Hello (do 224.0.0.5) będą przekazywane przez tunel GRE automatycznie. Zamiast ręcznych tras statycznych, routery naucza się siebie nawzajem przez OSPF:

# Po nawiązaniu OSPF - tablica routingu pokaże dynamiczne trasy:
/ip route print where dst-address~"10\."

#      DST-ADDRESS      GATEWAY        DISTANCE
    DAC  10.10.10.0/24   gre-tunnel-84         0
    DAo  10.20.20.0/24   172.16.1.2       110        <--- trasa dynamiczna OSPF

4.5. Weryfikacja tunelu GRE

Podstawowe komendy weryfikacyjne:

# Sprawdzenie stanu interfejsu tunelu GRE
/interface gre print

Flags: X - disabled; R - running
#   NAME             MTU   ACTUAL-MTU   LOCAL-ADDRESS     REMOTE-ADDRESS
0 R gre-tunnel-84    auto  1476         192.168.53.83     192.168.53.84

# Test łączności przez tunel (z routera A):
/ping 172.16.1.2

# Sprawdzenie ARP na interfejsie tunelu:
/ip arp print where interface=gre-tunnel-84

# Monitorowanie ruchu na interfejsie:
/interface monitor-traffic gre-tunnel-84 once

# Sprawdzenie keepalive:
/interface gre print stats

5. Scenariusz 2: Tunel EoIP (warstwa 2 – bridging, broadcasty, multicasty, L2)

EoIP (Ethernet over IP) to protokół MikroTik oparty na RFC 1701 (GRE), który tworzy tunel Ethernetowy między dwoma routerami. W przeciwieństwie do klasycznego GRE, EoIP przekazuje pełne ramki Ethernet, w tym:

• Broadcasty– ARP requests, DHCP discovery (0.0.0.0 -> 255.255.255.255)
• Multicasty L2 – IGMP, LLDP, STP BPDU, protokoły routingu multicastowego
• Ruch nie-IP – IPX, AppleTalk i inne protokoły warstwy 2
• VLANy– ramki 802.1Q przechodzą przez EoIP niezmiennie
• Wszystkie ramki Ethernet – cały ruch warstwy 2

5.1. Tworzenie interfejsu EoIP

Router A (192.168.53.83)

/interface eoip add name=eoip-to-84 \
    remote-address=192.168.53.84 \
    tunnel-id=100 \
    comment="Tunel EoIP L2 do routera B"

Router B (192.168.53.84)

/interface eoip add name=eoip-to-83 \
    remote-address=192.168.53.83 \
    tunnel-id=100 \
    comment="Tunel EoIP L2 do routera A"

Wyjaśnienie parametrów EoIP:

# Wynik po utworzeniu tunelu EoIP na routerze A:
/interface eoip print detail

Flags: X - disabled; R - running
0    ;;; Tunel EoIP L2 do routera B
     name="eoip-to-84" mtu=auto actual-mtu=1458 l2mtu=65535
     mac-address=FE:C6:96:AD:77:E6 arp=enabled arp-timeout=auto
     loop-protect=default loop-protect-status=off
     loop-protect-send-interval=5s loop-protect-disable-time=5m
     local-address=0.0.0.0 remote-address=192.168.53.84
     tunnel-id=100
     keepalive=10s,10 dscp=inherit clamp-tcp-mss=yes
     dont-fragment=no allow-fast-path=yes

Z powyższego wyniku widzimy:

• actual-mtu=1458 – pełna ramka Ethernet (1500) minus 42 bajty overhead EoIP (20 IP + 8 GRE + 14 Ethernet)
• l2mtu=65535 – MTU warstwy 2 (do użytku bridge)
• mac-address=FE:C6:96:AD:77:E6– automatycznie wygenerowany adres MAC
• tunnel-id=100– identyfikator tunelu

5.2. Bridge i porty

Aby EoIP działał jak wirtualny kabel Ethernet, interface tunelu EoIP musi zostać dodany do bridge (mostka) razem z lokalnymi portami Ethernet. Bridge łączy wszystkie porty w jeden broadcast domain:

Router A (192.168.53.83)

# Utwórz bridge (jeśli jeszcze nie istnieje)
/interface bridge add name=bridge1 protocol-mode=rstp \
    comment="Bridge z EoIP i portami LAN"

# Dodaj interfejs EoIP do bridge
/interface bridge port add bridge=bridge1 interface=eoip-to-84 \
    comment="EoIP tunel w bridge"

# Dodaj lokalny port LAN do bridge (NIE port transportowy/WAN!)
# UWAGA: w RouterOS 7 ether1 z adresem IP został już dodany automatycznie -
# sprawdź /interface bridge port print i usuń go jeśli nie chcesz bridge'owac
# sieci transportowej.
/interface bridge port add bridge=bridge1 interface=ether2 \
    comment="Port Ethernet LAN w bridge"

Router B (192.168.53.84)

# Utwórz bridge
/interface bridge add name=bridge1 protocol-mode=rstp \
    comment="Bridge z EoIP i portami LAN"

# Dodaj port EoIP do bridge
/interface bridge port add bridge=bridge1 interface=eoip-to-83 \
    comment="EoIP tunel w bridge"

# Dodaj lokalny port LAN do bridge (NIE port transportowy/WAN).
# Sprawdź też czy RouterOS nie dodał automatycznie ether1 (port z IP) do bridge.
/interface bridge port add bridge=bridge1 interface=ether2 \
    comment="Port Ethernet LAN w bridge"

# Bridge na routerze A:
/interface bridge print detail

Flags: X - disabled; R - running
0 R ;;; Bridge z EoIP i portami LAN
     name="bridge1" mtu=auto actual-mtu=1458 l2mtu=65535
     arp=enabled arp-timeout=auto mac-address=FE:C6:96:AD:77:E6
     protocol-mode=rstp fast-forward=yes igmp-snooping=no
     auto-mac=yes ageing-time=5m priority=0x8000
     max-message-age=20s forward-delay=15s
     transmit-hold-count=6 vlan-filtering=no

# Porty bridge (po usunięciu automatycznie dodanego ether1):
# UWAGA: nie ma tu portu TRANSPORTOWEGO - ether1 pozostał poza bridge,
# a jako port LAN dodaliśmy ether2.
/interface bridge port print

INTERFACE   BRIDGE   HW   PVID  PRIORITY  HORIZON
eoip-to-84  bridge1          1  0x80      none
ether2      bridge1  yes     1  0x80      none

Widzimy, ze bridge1 ma porty LAN, a port transportowy (ether1) jest poza bridge:

• eoip-to-84– Port EoIP (bez HW offloading, ponieważ to interfejs wirtualny)
• ether2– Fizyczny port LAN z hardware offloading (HW=yes)

5.3. Adresowanie i mostkowanie

Adres IP przypisujemy do bridge, NIE DO poszczególnych portów. Mostkowany interfejs (bridge) jest JEDNYM PORTEM broadcastowym:

Router A (192.168.53.83)

/ip address add address=10.100.100.1/24 interface=bridge1 \
    comment="Adres IP sieci lokalnej A"

Router B (192.168.53.84)

/ip address add address=10.100.100.2/24 interface=bridge1 \
    comment="Adres IP sieci lokalnej B"

Uwaga: oba routery mają adresy z TEJ SAMEJ sieci (10.100.100.0/24). To działa ponieważ są w tym samym broadcast domain dzięki tunelowi EoIP. Broadcast ARP z routera A dotrze do routera B i odwrotnie, tak jakby były połączone fizycznym kablem Ethernet.

# Przypisanie IP do bridge na routerze A:
/ip address print

  ADDRESS           NETWORK       INTERFACE
  192.168.53.83/24  192.168.53.0  ether1
  10.100.100.1/24   10.100.100.0  bridge1

5.4. Ustawianie MAC address dla EoIP

Gdy tunele EoIP są dodawane do bridge, ważne jest, aby każdy tunel miał unikalny adres MAC. Dzięki temu algorytmy bridge (STP, learning) działają poprawnie.

IANA zarezerwowała zakres MAC dla tuneli: 00:00:5E:80:00:00 – 00:00:5E:FF:FF:FF

Router A

# Ustaw unikalny MAC na tunelu EoIP
/interface eoip set eoip-to-84 mac-address=00:00:5E:80:00:01

Router B

# Ustaw unikalny MAC na tunelu EoIP
/interface eoip set eoip-to-83 mac-address=00:00:5E:80:00:02

5.5. Weryfikacja ruchu L2 (broadcasty, multicasty)

Na tunelu EoIP przekazywane są:

Broadcasty (ARP, DHCP)

# Gdy urządzenie w sieci A szuka MAC dla 10.100.100.2:
# 1. Wysyła ARP Request broadcast na wszystkie porty bridge
# 2. Bridge przekazuje ramkę przez EoIP do routera B
# 3. Router B dostarcza ramkę na wszystkie porty swojego bridge
# 4. Urządzenie B odpowiada ARP Reply (unicast)
# 5. Odpowiedź wróci tunelem EoIP do routera A

# Komendy weryfikacyjne na routerze:

# Tablica ARP - pokazuje nauczonych sąsiadów L2
/ip arp print

# Tablica MAC bridge - pokazuje porty i przypisane MAC
/interface bridge host print

# Statystyki bridge
/interface bridge print stats

# Monitorowanie ruchu na tunelu EoIP
/interface monitor-traffic eoip-to-84 once

Multicasty (IGMP, LLDP, BPDU)

# Multicastowe ramki Ethernet są przekazywane przez EoIP tak samo jak broadcasty
# Np. pakiet OSPF Hello (224.0.0.5) jest ramka Ethernet z docelowym
# adresem MAC multicastowym 01:00:5E:00:00:05

# Bridge może opcjonalnie włączyć IGMP snooping (ogranicza rozgłaszanie multicastu):
/interface bridge set bridge1 igmp-snooping=yes

# Jeśli w sieci L2 nie ma zewnętrznego queriera (np. routera PIM/IGMP proxy),
# włącz querier na łącznie jednym bridge w broadcast domain, inaczej
# wpisy w tablicy multicastowej wygasną po kilku minutach:
/interface bridge set bridge1 multicast-querier=yes

# Sprawdź tablice multicast bridge (MDB - Multicast DataBase):
/interface bridge mdb print

VLANy przez EoIP

# EoIP przekazuje ramki 802.1Q niezmiennie - VLAN przechodzi "przezroczyście"
# bez dodatkowej konfiguracji. Jeśli chcesz zakończyć VLAN na routerze (dać mu IP):

# Na routerze A - interfejs VLAN na bazie tunelu EoIP:
/interface vlan add name=vlan10 vlan-id=10 interface=eoip-to-84

# Adres IP dla VLAN 10:
/ip address add address=10.10.10.1/24 interface=vlan10

6. Testy na żywo – weryfikacja end-to-end (RouterOS 7.16.1)

Poniżej przedstawiam wyniki testów wykonanych na żywo na dwóch routerach MikroTik CHR z RouterOS 7.16.1 (stable):

6.1. Test tunelu GRE (warstwa 3)

Po skonfigurowaniu tunelu GRE na obu routerach sprawdzamy działanie przez ping końca tunelu:

# Z routera A - ping końca tunelu GRE (172.16.1.2 to tunel, nie fizyczne IP):
[admin@MikroTik] > /ping 172.16.1.2 count=5

  SEQ HOST        SIZE TTL TIME    STATUS
    0 172.16.1.2     56  64 267us
    1 172.16.1.2     56  64 575us
    2 172.16.1.2     56  64 743us
    3 172.16.1.2     56  64 736us
    4 172.16.1.2     56  64 853us
    sent=5 received=5 packet-loss=0% min-rtt=267us avg-rtt=634us max-rtt=853us

Dalej: routing między sieciami LAN obu routerów przez tunel GRE. Router A ma LAN 10.10.10.0/24 (na lo), router B ma LAN 10.20.20.0/24 (na lo). Trasy statyczne: na A dodajemy 10.20.20.0/24 przez bramę 172.16.1.2, na B dodajemy 10.10.10.0/24 przez bramę 172.16.1.1.

# Z routera A - ping sieci lokalnej B przez tunel GRE:
[admin@MikroTik] > /ping 10.20.20.1 count=5

  SEQ HOST        SIZE TTL TIME    STATUS
    0 10.20.20.1     56  64 534us
    1 10.20.20.1     56  64 898us
    2 10.20.20.1     56  64 873us
    3 10.20.20.1     56  64 771us
    4 10.20.20.1     56  64 715us
    sent=5 received=5 packet-loss=0% min-rtt=534us avg-rtt=758us max-rtt=898us

# Tablica routingu na routerze A (widać trasę aktywna):
[admin@MikroTik] > /ip route print
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC
#     DST-ADDRESS      GATEWAY     DISTANCE
;;; Do sieci B przez GRE
0  As 10.20.20.0/24    172.16.1.2         1
    DAc 172.16.1.0/30    gre-test           0
    DAc 192.168.53.0/24  ether1             0

6.2 Test tunelu EoIP (warstwa 2)

Po skonfigurowaniu EoIP + bridge-lan na obu routerach (tunnel-id=200, adresy 10.100.100.1/24 na A i 10.100.100.2/24 na B) testujemy komunikację L2:

# Z routera A - ping po L2 do routera B (przez EoIP/bridge-lan):
[admin@MikroTik] > /ping 10.100.100.2 count=5

  SEQ HOST         SIZE TTL TIME    STATUS
    0 10.100.100.2    56  64 507us
    1 10.100.100.2    56  64 296us
    2 10.100.100.2    56  64 727us
    3 10.100.100.2    56  64 955us
    4 10.100.100.2    56  64 729us
    sent=5 received=5 packet-loss=0% min-rtt=296us avg-rtt=642us max-rtt=955us

6.3. Dowód przekazywania broadcastu i multicastu przez EoIP

Najlepszy dowód: sniffer pakietów na routerze B (przechwytujący na interfejsie eoip-test) i wygenerowanie broadcast/multicast z routera A. Poniżej wynik:

Cel testu

1. Uruchamiamy sniffer pakietów na routerze B na interfejsie eoip-test
2. Z routera A wysyłamy broadcast ICMP (ping 10.100.100.255) i multicast ICMP (ping 224.0.0.1) na bridge-lan
3. Zatrzymujemy sniffer i oglądamy przechwycone ramki

Komendy testu

# Krok 1: na routerze B uruchom sniffer na interfejsie EoIP
/tool sniffer set filter-interface=eoip-test
/tool sniffer start

# Krok 2: z routera A wyślij broadcasty i multicasty
/ping 10.100.100.255 count=4 interface=bridge-lan
/ping 224.0.0.1 count=2 interface=bridge-lan

# Krok 3: na routerze B zatrzymaj sniffer i pokaż przechwycone pakiety
/tool sniffer stop
/tool sniffer packet print detail

Wynik sniffera na routerze B – dowód przekazywania L2 przez EoIP

 0 time=0.306 num=1 direction=rx src-mac=FE:2D:B4:D3:8C:9E
   dst-mac=01:80:C2:00:00:00 interface=eoip-test protocol=802.2 size=53

 1 time=2.182 num=2 direction=tx src-mac=FE:44:3F:F2:73:4F
   dst-mac=FF:FF:FF:FF:FF:FF interface=eoip-test
   src-address=10.100.100.2:5678 (discovery)
   dst-address=255.255.255.255:5678 (discovery) protocol=ip ip-protocol=udp

 2 time=2.182 num=3 direction=tx src-mac=FE:44:3F:F2:73:4F
   dst-mac=01:00:0C:CC:CC:CC interface=eoip-test protocol=802.2

 3 time=2.182 num=4 direction=tx src-mac=FE:44:3F:F2:73:4F
   dst-mac=01:80:C2:00:00:0E interface=eoip-test protocol=lldp

 5 time=3.506 num=6 direction=rx src-mac=FE:2D:B4:D3:8C:9E
   dst-mac=FF:FF:FF:FF:FF:FF interface=eoip-test
   src-address=10.100.100.1 dst-address=10.100.100.255
   protocol=ip ip-protocol=icmp size=70 ttl=255

 7 time=4.508 num=8 direction=rx src-mac=FE:2D:B4:D3:8C:9E
   dst-mac=FF:FF:FF:FF:FF:FF interface=eoip-test
   src-address=10.100.100.1 dst-address=10.100.100.255
   protocol=ip ip-protocol=icmp size=70 ttl=255

11 time=7.517 num=12 direction=rx src-mac=FE:2D:B4:D3:8C:9E
   dst-mac=01:00:5E:00:00:01 interface=eoip-test
   src-address=10.100.100.1 dst-address=224.0.0.1
   protocol=ip ip-protocol=icmp size=70 ttl=1

13 time=8.519 num=14 direction=rx src-mac=FE:2D:B4:D3:8C:9E
   dst-mac=01:00:5E:00:00:01 interface=eoip-test
   src-address=10.100.100.1 dst-address=224.0.0.1
   protocol=ip ip-protocol=icmp size=70 ttl=1

Interpretacja wyników – co pokazuje sniffer

Dowód na działanie bridge (tablica ARP)

# Tablica ARP na routerze A - widać MAC z drugiej strony tunelu:
/ip arp print where interface=bridge-lan
Flags: D - DYNAMIC; C - COMPLETE
#    ADDRESS         MAC-ADDRESS        INTERFACE   STATUS
0 DC 10.100.100.2    FE:44:3F:F2:73:4F  bridge-lan  reachable

# Z routera B:
/ip arp print where interface=bridge-lan
Flags: D - DYNAMIC; C - COMPLETE
#   ADDRESS       MAC-ADDRESS        INTERFACE   STATUS
0 DC 10.100.100.1  FE:2D:B4:D3:8C:9E  bridge-lan  reachable

7. Zasady zapory (firewall) dla tuneli

Tunele GRE i EoIP używają protokołu IP numer 47 (nie TCP, nie UDP). Aby tunele działały, firewall musi zezwalać na ten protokół.

Zezwolenie na ruch GRE/EoIP w firewallu

Router A (192.168.53.83)

# Zezwól na GRE/EoIP tylko od znanego routera
/ip firewall filter add chain=input \
    protocol=gre \
    src-address=192.168.53.84 \
    action=accept \
    comment="GRE/EoIP od routera B"

# Odrzuć GRE/EoIP z nieznanych źródeł
/ip firewall filter add chain=input \
    protocol=gre \
    action=drop \
    comment="Odrzucenie GRE z nieznanych zrodel"

Router B (192.168.53.84)

# Zezwól na GRE/EoIP tylko od znanego routera
/ip firewall filter add chain=input \
    protocol=gre \
    src-address=192.168.53.83 \
    action=accept \
    comment="GRE/EoIP od routera A"

# Odrzuć GRE/EoIP z nieznanych źródeł
/ip firewall filter add chain=input \
    protocol=gre \
    action=drop \
    comment="Odrzucenie GRE z nieznanych zrodel"

# Reguły firewall po dodaniu na routerze A:
/ip firewall filter print

#    CHAIN   ACTION   PROTOCOL   SRC-ADDRESS       COMMENT
0    input   accept   gre        192.168.53.84     GRE od routera B
1    input   drop     gre                             Odrzucenie GRE z nieznanych zrodel

Ochrona ruchu przepływającego przez tunel

Aby kontrolować jaki ruch może przepływać przez tunel (forward), dodaj reguły w chain forward:

# Zezwól na przepływ ruchu z sieci lokalnych przez tunel
/ip firewall filter add chain=forward \
    src-address=10.100.100.0/24 \
    out-interface=gre-tunnel-84 \
    action=accept \
    comment="Ruch z sieci A do B przez GRE"

/ip firewall filter add chain=forward \
    src-address=172.16.1.0/30 \
    dst-address=10.100.100.0/24 \
    in-interface=gre-tunnel-84 \
    action=accept \
    comment="Ruch z sieci B do A przez GRE"

8. Szyfrowanie – IPsec z tunelami

Oprócz prostej opcji ipsec-secret (pre-shared key), można skonfigurować pełne IPsec transport mode dla tuneli GRE lub EoIP. Jest to zalecane gdy tunele przechodzą przez sieci publiczne (internet).

Szyfrowanie automatyczne (ipsec-secret)

Można automatycznie zaszyfrować tunel GRE lub EoIP używając wbudowanej opcji IPsec. RouterOS sam utworzy peer, proposal i policy (tryb transport, protocol=gre):

# Dodanie klucza IPsec do tunelu GRE (szyfruje cały tunel)
/interface gre set gre-tunnel-84 ipsec-secret="moj-tajny-klucz-123"

# Lub dodanie klucza IPsec do tunelu EoIP
/interface eoip set eoip-to-84 ipsec-secret="moj-tajny-klucz-123"

IPsec transport mode dla GRE

## Router A ##

# Utwórz peer IPsec.
# UWAGA: "transport" nie jest wartością exchange-mode (są do wyboru
# aggressive|base|main|ike2). Tryb transportowy ustala się w policy
# parametrem tunnel=no (poniżej).
/ip ipsec peer add \
    name=peer-to-84 \
    address=192.168.53.84/32 \
    local-address=192.168.53.83 \
    exchange-mode=main \
    passive=no

# Utwórz proposal
/ip ipsec proposal add name=prop-to-84 \
    auth-algorithms=sha256 \
    enc-algorithms=aes-256-cbc \
    pfs-group=modp2048

# Utwórz profil
/ip ipsec profile add name=prof-to-84 \
    hash-algorithm=sha256 \
    enc-algorithm=aes-256 \
    dh-group=modp2048 \
    lifetime=8h \
    dpd-interval=120s \
    dpd-maximum-failures=5

# Utwórz ID peer (local)
/ip ipsec identity add peer=peer-to-84 \
    auth-method=pre-shared-key \
    secret="moj-bardzo-tajny-klucz"

# Utwórz policy - co zaszyfrować.
# tunnel=no = tryb TRANSPORT (szyfrujemy ruch GRE/gre między adresami peerów).
# tunnel=yes = tryb TUNELOWY (dodaje dodatkowy nagłówek IP z adresami
# SĄ) - NIE tego chcemy dla GRE.
/ip ipsec policy add \
    src-address=192.168.53.83 \
    dst-address=192.168.53.84 \
    protocol=gre \
    action=encrypt \
    level=require \
    tunnel=no \
    sa-src-address=192.168.53.83 \
    sa-dst-address=192.168.53.84 \
    proposal=prop-to-84 \
    peer=peer-to-84

Na routerze B konfiguracja jest lustrzanym odbiciem (zamień src-address z dst-address).

9. MTU i problem fragmentacji

Odpowiednie ustawienie MTU jest krytyczne dla poprawnego działania tuneli. Każdy tunel dodaje overhead (dodatkowe bajty nagłówków), co zmniejsza dostępne MTU dla danych użytkownika.

Overhead tunelów

Zalecane ustawienia MTU

# Dla tunelu GRE - ustawienie explicit MTU
/interface gre set gre-tunnel-84 mtu=1476

# Dla tunelu EoIP - ustawienie explicit MTU
/interface eoip set eoip-to-84 mtu=1458

# Jeśli tunel przechodzi przez PPPoE lub inny tunel z mniejszym MTU:
# Np. PPPoE MTU = 1492, to MTU tunelu = 1492 - 24 (GRE) = 1468
/interface gre set gre-tunnel-84 mtu=1468

Testowanie MTU

# Test ping z dużym pakietem i bitem DF (Don't Fragment)
# Na routerze A - testowanie do końca tunelu:

# Test z pełnym pakietem (powinien przejść):
/ping 172.16.1.2 size=1448 do-not-fragment=yes

# Test z za dużym pakietem (powinien się nie powieść):
/ping 172.16.1.2 size=1449 do-not-fragment=yes

# Na Linux/Windows z testowaniem PMTUD (Path MTU Discovery):
# ping -M do -s 1448 172.16.1.2    (powinien przejść)
# ping -M do -s 1449 172.16.1.2    (powinien się nie powieść)

10. Diagnostyka i rozwiązywanie problemów

Częsty problem i rozwiązania

Narzędzia diagnostyczne

# Przegląd wszystkich interfejsów tunelowych:
/interface gre print stats
/interface eoip print stats

# Monitorowanie ruchu na interfejsie (jednorazowy odczyt):
/interface monitor-traffic gre-tunnel-84 once
/interface monitor-traffic eoip-to-84 once

# Sprawdzanie tablicy ARP (sąsiedzi L2):
/ip arp print

# Sprawdzanie tablicy MAC bridge:
/interface bridge host print

# Sprawdzanie logów (czy są błędy):
/log print where topics~"interface"

# Sprawdzanie stanu IPsec (jeśli szyfrowane):
/ip ipsec active-peers print
/ip ipsec installed-sa print

# Sprawdzanie tras (czy brama tunelu jest aktywna):
/ip route print stats

# Pełna diagnostyka interfejsu:
# UWAGA: nie istnieje komenda "gre monitor" ani "eoip monitor".
# Jednorazowy pomiar ruchu robi się tak jak wyżej (monitor-traffic ... once),
# a stan tunelu sprawdza się przez print + kept (+ keepalive) + counters.
/interface gre print stats
/interface eoip print stats

Kompletny zestaw komend do kopiowania – Scenariusz 1 (GRE L3)

Router A (192.168.53.83)

#### KONFIGURACJA TUNELU GRE L3 - ROUTER A ####

# 1. Utwórz interfejs GRE
/interface gre add name=gre-tunnel-84 remote-address=192.168.53.84 local-address=192.168.53.83 keepalive=10s,10 comment="Tunel GRE do routera B"

# 2. Przypisz adres IP tunelu
/ip address add address=172.16.1.1/30 interface=gre-tunnel-84 comment="Tunel GRE - koniec A"

# 3. Utwórz trasę do sieci zdalnej
/ip route add dst-address=10.20.20.0/24 gateway=172.16.1.2 comment="Trasa do sieci B przez GRE"

# 4. Firewall - zezwól na GRE
/ip firewall filter add chain=input protocol=gre src-address=192.168.53.84 action=accept comment="GRE od routera B" place-before=0

# 5. (Opcjonalnie) Szyfrowanie IPsec
/interface gre set gre-tunnel-84 ipsec-secret="moj-tajny-klucz" allow-fast-path=no

Router B (192.168.53.84)

#### KONFIGURACJA TUNELU GRE L3 - ROUTER B ####

# 1. Utwórz interfejs GRE
/interface gre add name=gre-tunnel-83 remote-address=192.168.53.83 local-address=192.168.53.84 keepalive=10s,10 comment="Tunel GRE do routera A"

# 2. Przypisz adres IP tunelu
/ip address add address=172.16.1.2/30 interface=gre-tunnel-83 comment="Tunel GRE - koniec B"

# 3. Utwórz trasę do sieci zdalnej
/ip route add dst-address=10.10.10.0/24 gateway=172.16.1.1 comment="Trasa do sieci A przez GRE"

# 4. Firewall - zezwól na GRE
/ip firewall filter add chain=input protocol=gre src-address=192.168.53.83 action=accept comment="GRE od routera A" place-before=0

# 5. (Opcjonalnie) Szyfrowanie IPsec
/interface gre set gre-tunnel-83 ipsec-secret="moj-tajny-klucz" allow-fast-path=no

Kompletny zestaw komend do kopiowania – Scenariusz 2 (EoIP L2)

Router A (192.168.53.83)

#### KONFIGURACJA TUNELU EoIP L2 - ROUTER A ####

# 1. Utwórz interfejs EoIP
/interface eoip add name=eoip-to-84 remote-address=192.168.53.84 tunnel-id=100 comment="Tunel EoIP L2 do routera B"

# 2. Ustaw unikalny MAC (dla bridgowania)
/interface eoip set eoip-to-84 mac-address=00:00:5E:80:00:01

# 3. Utwórz bridge z RSTP
/interface bridge add name=bridge1 protocol-mode=rstp comment="Bridge L2 z EoIP"

# 4. Dodaj porty do bridge
/interface bridge port add bridge=bridge1 interface=eoip-to-84 comment="EoIP tunel L2"
/interface bridge port add bridge=bridge1 interface=ether2 comment="Port LAN (nie WAN/ether1!)"
# UWAGA: RouterOS 7 mógł automatycznie dodać do bridge ether1 (port z IP).
# Sprawdź i usuń: /interface bridge port remove [find where interface=ether1]

# 5. Przypisz IP do bridge (NIE do portów!)
/ip address add address=10.100.100.1/24 interface=bridge1 comment="Siec lokalna A"

# 6. Firewall - zezwól na EoIP/GRE
/ip firewall filter add chain=input protocol=gre src-address=192.168.53.84 action=accept comment="EoIP od routera B" place-before=0

# 7. (Opcjonalnie) Szyfrowanie IPsec
/interface eoip set eoip-to-84 ipsec-secret="moj-tajny-klucz" allow-fast-path=no

Router B (192.168.53.84)

#### KONFIGURACJA TUNELU EoIP L2 - ROUTER B ####

# 1. Utwórz interfejs EoIP
/interface eoip add name=eoip-to-83 remote-address=192.168.53.83 tunnel-id=100 comment="Tunel EoIP L2 do routera A"

# 2. Ustaw unikalny MAC (dla bridgowania)
/interface eoip set eoip-to-83 mac-address=00:00:5E:80:00:02

# 3. Utwórz bridge z RSTP
/interface bridge add name=bridge1 protocol-mode=rstp comment="Bridge L2 z EoIP"

# 4. Dodaj porty do bridge
/interface bridge port add bridge=bridge1 interface=eoip-to-83 comment="EoIP tunel L2"
/interface bridge port add bridge=bridge1 interface=ether2 comment="Port LAN (nie WAN/ether1!)"
# UWAGA: RouterOS 7 mógł automatycznie dodać do bridge ether1 (port z IP).
# Sprawdź i usuń: /interface bridge port remove [find where interface=ether1]

# 5. Przypisz IP do bridge (NIE do portów!)
/ip address add address=10.100.100.2/24 interface=bridge1 comment="Siec lokalna B"

# 6. Firewall - zezwól na EoIP/GRE
/ip firewall filter add chain=input protocol=gre src-address=192.168.53.83 action=accept comment="EoIP od routera A" place-before=0

# 7. (Opcjonalnie) Szyfrowanie IPsec
/interface eoip set eoip-to-83 ipsec-secret="moj-tajny-klucz" allow-fast-path=no

11. Podsumowanie i szybka ściąga

Co przekazuje każdy tunel?

Szybka Ściąga Komend

Zalecenia końcowe

1. Zawsze używaj keepalivena tunelach GRE i EoIP. Bez keepalive, interfejs tunelu pozostaje „running” nawet gdy zdalny koniec jest niedostępny, co prowadzi do blackholingu ruchu.
2. Włącz RSTP na wszystkich bridge, które mają więcej niż jeden port. Chroni przed pętlami L2 i broadcast storm.
3. Ustaw unikalne MAC na tunelach EoIP dodawanych do bridge, aby algorytmy MAC learning działały poprawnie.
4. Konfiguruj firewall aby zezwalać na GRE (protocol 47) tylko od znanych źródeł. Bez tego reguły tunele mogą nie działać.
5. Testuj MTUpingiem z bitem DF (Don’t Fragment), aby upewnić się, że pakiety nie są fragmentowane.
6. Nie mieszaj EoIP z GRE do tego samego celu. GRE służy do routingu L3, EoIP do bridgowania L2.
7. Szyfruj tunelegdy przechodzą przez sieci publiczne. Używaj IPsec transport mode lub przynajmniej ipsec-secret.
8. Włącz logowaniei monitorowanie: /log add topics=interface aby rejestrować zmiany stanu interfejsów.