To ejere, én adresse: dobbelte IP'er på en TAP-bro

Én Windows-klient holder 10.8.0.2 og virker, indtil opstartsrækkefølgen ændres; så rapporteres samme adresse som en konflikt, og intet ved klienten er ændret. En anden vært på samme sammenbroede segment kræver samme værdi, og den maskine, der bliver færdig med konfigurationen sidst, taber som regel. Begge tror, de ejer den, og taberen holder stille op med at bruge en adresse, den fik besked på at bruge. Netop det at behandle det som et tidsproblem er, hvad der får det til at vende tilbage ved hver genstart.

Læs konfliktbeviserne, før du rører en bro

Windows rapporterer en adressekonflikt sammen med den anden krævers hardwareadresse. Den hardwareadresse er det nyttige faktum, fordi den peger på ét interface på én vært, mens hændelsens viste navn ikke siger noget om, hvor dubletten bor. Skriv hardwareadressen ned, før du ændrer noget.

ARP-baseret dubletregistrering undersøger konkurrerende ejere, før en adresse tages i brug, og holder derefter øje. Derfor kan en vært, som var fraværende, mens du konfigurerede netværket, stadig forårsage en konflikt en time senere. Undersøgelsen er ikke et engangstjek ved opstart. En maskine, der dukker op bagefter, kan tage en adresse, som har været i rolig brug hele dagen, og derfor ser fejlen ud som et kapløb i stedet for en konfigurationsfejl.

En konflikthændelse siger i sig selv ikke, hvilken konfiguration der skabte det andet krav, og hvis du rydder adresser eksperimentelt, ødelægger du den kobling, der ville have fortalt dig det. Pointen med beviset er at gøre en hardwareadresse til et interface, du kan undersøge. At søge i inventaret efter maskinnavn sender dig som regel til den forkerte vært.

Kortlæg hvert krav på segmentet

En sammenbroet TAP-opsætning forbinder Ethernet-segmenter, der før var adskilte, så adresser, der var unikke i deres egne netværk, kan kollidere, når rammer deler ét link. Derfor findes denne fejlklasse på en VPN og ikke på de rutede netværk, den erstattede. Oplist enhver mulig ejer i stedet for den første, du mistænker.

Gå listen igennem i denne rækkefølge: adresserne på hver broenhed og dens medlemsporte, OpenVPN-puljen og enhver fast tildeling pr. klient samt enhver DHCP-server, der dækker det sammenbroede segment. Sammenhold derefter hardwareadressen fra konfliktrapporten med de interfaces, du fandt.

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

Puljen og DHCP-området er de to ejere, folk glemmer. Udskriv begge områder sammen, og led efter overlapning, før du gør noget andet. En håndtildelet broadresse og en pulje, der uddeler samme værdi, vil før eller siden kollidere, og kollisionen ser tilfældig ud, indtil begge områder er skrevet ud side om side.

Nummér kun broer, hvor de har brug for en identitet

I en normal værtsbro bærer broenheden værtens konfiguration for tredje lag, og Ethernet- og TAP-medlemmerne optræder som porte. At give hvert medlem sin egen adresse eller kopiere ét opsætningsscript til flere maskiner uden at ændre adressen er måden, hvorpå ét segment ender med tre ejere af samme værdi. Medlemmerne har ikke brug for egne identiteter for at videresende rammer. De har brug for præcis én identitet pr. vært, der skal kunne nås på det segment.

En bro, der kun switcher rammer, har slet ikke brug for en adresse på det segment. Lader du den være unummereret, fjerner du en hel klasse af kollisioner, forudsat at værten stadig har en administrationsvej, du har verificeret. Bekræft adgang først, fjern adressen som det næste, og kontrollér nåbarheden som det tredje.

Hvis den adresse, du er ved at slette, er den eneste vej ind i maskinen, er det en selvforskyldt nedetid og ikke en diagnose at slette den som et eksperiment. Verificér den alternative vej, før du tester noget.

Sørg for, at rettelsen overlever en genstart

Ændring af et aktivt interface retter den nuværende opstart og intet andet. Hvad der end genskaber adressen ved opstart, vil gendanne konflikten ved næste genstart, og du vil konkludere, at rettelsen ikke virkede, selv om den faktisk aldrig var varig. Notér, hvilken fil du ændrede, så den næste genstart bekræfter en beslutning i stedet for at afsløre en overraskelse.

Find ejeren af den konfiguration: en netværksadministratorprofil, en fil pr. interface, en container- eller VM-definition eller et cloud-init-fragment. Ændr den der, og genstart derefter bevidst én berørt vært for at bekræfte, at det er den nye værdi, der kommer tilbage. En genstart er den eneste test, der beviser varighed.

Reservér broadresserne inde i DHCP-området som udelukkelser, eller flyt dem uden for det. En reservation, der kun findes i et regneark, er ikke en udelukkelse, og tildeleren læser den ikke.

Bevis det med hver klient online

Én vellykket forbindelse beviser intet, fordi det oprindelige symptom kun viste sig, når rækkefølgen ændrede sig. Start hver tilsigtet klient, variér opstartsrækkefølgen, og gentag efter en genopkobling. Genstart derefter den vært, der plejede at tabe kapløbet, og bekræft, at adressen overlever.

For direkte bekræftelse kan du undersøge for en dobbelt ejer, før adressen tildeles, og derefter holde øje med nabo-tabellen. Hvis intet svarer på undersøgelsen, og adressen forbliver unikt ejet gennem en fuld genstartscyklus, er konflikten løst og ikke blot skjult. Kommandoerne nedenfor udfører begge kontroller på broenheden. RFC 5227 beskriver den undersøgelses- og annonceringsadfærd, som disse værktøjer udøver, og det er den reference, man citerer, når nogen foreslår at slå registrering fra i stedet.

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

En undersøgelse uden svar er det forventede resultat på et rent segment. En undersøgelse, der fremkalder et svar, giver dig hardwareadressen på den resterende ejer, det samme bevis Windows-hændelsen gav dig i starten. Gem det output sammen med ændringsregistreringen, fordi det er det eneste bevis på, at adressen holdes unikt.