Sprawdźmy dopasowania interfejsów, to znaczy czy jesteśmy w stanie filtrować ruch na br0, na podstawie interfejsu.
Niestety żadne z tych dopasowań nie przechwytuje pakietów. Jeśli interfejs nie pracuje w warstwie 3 OSI, iptables nie wychwyci na nim żadnego ruchu. Możliwe jest jednak przechwycenie ruchu na takim
interfejsie poprzez moduł physdev.
Poprzez takie dopasowanie iptables wychwycił pakiety na interfejsie bridża br0.
Sprawdźmy w końcu czy iptables potrafi zablokować ruch na br0.
Ping między maszynami przestał odpowiadać. Usuńmy tę regułę i sprawdźmy to samo dla innych dopasowań.
Zauważmy, w jakich warstwach działają switche linuksowe brctl, a w jakiej iptables.
Są tylko dwa sposoby aby ramki/pakiety przechodziły przez łańcuchy PREROUTING, FORWARD i POSTROUTING iptables. Pierwszy kiedy ramki przechodzą przez bridż brctl, z włączonym przekazywaniem (bridge-nf-call-iptables), łańcuch iptables jest wywoływany przez kod bridża. Drugi gdy uruchomimy routing dla tych pakietów.
Rys. Przykładowa sieć pracująca w warstwie 2 (kolor niebieski)
i 3 OSI (kolor zielony)
W przedstawionej powyżej topologii1, ruch na moście br0 jest obsługiwany przez ebtables, iptables otrzymuje go tylko dzięki włączonemu przekazywaniu br-nf-call-ipt. Natomiast ruch pomiędzy br0 a interfejsem eth0 jest już realizowany w warstwie sieciowej więc przez iptables, poprzez routing NAT.
Różnica między siecią opartą na linuksowych switchach brctl, a switchach VDE
Omówione wcześniej metody/systemy łączenia maszyn w sieci (mosty linuksowe brctl, VDE oraz Open vSwitch) działają w warstwie L2, jednak w przypadku VDE iptables nie ma dostępu do tej warstwy. Brctl oraz OVS pozwalają iptables „przedostać się” do bridży i filtrować na nich ruch.
Sieć VDE operuje w przestrzeni użytkownika (userspace), natomiast mosty brctl działają w przestrzeni jądra (kernel space). Innymi słowy oznacza to, że iptables „nie widzi” pakietów przesyłanych w sieci VDE, nie może więc filtrować ruchu w takiej sieci.
