Eu tinha uma LAN 192.168.22.0/24 totalmente isolada com dois switches HW: 1Gbit e 10Gbit. O antigo switch de 10 Gbit também suportava 1 Gbit, portanto, não havia problema em conectar os dois switches. Na semana passada, recebemos um novo switch de 10 Gbit que não suporta 1 Gbit. Devo conectar imediatamente essas partes de rede repentinamente divorciadas, porque em 10 Gbit há sementes principalmente nos servidores (incluindo dhcp) e a maioria das estações de trabalho está conectada a 1 Gbit. Felizmente, eu tenho uma caixa debian linux conectada a ambas as partes e posso configurá-la como switch de 1/10 Gbit temporariamente. Eu segui as dicas, mas não observei a ponte - por exemplo, nenhum efeito na tabela arp, nenhum ping de wks para o servidor. Eu escrevi um roteiro:
#!/bin/bash
ip link add name br0 type bridge
ip link set dev br0 up
ip link set dev eth0 master br0 #1Gb
ip link set dev eth1 master br0 #XGb
Por favor, você pode me responder alguma pergunta:
- a eth0 e eth1 podem ter (o mesmo) endereço IP ? ou o endereço IP pode obter o br0?
- o iptables tem que ser desabilitado/desinstalado/desinstalado? (iptables não está em uso)
- existe algum bit de habilitação "forward" para ser definido?
- esse software poderia realmente mudar a transmissão dhcp?
Eu tenho um runnig tasks na minha caixa linux, por isso não testei as dicas de como configurar /etc/network/interfaces – estou feliz por ter desabilitado o NetworkManager, não consigo reiniciar.
Qualquer ajuda e sugestão são bem-vindas, eu ficaria feliz em voltar à LAN antes da manhã de segunda-feira.
Para simplificar, falarei apenas sobre ethernet e IPv4 (o mesmo se aplica, por exemplo, a IPv6/ ip6tables ). Às vezes, tentarei abordar cada ponto com mais detalhes do que o necessário, caso essa pergunta seja interessante para outras pessoas.
configurar
Para ficar completo, você deve adicionar isso em sua configuração inicial, caso não tenha sido feito antes:
Se você não abrir as portas da ponte, a ponte enquanto estiver ativa não estará recebendo nem poderá enviar nenhum quadro. Esta pode ser a causa de seus problemas.
portas de ponte e camada 3
TL;DR : para uma configuração mais fácil, a configuração de IP e roteamento deve estar na interface da ponte
br0
e somente nela. Isso deve afetar apenas a conectividade IP do host, não sua capacidade de ponte. Portanto, se anteriormente o IP foi definido em eth0 , você deve aplicá-lo em br0 . Se você não fizesse isso, isso impediria a conectividade IP com o sistema (mas não impediria a ponte).Como uma observação lateral, o ARP é destinado ao sistema local e tratado pelo protocolo ARP e não tratado de maneira especial por uma ponte. O que é útil em uma ponte é ver o FDB (entradas do banco de dados de encaminhamento).
estado ARP do sistema local:
para monitorar as mudanças:
Estados de encaminhamento MAC da ponte:
para monitorar as mudanças:
Outras configurações são possíveis, por exemplo, usando um veth par extra de interfaces com o IP em uma extremidade e a outra extremidade como uma 3ª porta de ponte, e nenhum IP na ponte, deixando a ponte fazendo apenas ponte e não envolvida na camada 3. Mas é mais demorado para configurar corretamente (por exemplo: o que acontece com o endereço MAC aleatório por padrão? etc.).
Assim que uma interface se torna uma porta bridge (obtém uma bridge como master), suas informações da camada 3 são ignoradas: IPs configurados nela, se houver, ficam indisponíveis. A exceção notável é a porta de auto-ponte implícita especial com o nome da ponte, então aqui
br0
. Se você atribuir um IP a ele, então a bridge estará trabalhando na camada 3 (IP), além de fazer a comutação de quadros na camada 2. Caso contrário, ela só poderá fazer comutação.iptables/netfilter e interações de camada de ponte
TL;DR : se você não estiver usando nenhuma regra do iptables , inclusive em namespaces de rede (contêineres), você não precisa fazer nada, nem se preocupar se alguns módulos relacionados ao iptables estão carregados. Resposta detalhada a seguir...
Filtrar (ou desmembrar, etc.) quadros na camada 2 (ponte ethernet) deve ser feito por ebtables , enquanto a filtragem de pacotes IP na camada 3 deve ser feita por iptables . Então iptables normalmente não devem ver frames (a menos que sejam destinados ao sistema local e cheguem na camada 3 como pacotes IP) e não devem ter nenhuma interação nos frames da bridge, mas...
ebtables é mais limitado e por exemplo não tem acesso direto ao conntrack do netfilter nem todas as extensões disponíveis para o iptables . Sem isso, seria difícil implementar um bom firewall de camada 2 (que atua como um switch em vez de um roteador). É por isso que existe um modo especial que permite que o código da ponte chame iptables (com quadros temporariamente alterados em pacotes IP para uso de iptables ) além de ebtables . Está descrito em O que é bridge-netfilter? e na interação ebtables/iptables em uma ponte baseada em Linux , com exemplos de interação mais proeminentes em7. Duas maneiras possíveis de frames/pacotes passarem pelas chains PREROUTING, FORWARD e POSTROUTING do iptables . O fluxo de pacotes no lado da camada de link do Netfilter e do esquema de rede geral detalha esse manuseio em azul ( ebtables ) e verde ( iptables ).
Este modo é habilitado carregando o módulo br_netfilter (eg
modprobe br_netfilter
), mas simplesmente usando uma regra iptables com a correspondência physdev irá carregá-lo automaticamente.Quando este módulo for carregado (e o sysctl padrão ainda estiver presente:
net.bridge.bridge-nf-call-iptables=1
) então o iptables irá interagir com a ponte, especialmente quando a ponte tiver um IP, porque isso será feito um tempo adicional da camada de ponte, ao invés de apenas da camada de rede. Então seguindo o exemplo do capitulo 7 anterior , caso você esteja fazendo a ponte da LAN 192.168.22.0/24 e também tenha uma 3ª interface que não faça parte da ponte utilizada para acesso à internet com NAT, esta regra, se usada sozinha:além do tráfego roteado por NAT para fora, também o tráfego em ponte NAT : todo sistema que recebe quadros em ponte veria como origem o IP da ponte em vez do original. É por isso que isso geralmente é escrito assim (você vê isso definido por aplicativos como o LXC):
Então sim você pode até usar o iptables mas deve ter cuidado para não estar usando bridge-nf (o módulo br_netfilter ) ou então adaptar regras. Alguns aplicativos que lidam com rede, especialmente relacionados a contêineres (Docker, Kubernetes...) podem ativá-lo.
Nota sobre namespaces de rede: bridge-nf logo se tornará per-namespace , mas ainda não é o caso. É possível carregar o módulo, desativar a opção e definir uma opção por ponte, mas acho que por enquanto funciona corretamente apenas no namespace inicial. Também acionar o carregamento automático do módulo de qualquer namespace de rede (usando physdev ) afetará todos os outros namespaces de rede, incluindo inicial, é por isso que as regras devem sempre se preparar para isso.
Nota 2: uma vez que o rastreamento de conexão de ponte é disponibilizado para nftables , não deve haver nenhuma razão para usar bridge-nf .
encaminhamento
Por padrão, sem opções adicionais, a ponte está encaminhando quadros (e não manipulando STP) alguns segundos depois que suas portas e ela própria são ativadas. Então, se você sabe que não pode haver nenhum loop, ele deve estar pronto para ser usado.
DHCP
Sim, a ponte deve encaminhar consultas e respostas DHCP, nada de especial no nível da ponte aqui.
diversos
VLAN
Sua configuração parece não ter IDs de VLAN em nenhum lugar, portanto, nada de especial relacionado a VLANs é necessário. Apenas informando que se os quadros marcados com VLAN estivessem envolvidos, a ponte precisaria de configurações adicionais para tratá-los corretamente (começando com
ip link set dev br0 type bridge vlan_filtering 1
, e depois algunsbridge vlan ...
comandos adequados).solução de problemas
Você deve executar o tcpdump em todas as interfaces, algo como:
simultaneamente para ajudar a ver o que está acontecendo.
configuração
se você estiver usando o tipo de configuração ifupdown no Debian, instalar o pacote bridge-utils , que contém o comando obsoleto brctl , também adicionará ganchos bridge-utils-interfaces para configurar uma ponte em uma estrofe de interfaces . Deve ser bom o suficiente para uma configuração de ponte simples.