Tveir eigendur, eitt vistfang: tvítekin IP á TAP-brú

Einn Windows-biðlari heldur 10.8.0.2 og virkar þar til röð ræsingar breytist; þá er sama vistfang tilkynnt sem árekstur þótt ekkert hafi breyst hjá biðlaranum. Annar gestgjafi á sama brúaða sniði krefst sama gildis, og vélin sem lýkur stillingunni síðast tapar venjulega. Báðir telja sig eiga það, og sá sem tapar hættir hljóðlega að nota vistfang sem honum var sagt að nota. Einmitt meðferðin á þessu sem tímasetningarvandamáli veldur því að það kemur aftur við hverja endurræsingu.

Lestu sönnunargögn árekstsins áður en þú snertir brú

Windows tilkynnir vistfangsárekstur ásamt vélbúnaðarfangi hins kröfuhafans. Sá vélbúnaðarfangur er gagnleg staðreynd, því hann varpar á eitt viðmót á einum gestgjafa, en sýnilegt heiti atburðarins segir ekkert um hvar tvítekið er. Skrifaðu vélbúnaðarfangið niður áður en þú breytir einhverju.

ARP-greining tvítekninga kannar keppinauta áður en vistfang er notað og heldur áfram að fylgjast með eftir það. Þess vegna getur gestgjafi sem var fjarverandi þegar þú stilltir netið enn valdið árekstri klukkustund síðar. Könnunin er ekki einstök athugun við ræsingu. Vél sem birtist síðar getur tekið vistfang sem hefur verið í rólegri notkun allan daginn, og þess vegna virðist bilunin kapphlaup en ekki stillingarvilla.

Árekstur einn og sér segir ekki hvaða stilling bjó til hina kröfuna, og að hreinsa vistföng í tilraunaskyni eyðileggur þá vörpun sem hefði sagt þér það. Tilgangur sönnunargagnanna er að gera vélbúnaðarfang að viðmóti sem þú getur skoðað. Að leita í birgðaskrá eftir vélarheiti sendir þig venjulega á rangt gestgjafa.

Gerðu skrá yfir hverja kröfu á sniðinu

Brúuð TAP-uppsetning tengir Ethernet-snið sem áður voru aðskilin, svo vistföng sem voru einstök innan eigin neta geta rekist saman þegar rammar deila einni tengingu. Þess vegna er þessi villuflokkur til á VPN og er ekki til á netum með leiðsögn sem hann leysti af hólmi. Teldu upp alla mögulega eigendur í stað þess fyrsta sem þú grunar.

Farðu í gegnum listann í þessari röð: vistföngin á hverju brúartæki og meðlimaportunum þess, OpenVPN laugina og hverja fasta úthlutun á hvern biðlara, og hvern DHCP-þjón sem nær yfir brúaða sniðið. Pörðu síðan vélbúnaðarfangið úr áreksturskýrslunni við viðmótin sem þú fannst.

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

Laugin og DHCP-bilið eru þeir tveir eigendur sem gleymast. Prentaðu bæði bilin saman og leitaðu að skörun áður en þú gerir eitthvað annað. Handvirkt brúarvistfang og laug sem gefur sama gildi munu rekast saman fyrr eða síðar, og áreksturinn virðist tilviljunarkenndur þar til bæði bilin eru prentuð hlið við hlið.

Númeraðu brýr aðeins þar sem þær þurfa auðkenni

Í venjulegri gestgjafabrú ber brúartækið stillingu þriðja lags gestgjafans og Ethernet- og TAP-meðlimir starfa sem port. Að gefa hverjum meðlim eigið vistfang, eða afrita eitt uppsetningarskrif á nokkrar vélar án þess að breyta vistfanginu, er leiðin sem eitt snið endar með þremur eigendum sama gildis. Meðlimirnir þurfa ekki eigin auðkenni til að senda ramma áfram. Þeir þurfa nákvæmlega eitt auðkenni á hvern gestgjafa sem verður að vera aðgengilegur á því sniði.

Brú sem aðeins skiptir um ramma þarf alls ekkert vistfang á því sniði. Að láta hana vera ónúmeraða fjarlægir heilan flokk árekstra, að því tilskildu að gestgjafinn hafi enn staðfesta stjórnunarleið. Staðfestu aðgang fyrst, fjarlægðu vistfangið næst og athugaðu aðgengi þriðja.

Ef vistfangið sem þú ert að fara að eyða er eina leiðin inn í vélina, er að eyða því sem tilraun sjálfsköpuð truflun en ekki greining. Staðfestu leiðina utan bands áður en þú prófar eitthvað.

Láttu leiðréttinguna standa af sér endurræsingu

Að breyta virku viðmóti lagar núverandi ræsingu og ekkert annað. Hvað sem endurskapar vistfangið við ræsingu mun endurvekja áreksturinn við næstu endurræsingu, og þú munt álykta að leiðréttingin hafi ekki virkað þótt hún hafi í raun aldrei verið varanleg. Skrifaðu niður hvaða skrá þú breyttir, svo næsta endurræsing staðfesti ákvörðun í stað þess að afhjúpa óvænt atriði.

Finndu eiganda þeirrar stillingar: netkerfisstjóraprófíll, skrá á hvert viðmót, skilgreining gáms eða sýndarvélar, eða cloud-init brot. Breyttu henni þar og endurræstu síðan viljandi einn viðkomandi gestgjafa til að staðfesta að nýja gildið komi til baka. Endurræsing er eina prófið sem sannar varanleika.

Frátektu brúarvistföngin innan DHCP-bilsins sem undantekningar, eða færðu þau út fyrir það. Frátekt sem aðeins er til í töflureikni er ekki undantekning, og úthlutandinn mun ekki lesa hana.

Sannaðu þetta með alla biðlara á netinu

Ein farsæl tenging sannar ekkert, því upprunalega einkennið kom aðeins fram þegar röðin breyttist. Ræstu alla fyrirhugaða biðlara, breyttu ræsingarröðinni og endurtaktu eftir endurtengingu. Endurræstu síðan gestgjafann sem áður tapaði kapphlaupinu og staðfestu að vistfangið lifir af.

Fyrir beina staðfestingu skaltu kanna hvort tvítekinn eigandi sé til áður en vistfanginu er úthlutað og fylgjast með nágrannatöflunni eftir á. Ef ekkert svarar könnuninni og vistfangið helst einstakt í eigu í gegnum fulla endurræsingarlotu, er áreksturinn leystur en ekki bara faldinn. Skipanirnar hér að neðan gera báðar athuganirnar á brúartækinu. RFC 5227 lýsir hegðun könnunar og tilkynningar sem þessi verkfæri beita, og það er heimildin sem vitna á í þegar einhver leggur til að slökkva á greiningu í staðinn.

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

Könnun sem fær ekkert svar er væntanleg niðurstaða á hreinu sniði. Könnun sem dregur fram svar gefur þér vélbúnaðarfang hins eftirstandandi eiganda, sömu sönnun og Windows-atburðurinn gaf þér í upphafi. Geymdu þessa útkomu með breytingaskránni, því hún er eina sönnunin fyrir því að vistfangið sé haldið á einstakan hátt.