MikroTik - Forgalom tiltása bridge-bridge között

Üdvözlök Mindenkit!

Adott egy MikroTik - RB4011iGS+RM router, melyen létrehozok két bridge interface-t.

bridge1 -> ether2 + ether3 + ether4 + ether5
bridge2 -> ether6 + ether7 + ether8 + ether9

A két bridge interface különböző alhálózatot szolgál ki IPv4 címtartományban, melynek következtében elvben nem látják egymást, gyakorlatban viszont az alapértelmezett routing funkció miatt a csomagok akadály nélkül közlekednek az egyik bride interface-ről a másikra és fordítva. Mivel nem tudok olyanról, hogy adott interface-ek között le lehetne tiltani a routing funkciót, így marad a bridge alatti, vagy a tűzfalból történő szabályozás. Mivel az eszközben egy buta switch chip van, így VLAN-t nem szeretnék használni. A probléma az, hogy akár a bridge alatt, akár a tűzfalban próbálom beállítani a két bridge közötti forgalom eldobását semmi sem történik, minden megy tovább, mint ha mi sem történt volna. Olyan, mint ha az eszköz nem dolgozná fel valamiért a forward szabályokat (legalábbis a szóban forgó interface-ek esetében). Bridge alatt a tűzfal használatát természetesen engedélyeztem.

Volt már valakinek hasonló problémája más típusú eszközön? Van ötletetek a hibára?

Segítségeteket előre is köszönöm!

Üdv: LittleT

Hozzászólások

Erre sok mód van, még routing szinten is (lásd IP -> Routes -> Rules).
Működnie kellene a tűzfal szabályoknak is, ezért jó lenne ha megírnád hogy most mivel próbálkozol pontosan.. 

Mivel ez egy router, a benne lévő switch chip tudása szerintem nem releváns, pláne ebben az esetben.

Ha VLAN-okat csinálnál, layer3-on a default route miatt pont ugyan így elérnék egymás az alhálózatok, mint most, a "sima" bridge-ek esetében.

A legegyszerűbb, ha a normál layer3 tűzfalban tiltod IP tartomány vagy interface alapon a kommunikációt. Nem a route-olást kell tiltani (nem is tudom, hogy ez értelmes kifejezés vagy sem), hanem az adott irányú forgalmat.

Csatlakozva az előttem szólóhoz, jó lenne látni, most mi az, ami nem működik. Milyen szabályok vannak a tűzfalban?

Ennek működnie kell.

;;; disable to  communicate  primary network
chain=forward action=drop src-address=192.168.XXX.0/24 dst-address=192.168.YYY.0/24 log=no log-prefix=""

;;; disable to  communicate  secondary network
chain=forward action=drop src-address=192.168.YYY.0/24 dst-address=192.168.XXX.0/24 log=no log-prefix=""

Nincs a világon se jó, se rossz. A gondolkodás teszi azzá... (W. Shakespeare)

Fura pedig mennie kéne.

 Nálam ugyan vlan-okkal vannak elválaszva a hálók, de a fenti példa működik, de belekukkoltam anyámék routerébe ahol viszont két port két külön ip cimen van, hasonloan a tiédhez(csak nem bridge)  és ott is működik az alábbi szabály.
 ez egy 433as mikrotik 3 portal: 1wan 1belső hálo 1 pedig megy a szomszédnak. 

ime a szabály:

  chain=forward action=drop src-address=192.168.3.0/24 dst-address=192.168.2.0/24 log=no log-prefix=""

Le kell nyelni a békát és bekapcsolni a bridge VLAN filteringet. Utána fog menni a fenti szabály.

Szerintem ez a forgalom nem jut el a CPU-ig es ezert nem vonatkozik ra a tuzfalszabaly. Lattam h feljebb kerdeztek a fastpath-t, igazabol bridge-bridge kozott layer 2 forgalom van es azt nem tuzfallal szurjuk hanem bridge firewallal: https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#Bridge_Firewall de ez MAC cimekkel megy nem IP cimekkel. Ha IP cimek alapjan akar szurni, akkor 1 ISO/OSI reteggel feljebb kell vinni a dolgot es ehhez kell a bridge vlan filtering.

Az RB4011-nél az OP által megjelölt 2-3-4-5 és 6-7-8-9 portok (a két bridge portjai) külön switch chipre vannak kötve, és a kettő között a CPU az átjárás. Szóval ebben a vázolt felállásban mindenképp átmegy a CPU-n a forgalom, fizikailag nem lehet másképp. Meg egyébként minden forgalom átmegy a CPU-n, ha nem egy bridge-en belül vannak a portok (akkor is, ha az adott két port fizikailag ugyan arra a switch chip-re kapcsolódik.). Szóval a két bridge közötti forgalom mindenképp átmegy a CPU-n.

Azt viszont nem értem, hogy a bridge VLAN filtering hogyan emeli layer3-ra a dolgot, hogy IP alapon szűrhetővé váljon (mert a VLAN tag-elt forgalom az ugyan úgy layer2 mint a VLAN tag-ek nélküli forgalom), mikor az kizárólag annyit szabályoz (erősen egyszerűsítve), hogy az adott bridge-en csak a definiált VLAN-ok közlekedhetnek, vagy bármilyen VLAN tag átmehet.

Persze bridge filter-rel is meg lehet oldani, hogy a két bridge-en állítok kézzel admin MAC címet, és a megfelelő bridge-re felveszem az input vagy output chain-en a másik bridge MAC címével a DROP-ot. De szerintem ennek RB4011-nél semmi értelme, mikor ennek a switch chip-je (RTL8367) nem tud filter szabályokat kezelni, így a bridge filter-t is CPU-ból valósítja meg ez a router, így kézenfekvőbb az /ip firewall filter megoldás szerintem.

Full disclosure: Nekem ilyen routerem van itthon és bridge vlan filteringgel működik kb ugyanez a tűzfal szabály. A helyzet az hogy bridge vlan filtering nélkül szerintem nem lehet korlátozni a bridge-ek közötti forgalmat (de amúgy igazad van :))

Itt pusztán arról van szó hogy emberünk nem akarja bekapcsolni a bridge vlan filteringet mert tudja hogy az kikapcsolja a hardware offloadingot, de a 4011 elég erős ahhoz hogy szoftverből lekezelje a gigabites linkeket. 

Szerkesztve: 2021. 01. 15., p - 13:17

Mikrotik linux tűzfalat használ ( iptables ), ennek kell érteni a működését.
Azért engedi át, mert a "Filter" tábla "Forward" ága "Accept"-re van állítva, így minden írányba megy a forgalom ( Layer 3 ).

Ennek a kimenetét nézd meg:

/ip firewall filter print

 

https://manpages.debian.org/buster/iptables/iptables.8.en.html
https://netfilter.org/documentation/index.html
https://en.wikipedia.org/wiki/Reserved_IP_addresses

 

Itt egy kis segítség, én ezt a "Linux alapkonfigot" használom amit kibővítek,majd átírom Mikrotik féle "kódra".

Filter tábla

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:]
#
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
#
-A INPUT -i lo -j ACCEPT
#
#
#
# eth0: 192.168.1.1, LAN 192.168.1.0/24
#
-A INPUT -i eth0 -s 0.0.0.0/8 -j DROP
-A INPUT -i eth0 -s 10.0.0.0/8 -j DROP
-A INPUT -i eth0 -s 100.64.0.0/10 -j DROP
-A INPUT -i eth0 -s 127.0.0.0/8 -j DROP
-A INPUT -i eth0 -s 169.254.0.0/16 -j DROP
-A INPUT -i eth0 -s 172.16.0.0/12 -j DROP
##-A INPUT -i eth0 -s 192.168.0.0/16 -j DROP
#
-A INPUT -i eth0 -d 0.0.0.0/8 -j DROP
-A INPUT -i eth0 -d 10.0.0.0/8 -j DROP
-A INPUT -i eth0 -d 100.64.0.0/10 -j DROP
-A INPUT -i eth0 -d 127.0.0.0/8 -j DROP
-A INPUT -i eth0 -d 169.254.0.0/16 -j DROP
-A INPUT -i eth0 -d 172.16.0.0/12 -j DROP
##-A INPUT -i eth0 -d 192.168.0.0/16 -j DROP
#
## -A INPUT -i eth0 -j DROP
#
#
#
# eth1: WAN-ipv4: 5.5.5.5
#
-A INPUT -i eth1 -s 0.0.0.0/8 -j DROP
-A INPUT -i eth1 -s 10.0.0.0/8 -j DROP
-A INPUT -i eth1 -s 100.64.0.0/10 -j DROP
-A INPUT -i eth1 -s 127.0.0.0/8 -j DROP
-A INPUT -i eth1 -s 169.254.0.0/16 -j DROP
-A INPUT -i eth1 -s 172.16.0.0/12 -j DROP
-A INPUT -i eth1 -s 192.168.0.0/16 -j DROP
#
-A INPUT -i eth1 -d 0.0.0.0/8 -j DROP
-A INPUT -i eth1 -d 10.0.0.0/8 -j DROP
-A INPUT -i eth1 -d 100.64.0.0/10 -j DROP
-A INPUT -i eth1 -d 127.0.0.0/8 -j DROP
-A INPUT -i eth1 -d 169.254.0.0/16 -j DROP
-A INPUT -i eth1 -d 172.16.0.0/12 -j DROP
-A INPUT -i eth1 -d 192.168.0.0/16 -j DROP
#
## -A INPUT -i eth0 -j DROP
#
#
#
# SSH #
#
-A INPUT -i eth0 -d 5.5.5.5 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
#
#
#
# Ping-t engedjük #
#
-A INPUT -p icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -j DROP
#
#
#
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -j DROP
#
#
#
-A FORWARD -s 192.168.1.0/24 -j ACCEPT
-A FORWARD -d 192.168.1.0/24 -j ACCEPT
-A FORWARD -j DROP
#
#
#
-A OUTPUT -o lo -j ACCEPT
#
#
#
# eth0: 192.168.1.1, LAN 192.168.1.0/24
#
-A OUTPUT -o eth0 -s 0.0.0.0/8 -j DROP
-A OUTPUT -o eth0 -s 10.0.0.0/8 -j DROP
-A OUTPUT -o eth0 -s 100.64.0.0/10 -j DROP
-A OUTPUT -o eth0 -s 169.254.0.0/16 -j DROP
-A OUTPUT -o eth0 -s 172.16.0.0/12 -j DROP
-A OUTPUT -o eth0 -s 192.168.1.0/24 -j ACCEPT
-A OUTPUT -o eth0 -s 192.168.0.0/16 -j DROP
#
-A OUTPUT -o eth0 -d 0.0.0.0/8 -j DROP
-A OUTPUT -o eth0 -d 10.0.0.0/8 -j DROP
-A OUTPUT -o eth0 -d 100.64.0.0/10 -j DROP
-A OUTPUT -o eth0 -d 169.254.0.0/16 -j DROP
-A OUTPUT -o eth0 -d 172.16.0.0/12 -j DROP
-A OUTPUT -o eth0 -d 192.168.1.0/24 -j ACCEPT
-A OUTPUT -o eth0 -d 192.168.0.0/16 -j DROP
#
-A OUTPUT -o eth0 -j DROP
#
#
#
# eth1: WAN-ipv4: 5.5.5.5
#
-A OUTPUT -o eth1 -s 0.0.0.0/8 -j DROP
-A OUTPUT -o eth1 -s 10.0.0.0/8 -j DROP
-A OUTPUT -o eth1 -s 100.64.0.0/10 -j DROP
-A OUTPUT -o eth1 -s 169.254.0.0/16 -j DROP
-A OUTPUT -o eth1 -s 172.16.0.0/12 -j DROP
-A OUTPUT -o eth1 -s 192.168.0.0/16 -j DROP
-A OUTPUT -o eth1 -s 5.5.5.5 -j ACCEPT
#
-A OUTPUT -o eth1 -d 0.0.0.0/8 -j DROP
-A OUTPUT -o eth1 -d 10.0.0.0/8 -j DROP
-A OUTPUT -o eth1 -d 100.64.0.0/10 -j DROP
-A OUTPUT -o eth1 -d 169.254.0.0/16 -j DROP
-A OUTPUT -o eth1 -d 172.16.0.0/12 -j DROP
-A OUTPUT -o eth1 -d 192.168.0.0/16 -j DROP
-A OUTPUT -o eth1 -d 5.5.5.5 -j ACCEPT
#
-A OUTPUT -o eth0 -j DROP
#
#
#
-A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -j drop

NAT tábla

*nat
:INPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
#
#
#
-P INPUT ACCEPT
-P PREROUTING ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
#
#
#
-A POSTROUTING -o eth1 -s 192.168.1.0/24 -j MASQUERADE

Szerintem ezért kértük többen, hogy áthassuk azt a konfigot ami most nem működik. Aki Mikrotik-et napi szinten használ, az úgy kezdi a beállítást, hogy INPUT DROP ALL, FORWARD DROP ALL, és utána jöhet, hogy mit szabad. Aztán legtöbben ebből is indulunk ki, hogy biztosan ott vannak a DROP-ok...

Mondjuk itt elhangzottak explicit DROP szabályok, amik elvileg megoldanák a kérdést, de ugye nem tudjuk, előttük mi van. Simán lehet, hogy van egy nagyobb hatókörű ACCEPT, és ugye itt first math működés van, ha átengedte, akkor később nincs már mit eldobni.

"Aki Mikrotik-et napi szinten használ, az úgy kezdi a beállítást, hogy INPUT DROP ALL, FORWARD DROP ALL, és utána jöhet, hogy mit szabad. "

Ezzel jól ki is zárnám magam. Az első matchig megy, mindent eldob, helo van.

Tudtommal a mikrotik nem tud default policyt alkalmazni, ami iptablesben lehet accept vagy drop.

Az azért hihetetlen, hogy mindig a kötözködés az első.

TERMÉSZETESEN nem úgy értettem (és biztos vagyok benne, hogy senki más sem úgy értette), hogy beírom ezt a két szabályt legelsőre, és utána nekiugrok MAC-Winbox-al csatlakozva visszaengedni magam...

Hanem úgy (szerintem logikusan, ezért nem is írtam ki, mert nem tankönyvet írtam, hanem hosszászólást), hogy felveszem az általam preferált konfig módhoz tartozó INPUT ACCEPT szabályt, majd ezután azonnal a DROP szabályok jönnek, hogy biztosan eldobjak mindent, amit nem engedtem át.

Ha azt írom, hogy én úgy kezdem a tűzfalat, hogy

/ip service set ssh port=8022
/ip firewall filter add disabled=no chain=input protocol=tcp port=8022 action=accept
/ip firewall filter add disabled=no chain=input action=drop
/ip firewall filter add disabled=no chain=forward action=drop

Akkor meg be lehetne írni, hogy "én nem teszem az SSH-t 8022-re", meg "én nem engedek SSH-t csak jumphost-ról", "én csak az internet felől DROP-olok mindent", stb., stb.

De nem ez a lényeg, nem releváns. Hanem, hogy mivel DEFAULT ACCEPT van minden chain-en Mikrotik esetében, ezért a konfigurálás legelején már fel kell venni a DROP szabályokat, hogy le ne maradjon...