To eigarar, éi adresse: doble IP-ar på ei TAP-bru

Éin Windows-klient held 10.8.0.2 og verkar til startrekkjefølgja blir endra; då blir same adresse rapportert som ein konflikt, og ingenting ved klienten er endra. Ein annan vert på same brubundne segmentet krev same verdi, og maskina som blir ferdig med konfigurasjonen sist, tapar som regel. Begge trur dei eig ho, og taparen sluttar stille å bruke ei adresse han fekk beskjed om å bruke. Nettopp det å handsame dette som eit tidsproblem er det som gjer at det kjem attende ved kvar omstart.

Les konfliktbevisa før du rører ei bru

Windows rapporterer ein adressekonflikt saman med maskinvareadressa til den andre krevjaren. Den maskinvareadressa er det nyttige faktumet, fordi ho peikar på eitt grensesnitt på éin vert, medan det viste namnet på hendinga ikkje seier noko om kvar duplikatet bur. Skriv ned maskinvareadressa før du endrar noko.

ARP-basert duplikatregistrering undersøkjer konkurrerande eigarar før ei adresse blir teken i bruk, og følgjer deretter med vidare. Derfor kan ein vert som var fråverande medan du konfigurerte nettverket, framleis valde ein konflikt ein time seinare. Undersøkinga er ikkje ein eingongssjekk ved oppstart. Ei maskin som dukkar opp etterpå, kan ta ei adresse som har vore i roleg bruk heile dagen, og derfor ser feilen ut som eit kapplaup i staden for ein konfigurasjonsfeil.

Ei konflikthending seier i seg sjølv ikkje kva konfigurasjon som skapte det andre kravet, og viss du ryddar adresser eksperimentelt, øydelegg du koplinga som ville ha fortalt deg det. Poenget med beviset er å gjere ei maskinvareadresse om til eit grensesnitt du kan undersøkje. Å søkje i inventaret etter maskinnamn sender deg som regel til feil vert.

Kartlegg kvart krav på segmentet

Eit brubunde TAP-oppsett knyter saman Ethernet-segment som før var skilde, så adresser som var unike i sine eigne nettverk, kan kollidere når rammer deler éi lenkje. Derfor finst denne feilklassen på ein VPN og ikkje på dei ruta netta han erstatta. List opp kvar mogeleg eigar i staden for den første du mistenkjer.

Gå gjennom lista i denne rekkjefølgja: adressene på kvar brueining og medlemsporten hennar, OpenVPN-poolen og kvar fast tildeling per klient, samt kvar DHCP-tenar som dekkjer det brubundne segmentet. Samanhald deretter maskinvareadressa frå konfliktrapporten med grensesnitta du fann.

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

Poolen og DHCP-området er dei to eigarane folk gløymer. Skriv ut begge områda saman og sjå etter overlapp før du gjer noko anna. Ei handtildelt bruadresse og ein pool som deler ut same verdi, vil før eller seinare kollidere, og kollisjonen ser tilfeldig ut heilt til begge områda blir skrivne ut side ved side.

Nummerer bruer berre der dei treng ein identitet

I ei vanleg vertsbru ber brueininga konfigurasjonen til verten for tredje lag, og Ethernet- og TAP-medlemmene opptrer som portar. Å gi kvart medlem si eiga adresse, eller kopiere eitt oppsettsskript til fleire maskiner utan å endre adressa, er måten eitt segment endar opp med tre eigarar av same verdi. Medlemmene treng ikkje eigne identitetar for å videresende rammer. Dei treng nøyaktig éin identitet per vert som må vere nåbar på det segmentet.

Ei bru som berre svitsjar rammer, treng ikkje adresse på det segmentet i det heile. Let du ho vere unummerert, fjernar du ein heil klasse kollisjonar, føresett at verten framleis har ein administrasjonsveg du har verifisert. Stadfest tilgang først, fjern adressa som nummer to, og kontroller nåbarheita som nummer tre.

Viss adressa du er i ferd med å slette, er den einaste vegen inn til maskina, er det eit sjølvpåført avbrot og ikkje ein diagnose å slette ho som eit eksperiment. Verifiser den alternative vegen før du testar noko.

Sørg for at rettinga overlever ein omstart

Endring av eit aktivt grensesnitt rettar den gjeldande oppstarten og ingenting anna. Det som enn gjenopprettar adressa ved oppstart, vil gjenopprette konflikten ved neste omstart, og du vil konkludere med at rettinga ikkje verka, sjølv om ho faktisk aldri var varig. Noter kva fil du endra, slik at neste omstart stadfestar ei avgjerd i staden for å avdekkje ei overrasking.

Finn eigaren av den konfigurasjonen: ein nettverksadministratorprofil, ei fil per grensesnitt, ein container- eller VM-definisjon, eller eit cloud-init-fragment. Endre han der, og start deretter medvite éin råka vert på nytt for å stadfeste at det er den nye verdien som kjem attende. Ein omstart er den einaste testen som beviser varigheit.

Reserver bruadressene inne i DHCP-området som unntak, eller flytt dei utanfor. Ein reservasjon som berre finst i eit rekneark, er ikkje eit unntak, og tildelaren vil ikkje lese han.

Bevis det med kvar klient på nett

Éi vellukka tilkopling beviser ingenting, fordi det opphavlege symptomet berre dukka opp når rekkjefølgja endra seg. Start kvar tiltenkte klient, varier startrekkjefølgja, og gjer det om att etter ei gjenoppkopling. Start deretter verten som før tapte kapplauet på nytt, og stadfest at adressa overlever.

For direkte stadfesting, undersøk om det finst ein dobbel eigar før adressa blir tildelt, og følg deretter med på nabolagetabellen. Viss ingenting svarar på undersøkinga, og adressa blir verande unikt eigd gjennom ein full omstartssyklus, er konflikten løyst og ikkje berre skjult. Kommandoane nedanfor utfører begge kontrollane på brueininga. RFC 5227 skildrar undersøkings- og annonseringsåtferda som desse verktya utøvar, og det er referansen ein siterer når nokon føreslår å slå av registreringa i staden.

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

Ei undersøking utan svar er det forventa resultatet på eit reint segment. Ei undersøking som framkallar eit svar, gir deg maskinvareadressa til den gjenverande eigaren, det same beviset Windows-hendinga gav deg i starten. Ta vare på den utskrifta saman med endringsloggen, fordi det er det einaste beviset på at adressa blir halden unikt.