Due proprietari, un indirizzo: IP duplicati su un bridge TAP

Un client Windows mantiene 10.8.0.2 e funziona finché l'ordine di avvio non cambia; allora lo stesso indirizzo viene segnalato come conflitto mentre nulla è cambiato nel client. Un secondo host sullo stesso segmento con bridge rivendica lo stesso valore, e la macchina che termina per ultima la configurazione di solito perde. Entrambi credono di possederlo, e chi perde smette silenziosamente di usare un indirizzo che gli era stato detto di usare. È proprio trattarlo come un problema di temporizzazione che lo fa ripresentare a ogni riavvio.

Leggete le prove del conflitto prima di toccare un bridge

Windows segnala un conflitto di indirizzo insieme all'indirizzo hardware dell'altro richiedente. Quell'indirizzo hardware è il dato utile, perché corrisponde a un'interfaccia su un host, mentre il nome visualizzato dell'evento non dice nulla su dove si trovi il duplicato. Annotate l'indirizzo hardware prima di cambiare qualsiasi cosa.

Il rilevamento dei duplicati basato su ARP sonda i proprietari concorrenti prima che un indirizzo venga usato e continua a osservare dopo. Per questo un host assente mentre configuravate la rete può ancora causare un conflitto un'ora dopo. La sonda non è un controllo una tantum all'avvio. Una macchina che compare dopo può prendere un indirizzo rimasto in uso tranquillo tutto il giorno, ed è per questo che il guasto si legge come una corsa e non come un errore di configurazione.

Un evento di conflitto da solo non dice quale configurazione abbia creato l'altra rivendicazione, e cancellare gli indirizzi per esperimento distrugge la corrispondenza che ve l'avrebbe detto. Lo scopo della prova è trasformare un indirizzo hardware in un'interfaccia che potete ispezionare. Cercare nell'inventario per nome macchina di solito vi porta all'host sbagliato.

Inventariate ogni rivendicazione sul segmento

Un'installazione TAP con bridge unisce segmenti Ethernet che prima erano separati, così indirizzi unici all'interno delle proprie reti possono scontrarsi non appena i frame condividono un collegamento. Per questo questa classe di guasti esiste su una VPN e non esiste sulle reti instradate che ha sostituito. Elencate ogni possibile proprietario invece del primo che sospettate.

Percorrete l'elenco in questo ordine: gli indirizzi su ogni dispositivo bridge e sulle sue porte membro, il OpenVPN e ogni assegnazione fissa per client, e ogni server DHCP che copre il segmento con bridge. Poi confrontate l'indirizzo hardware del rapporto di conflitto con le interfacce trovate.

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

Il pool e l'intervallo DHCP sono i due proprietari che si dimenticano. Stampate entrambi gli intervalli insieme e cercate una sovrapposizione prima di fare qualsiasi altra cosa. Un indirizzo bridge assegnato a mano e un pool che distribuisce lo stesso valore prima o poi si scontreranno, e lo scontro sembra casuale finché i due intervalli non vengono stampati fianco a fianco.

Numerate i bridge solo dove serve un'identità

In un normale bridge host, il dispositivo bridge porta la configurazione di terzo livello dell'host e i membri Ethernet e TAP agiscono come porte. Dare a ogni membro un proprio indirizzo, o copiare uno script di installazione su più macchine senza cambiare l'indirizzo, è il modo in cui un singolo segmento finisce con tre proprietari dello stesso valore. I membri non hanno bisogno di identità proprie per inoltrare i frame. Hanno bisogno di esattamente un'identità per host che deve essere raggiungibile su quel segmento.

Un bridge che commuta solo frame non ha affatto bisogno di un indirizzo su quel segmento. Lasciarlo senza numero elimina un'intera classe di collisioni, a condizione che l'host abbia ancora un percorso di gestione che avete verificato. Confermate l'accesso per primo, rimuovete l'indirizzo per secondo e controllate la raggiungibilità per terzo.

Se l'indirizzo che state per cancellare è l'unica via verso la macchina, cancellarlo come esperimento è un'interruzione autoinflitta e non una diagnosi. Verificate il percorso fuori banda prima di testare qualsiasi cosa.

Fate sopravvivere la correzione a un riavvio

Modificare un'interfaccia in funzione corregge l'avvio attuale e nient'altro. Qualunque cosa ricrei l'indirizzo all'avvio ripristinerà il conflitto al riavvio successivo, e concluderete che la correzione non ha funzionato mentre in realtà non è mai stata persistente. Annotate quale file avete modificato, così che il riavvio successivo confermi una decisione invece di rivelare una sorpresa.

Trovate il proprietario di quella configurazione: un profilo del gestore di rete, un file per interfaccia, una definizione di container o VM, o un frammento cloud-init. Modificatela lì, poi riavviate deliberatamente un host interessato per confermare che il nuovo valore è quello che torna. Un riavvio è l'unico test che dimostra la persistenza.

Riservate gli indirizzi del bridge all'interno dell'intervallo DHCP come esclusioni, oppure spostateli fuori. Una prenotazione che esiste solo in un foglio di calcolo non è un'esclusione, e l'allocatore non la leggerà.

Dimostratelo con tutti i client online

Una singola connessione riuscita non dimostra nulla, perché il sintomo originale compariva solo quando l'ordine cambiava. Avviate ogni client previsto, variate l'ordine di avvio e ripetete dopo una riconnessione. Poi riavviate l'host che di solito perdeva la corsa e confermate che l'indirizzo sopravvive.

Per una conferma diretta, sondate la presenza di un proprietario duplicato prima di assegnare l'indirizzo e osservate la tabella dei vicini dopo. Se nulla risponde alla sonda e l'indirizzo resta posseduto in modo unico per un ciclo completo di riavvio, il conflitto è risolto e non solo nascosto. I comandi seguenti eseguono entrambi i controlli sul dispositivo bridge. RFC 5227 descrive il comportamento di sonda e annuncio che questi strumenti esercitano, ed è il riferimento da citare quando qualcuno propone di disattivare il rilevamento.

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

Una sonda senza risposta è il risultato atteso su un segmento pulito. Una sonda che suscita una risposta vi dà l'indirizzo hardware del proprietario rimasto, la stessa prova che l'evento Windows vi aveva dato all'inizio. Conservate quell'output con il registro delle modifiche, perché è l'unica prova che l'indirizzo è detenuto in modo unico.