Dois donos, um endereço: IPs duplicados numa ponte TAP

Um cliente Windows mantém 10.8.0.2 e funciona até a ordem de arranque mudar; então o mesmo endereço é reportado como conflito e nada no cliente mudou. Um segundo anfitrião no mesmo segmento com ponte reclama o mesmo valor, e a máquina que termina a configuração em último tende a perder. Ambos acreditam que o endereço é seu, e o perdedor deixa silenciosamente de usar um endereço que lhe foi dito para usar. É precisamente tratar isto como um problema de temporização que faz com que volte a ocorrer em cada reinício.

Leia as provas do conflito antes de tocar numa ponte

O Windows reporta um conflito de endereço juntamente com o endereço de hardware do outro reclamante. Esse endereço de hardware é o facto útil, porque mapeia para uma interface num anfitrião, enquanto o nome apresentado do evento não diz nada sobre onde vive o duplicado. Anote o endereço de hardware antes de mudar seja o que for.

A deteção de duplicados baseada em ARP sonda os donos concorrentes antes de o endereço ser usado e continua a vigiar depois. É por isso que um anfitrião que estava ausente enquanto configurava a rede ainda pode causar um conflito uma hora mais tarde. A sonda não é uma verificação única no arranque. Uma máquina que aparece depois pode tomar um endereço que esteve em uso tranquilo todo o dia, e é por isso que a falha se lê como uma corrida e não como um erro de configuração.

Um evento de conflito por si só não diz que configuração criou a outra reivindicação, e apagar endereços experimentalmente destrói o mapeamento que lhe teria dito. O objetivo da prova é transformar um endereço de hardware numa interface que possa inspecionar. Procurar no inventário pelo nome da máquina costuma levar ao anfitrião errado.

Inventarie cada reivindicação no segmento

Uma instalação TAP com ponte junta segmentos Ethernet que antes estavam separados, pelo que endereços que eram únicos dentro das suas próprias redes podem colidir assim que as tramas partilham uma ligação. É por isso que esta classe de falha existe numa VPN e não existe nas redes encaminhadas que substituiu. Enumere todos os donos possíveis em vez do primeiro que suspeita.

Percorra a lista por esta ordem: os endereços de cada dispositivo de ponte e das suas portas membro, o OpenVPN e qualquer atribuição fixa por cliente, e qualquer servidor DHCP que cubra o segmento com ponte. Depois compare o endereço de hardware do relatório de conflito com as interfaces que encontrou.

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

O pool e o intervalo DHCP são os dois donos que as pessoas esquecem. Imprima os dois intervalos juntos e procure sobreposição antes de fazer qualquer outra coisa. Um endereço de ponte atribuído à mão e um pool que entrega o mesmo valor acabarão por colidir, e a colisão parece aleatória até os dois intervalos serem impressos lado a lado.

Numere pontes apenas onde precisam de uma identidade

Numa ponte de anfitrião normal, o dispositivo de ponte transporta a configuração de terceira camada do anfitrião e os membros Ethernet e TAP funcionam como portas. Dar a cada membro o seu próprio endereço, ou copiar um script de instalação para várias máquinas sem alterar o endereço, é como um único segmento acaba com três donos do mesmo valor. Os membros não precisam de identidades próprias para encaminhar tramas. Precisam exatamente de uma identidade por anfitrião que tenha de ser alcançável nesse segmento.

Uma ponte que apenas comuta tramas não precisa de endereço nesse segmento. Deixá-la sem numeração elimina toda uma classe de colisão, desde que o anfitrião ainda tenha um caminho de gestão que tenha verificado. Confirme o acesso primeiro, remova o endereço segundo e verifique a alcançabilidade terceiro.

Se o endereço que vai apagar é a única rota para a máquina, apagá-lo como experiência é uma interrupção autoinfligida e não um diagnóstico. Verifique o caminho fora de banda antes de testar seja o que for.

Faça com que a correção sobreviva a um reinício

Alterar uma interface em funcionamento corrige o arranque atual e nada mais. O que quer que recrie o endereço no arranque restaurará o conflito no reinício seguinte, e vai concluir que a correção não funcionou quando na verdade nunca foi persistente. Anote que ficheiro alterou, para que o reinício seguinte confirme uma decisão em vez de revelar uma surpresa.

Encontre o dono dessa configuração: um perfil do gestor de rede, um ficheiro por interface, uma definição de contentor ou VM, ou um fragmento de cloud-init. Altere-o aí e depois reinicie deliberadamente um anfitrião afetado para confirmar que o novo valor é o que regressa. Um reinício é o único teste que prova a persistência.

Reserve os endereços da ponte dentro do intervalo DHCP como exclusões, ou mova-os para fora dele. Uma reserva que só existe numa folha de cálculo não é uma exclusão, e o distribuidor não a lerá.

Prove-o com todos os clientes em linha

Uma única ligação bem-sucedida não prova nada, porque o sintoma original só aparecia quando a ordem mudava. Levante todos os clientes previstos, varie a ordem de arranque e repita após uma religação. Depois reinicie o anfitrião que costumava perder a corrida e confirme que o endereço sobrevive.

Para confirmação direta, sonde se existe um dono duplicado antes de atribuir o endereço e observe a tabela de vizinhos depois. Se nada responder à sonda e o endereço se mantiver de propriedade única durante um ciclo completo de reinício, o conflito está resolvido e não apenas escondido. Os comandos abaixo efetuam as duas verificações no dispositivo de ponte. RFC 5227 descreve o comportamento de sonda e anúncio que estas ferramentas exercem, e é a referência a citar quando alguém propõe desativar a deteção.

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

Uma sonda que não recebe resposta é o resultado esperado num segmento limpo. Uma sonda que atrai uma resposta dá-lhe o endereço de hardware do dono restante, a mesma prova que o evento do Windows lhe deu no início. Guarde essa saída com o registo de alterações, porque é a única prova de que o endereço é mantido de forma única.