Os sites ligados por bridge continuam a precisar de uma decisão de saída local para a internet

A extensão de VLAN passou limpa: os hosts dos dois sites veem-se, as partilhas de ficheiros funcionam e as impressoras respondem. Depois alguém no site mais pequeno repara que cada transferência usa a linha de internet do outro site, e o ticket chega como uma queixa de largura de banda. A bridge fez exatamente o que lhe foi pedido. Transportava tramas entre dois edifícios e nunca teve opinião sobre qual router essas tramas deviam usar para a internet.

A bridge transporta tramas, não decisões

Uma extensão de camada 2 faz com que dois locais pareçam um único domínio de difusão, por isso os pedidos ARP, as difusões DHCP e o tráfego da mesma sub-rede atravessam todos o túnel. É todo o serviço que presta. Nada na bridge inspeciona um endereço de destino, o compara com o uplink de um site ou encaminha o tráfego para a saída mais próxima. Cada cliente continua a tomar a sua própria decisão local ou remota com o endereço e a máscara com que foi configurado.

Coloque dois routers nessa sub-rede partilhada e ambos se tornam gateways plausíveis, esteja ou não algum perto do cliente que o usa.

Como um cliente escolhe o seu gateway

A decisão IPv4 descrita em RFC 1122 é simples. Um destino dentro da sub-rede ligada do cliente é alcançado diretamente, com ARP, e um destino fora dela vai para o gateway predefinido configurado. É por isso que o tráfego da mesma sub-rede entre os sites pode atravessar a bridge sem qualquer intervenção do router, e é por isso que o tráfego de internet depende inteiramente do endereço de gateway que o cliente recebeu. Os dois comportamentos são independentes, e uma partilha de ficheiros a funcionar prova apenas o primeiro.

Se um cliente do site pequeno foi configurado com o router do site grande, as suas tramas de internet atravessam primeiro o túnel e saem por lá.

Alterar a rota predefinida do próprio dispositivo VPN não move o gateway desse cliente, porque o cliente não usa o dispositivo como router de todo. O dispositivo também precisa de uma rota separada para o seu par remoto para que o túnel que transporta essas tramas se mantenha ativo, e confundir as duas coisas é como uma extensão de bridge derruba o seu próprio transporte.

Deixe o DHCP expressar a saída pretendida

A opção 3 de uma resposta DHCP fornece uma lista de endereços de router na sub-rede do cliente, por ordem de preferência, e os clientes normalmente escolhem o primeiro que responde. O mecanismo está bem; a propriedade é onde os desenhos falham. Registe o que uma concessão real entrega em cada site em vez de assumir que o servidor DHCP mais próximo entregará o gateway mais próximo.

Execute um alocador coordenado, ou dois configurados explicitamente para a mesma política, e dê à política um responsável. Um segundo alocador independente acrescentado no site remoto não cria localidade, cria duas autoridades para o mesmo domínio de difusão.

Não atribua um único endereço de gateway a dois routers ativos de forma independente só para que as definições dos dois sites pareçam idênticas. Um endereço virtual partilhado num segmento ligado por bridge é um desenho de redundância de primeiro salto com requisitos próprios, e uma versão improvisada produz conflitos ARP que parecem perda de pacotes intermitente. Se a aplicação não precisa realmente de um segmento de camada 2 partilhado, prefixos encaminhados separados com gateways predefinidos locais são mais simples de operar e mais fáceis de explicar durante um incidente.

Teste as quatro coisas separadamente

Peça quatro observações, não uma. Obtenha uma nova concessão DHCP em cada site e registe o router e a máscara recebidos. Chegue a um serviço da mesma sub-rede no outro site e confirme que o caminho é a bridge e não um desvio encaminhado. Obtenha algo da internet pública em cada site e confirme qual uplink o transportou. Depois derrube o túnel e veja o que se parte, porque um site que perde toda a conetividade quando a bridge falha dependia do gateway remoto sem que ninguém notasse.

Esses quatro resultados dizem-lhe se tem uma bridge entre sites, uma saída local ou um backhaul acidental, e recolhê-los leva dez minutos.

O princípio de desenho não é glamoroso: a bridge decide a acessibilidade, o DHCP decide o gateway, e a tabela de encaminhamento do dispositivo decide o caminho próprio do túnel. Mantenha os três em conversas separadas, porque uma única alteração que tente corrigir os três costuma quebrar dois.