IMPORTANT: Per accedir als fitxer de subversion: http://acacha.org/svn (sense password). Poc a poc s'aniran migrant els enllaços. Encara però funciona el subversion de la farga però no se sap fins quan... (usuari: prova i la paraula de pas 123456)

Vegeu també Bridges amb Linux

Network bridging és l'acció que realitzen alguns dispositius de xarxa (bridges) que permet a dos o més xarxes (o segments de xarxa) crear una xarxa agregada. Bridging és diferent del Routing (Encaminament) que permet comunicar-se entre si dos xarxes però sent les xarxes comunicades independents entre sí (amb Bridging les dos xarxes comunicades passen a ser una sola xarxa). En el model OSI els bridges treballes a les dos primeres capes (capa física i capa d'enllaç)

Existeixen les següents tecnologies de Bridging:

Transparent bridging va ser originalment originally developed by the Digital Equipment Corporation (DEC) in the 1980s

Ethernet Bridging

Un Bridge connecta diferents segments de xarxa permeten que el trànsit passi entre aquests segments. D'aquesta forma la mida màxima de la xarxa es pot ampliar.

Un bridge transparent (aka Transparent Bridge o Learning bridge) aprèn les adreces MAC de les estacions connectades al segment o segments de xarxa als que està connectat el bridge examinant els paquets que rep. A aquest funcionament de l'anomena Promiscuous Mode i es diu que els ports del bridge funcionen en Learning Mode ja que a partir de la informació que reben els creen les Forwarding Tables una llista d'adreces MAC (vegeu brctl showmacs) apreses, en quin port s'han vist i també sovint la informació relacionada amb l'Aging.

Al procediment se l'anomena Bridge transparent, pel fet que el bridge és transparent (no es detectable) per les estacions de treball, és a dir tota aquesta tasca es realitza sense haver de fer cap canvi en les estacions de treball. A més el bridge també té adreces MAC en cada port. Aquestes adreces són invisibles per al dispositius de la xarxa i el frames no s'alteren de cap manera.

NOTA: Observeu que quan s'encamina un paquet en capa 3 si que se li modifica el contingut.

Les taules de forwarding poden créixer indefinidament ja que les xarxes tot i que pot ser no són especialment dinàmiques ni molt menys solen ser estàtiques: els ordinadors poden canviar de port, es poden connectar més bridges o commutadors a la xarxa, pot haver-hi segments WIFI on a priori es poden connectar infinitat de dispositius diferents, etc... Per aquest raó s'aplica un procediment conegut com a Aging on les adreces que fa més temps que estan a la taula d'adreces MAC són esborrades de la memòria (normalment el temps és un 300 segons)

Amb un bridge se sol connectar xarxes que utilitzin el mateixos protocols de capa física i de capa d'enllaç. No hi ha cap procediment d'encaminament (ni descobriment de rutes ni selecció de rutes).

El problema d'un bridge és la latència que introdueix (aprox un 20-30% en protocols acknowledgement-oriented com TCP) o de un 10-20% en protocols sliding window (UDP?). L'altre problema és l'augment del trànsit de broadcast i la possibilitat de tormentes de broadcast

Recursos:

Forwarding tables

Són les bases de dades que permeten als bridges prendre decisions de forwarding en capa 2.

NOTA: Cisco les anomena CAM tables (Content Addressable Memory)

TODO: Posar la gràfica que apareix a l'enllaç de més abaix.
Davidginovart bridge.png

Sistemes operatius

Linux

Consulteu Bridges amb Linux

RouterOS

Consulteu RouterOS Bridging


ebtables

ebtables és l'equivalent en TCP/IP d'iptables però en comptes de a nivell de xarxa (aka nivell IP o network Layer) a nivell d'enllaç (aka bridge o Link Layer).

IMPORTANT: Cal tenir en compte que ebtables a diferència de iptables no és un "firewall" stateful

Configuració del nucli

Quines opcions suporta el nostre nucli:

A un Proxmox

$ cat "/boot/config-`uname -r`" | grep EBTABLES
CONFIG_BRIDGE_NF_EBTABLES=m
$ cat "/boot/config-`uname -r`" | grep BROUTE
CONFIG_BRIDGE_EBT_BROUTE=m

La m vol dir suportat per mòdul.

$ cat "/boot/config-`uname -r`" | grep EBT
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_IP6=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_BRIDGE_EBT_NFLOG=m 

Configuració de /proc:

$ cat /proc/sys/net/bridge/bridge-nf-          <-- TABULAR DOS COPS
bridge-nf-call-arptables       bridge-nf-call-iptables        bridge-nf-filter-vlan-tagged   
bridge-nf-call-ip6tables       bridge-nf-filter-pppoe-tagged  

els fitxers són:

/proc/sys/net/bridge/bridge-nf-call-arptables
/proc/sys/net/bridge/bridge-nf-call-ip6tables
/proc/sys/net/bridge/bridge-nf-call-iptables
/proc/sys/net/bridge/bridge-nf-filter-pppoe-tagged
/proc/sys/net/bridge/bridge-nf-filter-vlan-tagged

Per consultar els valors:

$ cat /proc/sys/net/bridge/bridge-nf-filter-vlan-tagged
0

O per veure'ls tots:

$ cat /proc/sys/net/bridge/*
0
0
0
0
0

També es pot configurar amb sysctl

net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0

Recursos

Instal·lació

Per instal·lar el suport per ebtables:

$ sudo apt-get install ebtables

Fitxers instal·lats

$ dpkg -L ebtables
/.
/etc
/etc/ethertypes
/etc/init.d
/etc/init.d/ebtables
/etc/default
/etc/default/ebtables
/sbin
/sbin/ebtables
/lib
/lib/ebtables
/lib/ebtables/libebt_802_3.so
/lib/ebtables/libebt_among.so
/lib/ebtables/libebt_arp.so
/lib/ebtables/libebt_arpreply.so
/lib/ebtables/libebt_ip.so
/lib/ebtables/libebt_ip6.so
/lib/ebtables/libebt_limit.so
/lib/ebtables/libebt_log.so
/lib/ebtables/libebt_mark.so
/lib/ebtables/libebt_mark_m.so
/lib/ebtables/libebt_nat.so
/lib/ebtables/libebt_nflog.so
/lib/ebtables/libebt_pkttype.so
/lib/ebtables/libebt_redirect.so
/lib/ebtables/libebt_standard.so
/lib/ebtables/libebt_stp.so
/lib/ebtables/libebt_ulog.so
/lib/ebtables/libebt_vlan.so
/lib/ebtables/libebtable_broute.so
/lib/ebtables/libebtable_filter.so
/lib/ebtables/libebtable_nat.so
/lib/ebtables/libebtc.so
/usr
/usr/share
/usr/share/man
/usr/share/man/man8
/usr/share/man/man8/ebtables.8.gz
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/ebtables
/usr/share/doc
/usr/share/doc/ebtables
/usr/share/doc/ebtables/THANKS
/usr/share/doc/ebtables/copyright
/usr/share/doc/ebtables/changelog.gz
/usr/share/doc/ebtables/changelog.Debian.gz

Fitxers de configuració

/etc/init.d/ebtables

Script System V que s'encarrega d'executar el servei ebtables

NOTA: Observeu la diferència a iptables que és un servei integrat al nucli del sistema i no s'encén ni s'apaga de la forma habitual que ho fan els serveis a Linux!

/etc/default/ebtables
$ cat /etc/default/ebtables
# Unload modules on restart and stop
#   Value: yes|no,  default: yes
# This option has to be 'yes' to get to a sane state for a firewall
# restart or stop. Only set to 'no' if there are problems unloading netfilter
# modules.
EBTABLES_MODULES_UNLOAD="yes"

# Load firewall rules on system startup.
#   Value: yes|no,  default: no
# Restores the ebtables rulesets from the last saved state when the
# system boots up.
EBTABLES_LOAD_ON_START="no"

# Save current firewall rules on stop.
#   Value: yes|no,  default: no
# Saves all firewall rules if firewall gets stopped
# (e.g. on system shutdown).
EBTABLES_SAVE_ON_STOP="no"

# Save current firewall rules on restart.
#   Value: yes|no,  default: no
# Saves all firewall rules if firewall gets restarted.
EBTABLES_SAVE_ON_RESTART="no"

# Save (and restore) rule counters.
#   Value: yes|no,  default: no
# Save rule counters when saving a kernel table to a file. If the
# rule counters were saved, they will be restored when restoring the table.
EBTABLES_SAVE_COUNTER="no"

# Backup suffix for ruleset save files.
#   Value: <string>,  default: "~"
# Keep one backup level of saved rules.
# Set this variable to the empty string to disable backups.
EBTABLES_BACKUP_SUFFIX="~"

Comanda ebtables

La sintaxi és força similar a iptables. Podeu consultar lajuda:

$ ebtables -h
ebtables v2.0.9-2 (June 2009)
Usage:
ebtables -[ADI] chain rule-specification [options]
ebtables -P chain target
ebtables -[LFZ] [chain]
ebtables -[NX] [chain]
ebtables -E old-chain-name new-chain-name 

Commands:
--append -A chain             : append to chain
--delete -D chain             : delete matching rule from chain
--delete -D chain rulenum     : delete rule at position rulenum from chain
--change-counters -C chain
          [rulenum] pcnt bcnt : change counters of existing rule
--insert -I chain rulenum     : insert rule at position rulenum in chain
--list   -L [chain]           : list the rules in a chain or in all chains
--flush  -F [chain]           : delete all rules in chain or in all chains
--init-table                  : replace the kernel table with the initial table
--zero   -Z [chain]           : put counters on zero in chain or in all chains
--policy -P chain target      : change policy on chain to target
--new-chain -N chain          : create a user defined chain
--rename-chain -E old new     : rename a chain
--delete-chain -X [chain]     : delete a user defined chain
--atomic-commit               : update the kernel w/t table contained in <FILE>
--atomic-init                 : put the initial kernel table into <FILE>
--atomic-save                 : put the current kernel table into <FILE>
--atomic-file file            : set <FILE> to file 

Options:
--proto  -p [!] proto         : protocol hexadecimal, by name or LENGTH
--src    -s [!] address[/mask]: source mac address
--dst    -d [!] address[/mask]: destination mac address
--in-if  -i [!] name[+]       : network input interface name
--out-if -o [!] name[+]       : network output interface name
--logical-in  [!] name[+]     : logical bridge input interface name
--logical-out [!] name[+]     : logical bridge output interface name
--set-counters -c chain
          pcnt bcnt           : set the counters of the to be added rule
--modprobe -M program         : try to insert modules using this program
--version -V                  : print package version

Environment variable:
EBTABLES_ATOMIC_FILE          : if set <FILE> (see above) will equal its value

Standard targets: DROP, ACCEPT, RETURN or CONTINUE;
The target can also be a user defined chain. 

Supported chains for the filter table:
INPUT FORWARD OUTPUT

Per mostrar les normes cal fer:

$ sudo ebtables -L
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT 

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Com en el cas de iptables la taula per defecte que és es mostra és la taula filter.

Podeu consultar altres taules amb l'opció -t:

$ sudo ebtables -t nat -L
Bridge table: nat

Bridge chain: PREROUTING, entries: 0, policy: ACCEPT 

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

o:

$ sudo ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 0, policy: ACCEPT


Bridge chain: POSTROUTING, entries: 0, policy: ACCEPT


Per a més informació consulteu el manual:

$ man ebtables

Fer les normes d'ebtables persistents

$ cat /etc/default/ebtables
EBTABLES_LOAD_ON_START="yes"
EBTABLES_SAVE_ON_STOP="yes"
EBTABLES_SAVE_ON_RESTART="yes"

Exemples

Port Isolation

Consulteu Port_Isolation#ebtables

BROUTING
brouter

Com diu al manual de ebtables:

$ man ebtables
...
route is used to make a brouter, it has one built-in chain: BROUTING.  The targets DROP and ACCEPT have a special  meaning
in  the  broute  table  (these  names are used instead of more descriptive names to keep the implementation generic).  DROP
actually means the frame has to be routed, while ACCEPT means the frame has to be bridged. The BROUTING chain is  traversed
very  early.  However, it is only traversed by frames entering on a bridge port that is in forwarding state. Normally  those    
frames would be bridged, but you can decide otherwise here. The redirect target is very handy here.

Ebtables treballa amb frames que poden ser Ethernet o d'altres tipus de protocols de nivell 2 (com per exemple VLANs, consulteu /etc/ethertypes). Un target DROP a la cadena BROUTING indica que el paquet ha de ser encaminat i sortir del bridge. Això significa que el codi del bridge no tocarà per a res el frame i l'envia cap a la capa superior (capa de xarxa). El resultat és que el frame entrarà a la màquina com si no hagués arribat pel bridge sinó per la interfície física mateixa.

Vegem un exemple:

Configuració del bridge:

$ sudo brctl addbr br0
$ sudo brctl addif br0 eth0
$ sudo brctl addif br0 eth1
$ sudo ifconfig br0 0.0.0.0
$ sudo ifconfig eth0 172.16.1.1 netmask 255.255.255.0
$ sudo ifconfig eth1 172.16.2.1 netmask 255.255.255.0

Configuració de ebtables:

$ sudo ebtables -t broute -A BROUTING -p ipv4 -i eth0 --ip-dst 172.16.1.1 -j DROP
$ sudo ebtables -t broute -A BROUTING -p ipv4 -i eth1 --ip-dst 172.16.2.1 -j DROP
$ sudo ebtables -t broute -A BROUTING -p arp -i eth0 -d $MAC_OF_ETH0 -j DROP
$ sudo ebtables -t broute -A BROUTING -p arp -i eth1 -d $MAC_OF_ETH1 -j DROP
$ sudo ebtables -t broute -A BROUTING -p arp -i eth0 --arp-ip-dst 172.16.1.1 -j DROP
$ sudo ebtables -t broute -A BROUTING -p arp -i eth1 --arp-ip-dst 172.16.2.1 -j DROP

Les dos primeres línies s'asseguren que els paquets adreçats a les interfícies reals siguin encaminats i no passin pel bridge.

NOTA: If you want the box to also route traffic with a MAC destination address different from the router's, you need to use the redirect target, which changes the MAC destination address to the bridge's MAC address (see the subsequent example).

Les últimes 4 comandes són necessàries per tal que el protocol ARP funcioni correctament. Quan el brouter envia les peticions ARP request per exemple per a la IP 172.16.1.5, aquesta petició s'envia per les interfícies eth0 o eth1 (estem suposant que no hi ha una ruta assignada a la interfície br0). Esnse la tercera norma ebtables, el paquet ARP reply arribarà per la interfície br0 i serà descartat.

would arrive on the br0 device instead of the eth{0,1} device, as far as the ARP code can tell. This reply is then discarded by the ARP code. Using the third rule, the reply arrives on the eth0 device and the ARP code is happy. So the third and fourth rules are needed to make the ARP code use the ARP replies. Without the third rule, the brouter will not send IP packets to 172.16.1.5 (unless it already knew the MAC address of 172.16.1.5 and therefore didn't send an ARP request in the first place). 

The last two commands are needed so that the ARP requests for 172.16.1.1 and 172.16.2.1 are answered. You can use more restrictive matching on the ARP packets (e.g. only match on arp requests in the last two rules).

VLANS i bridges

TODO

The Brouting table is the first table processed. It enables a unique behavior where in frames which follow a -j ACCEPT target continue on to the rest of the bridging tables/chains, but following a -j DROP will actually kick the frame out of the bridging process and over to the routing process, as if it had never entered the bridge.

So let’s say that we need our VMs to communicate over the untagged VLAN, so eth0 is in our bridge with the vifs. In addition, we have eth0.100 unbridged so we can hit VLAN 100 from the host. At this point, outgoing traffic through eth0.100 works, but no traffic is received. By making use of some match criteria specific to our setup, we can write a rule in ebtables that fixes the issue, like so:

$ sudo ebtables -t broute -A BROUTING -i eth0 -p 802_1Q -j DROP

This command adds a rule to the BROUTING chain in the broute table where any frames entering eth0 with a protocol of 8021q (VLAN tagging) gets kicked out of bridging and goes straight to routing. The result is that the VLAN code detects the tag and selects the correct subif for the traffic. We don’t have to adjust outgoing traffic because in this setup it will be originating from or through the subif and thus get tagged before the bridge sees it.

Things get a little trickier when you want to have this setup and also handle traffic being tagged inside of VMs. By solving the first problem, we’ve created a new one for ourselves; if eth0 -j DROPs all tagged traffic to kick it to the host’s subifs, VMs will never see it. To get that traffic back through, we need to use more ebtables magic by modifying the rule slightly:

# ebtables -t broute -F
# ebtables -t broute -A BROUTING -i eth0 -p 802_1Q -d de:ad:be:ef:do:od -j DROP

What we’ve done here is stipulate that only if the tagged traffic entering eth0 is destined for the mainif (or any of its subifs) MAC address do we want the bridge to kick it back to get untagged on the host. Otherwise, bridging proceeds and the VM receives the tagged traffic as-is. This works because the MAC address of a subif is copied from the mainif it is attached to, allowing us to distinguish between traffic for the host and traffic for VMs.

Conclusion

This may seem like an overly convoluted approach to networking when there are other possible solutions such as just throwing in more interfaces and eating up port density on your switches and aggrs. However, in a modern cloud environment where you need to solve the problems of density, multi-tenancy, VM/host isolation, integrating fine-grained security with logical network segregation, etc… being able to flexibly massage the Linux VLAN and bridge code into handling any combination of ports and tags is truly essential.

Hopefully this long-winded post helps anyone struggling with making these two indispensable network building-blocks play nice in Linuxland at least understand how the pieces fit together better. Feel free to leave feedback on your experiences, solutions or harsh language when you’re forced to resort to ebtables. Better the devil you know.

3 In most distros you have to install an ebtables package to obtain the binary, but what it talks to is built into most every stock kernel; similar to 8021q, but isn’t its own module.

Atacs i forats de seguretat

TODO

http://backup-cosas.blogspot.com.es/search/label/ebtables

Vegeu Atacs i forats de seguretat.

bridge-netfilter

TODO

The bridge-netfilter code enables the following functionality:

   {Ip,Ip6,Arp}tables can filter bridged IPv4/IPv6/ARP packets, even when encapsulated in an 802.1Q VLAN or PPPoE header. This enables the functionality of a stateful transparent firewall.
   All filtering, logging and NAT features of the 3 tools can therefore be used on bridged frames.
   Combined with ebtables, the bridge-nf code therefore makes Linux a very powerful transparent firewall.
   This enables, f.e., the creation of a transparent masquerading machine (i.e. all local hosts think they are directly connected to the Internet).
   Letting {ip,ip6,arp}tables see bridged traffic can be disabled or enabled using the appropriate proc entries, located in /proc/sys/net/bridge/:
       bridge-nf-call-arptables
       bridge-nf-call-iptables
       bridge-nf-call-ip6tables
   Also, letting the aforementioned firewall tools see bridged 802.1Q VLAN and PPPoE encapsulated packets can be disabled or enabled with a proc entry in the same directory:
       bridge-nf-filter-vlan-tagged
       bridge-nf-filter-pppoe-tagged
   These proc entries are just regular files. Writing '1' to the file (echo 1 > file) enables the specific functionality, while writing a '0' to the file disables it.

Troubleshooting. Resol·lució de problemes

Device X is already a member of a bridge; can't enslave it to bridge Y

No es pot afegir a dos bridgos diferents una mateixa interfície de xarxa.

Vegeu també

Enllaços externs