Kaks omanikku, üks aadress: dubleeritud IP-d TAP-sillal

Üks Windowsi klient hoiab aadressi 10.8.0.2 ja töötab, kuni käivitusjärjekord muutub; siis teatatakse sama aadress konfliktina, kuigi kliendi juures pole miski muutunud. Teine host samas sillatud segmendis nõuab sama väärtust ja masin, mis lõpetab seadistamise viimasena, kaotab tavaliselt. Mõlemad usuvad, et see kuulub neile, ja kaotaja lakkab vaikselt kasutamast aadressi, mida tal kästi kasutada. Just selle käsitlemine ajastusprobleemina paneb selle igal taaskäivitusel korduma.

Lugege konflikti tõendeid enne, kui puudutate silda

Windows teatab aadressikonfliktist koos teise nõudja riistvara-aadressiga. Just see riistvara-aadress on kasulik fakt, sest see vastab ühele liidesele ühes hostis, samal ajal kui sündmuse kuvatav nimi ei ütle teile duplikaadi asukoha kohta midagi. Kirjutage riistvara-aadress üles enne, kui midagi muudate.

ARP-põhine duplikaatide tuvastamine uurib konkureerivaid omanikke enne aadressi kasutamist ja jälgib edasi ka pärast. Seetõttu võib host, mis oli võrgu seadistamise ajal puuduv, põhjustada konflikti ka tund hiljem. Uurimine ei ole ühekordne kontroll käivitamisel. Hiljem ilmuv masin võib võtta aadressi, mis on kogu päeva rahulikult kasutuses olnud, ja seetõttu näeb rike välja nagu võidujooks, mitte seadistusviga.

Konfliktisündmus iseenesest ei ütle, milline seadistus teise nõude lõi, ja aadresside eksperimentaalne kustutamine hävitab vastenduse, mis oleks seda öelnud. Tõendi mõte on muuta riistvara-aadress liideseks, mida saate uurida. Inventuurist masinanime järgi otsimine viib teid tavaliselt vale hosti juurde.

Loetlege segmendi iga nõue

Sillatud TAP-i seadistus ühendab Etherneti segmendid, mis varem olid eraldi, nii et nende endi võrkudes unikaalsed aadressid võivad kokku põrgata, kui kaadrid jagavad üht linki. Seetõttu see rikke klass esineb VPN-is ega esine marsruuditud võrkudes, mille see asendas. Loetlege iga võimalik omanik, mitte esimene, mida kahtlustate.

Käige nimekiri läbi selles järjekorras: aadressid igal sillaseadmel ja selle liikmeportidel, OpenVPN-bassein ja igasugune kliendipõhine fikseeritud määramine ning iga DHCP-server, mis katab sillatud segmendi. Seejärel sobitage konfliktiaruande riistvara-aadress leitud liidestega.

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

Bassein ja DHCP-vahemik on kaks omanikku, mille inimesed unustavad. Printige mõlemad vahemikud koos ja otsige kattuvust enne, kui midagi muud teete. Käsitsi määratud silla-aadress ja bassein, mis väljastab sama väärtust, põrkavad lõpuks kokku, ja kokkupõrge näib juhuslik, kuni mõlemad vahemikud on kõrvuti välja prinditud.

Nummerdage sildasid ainult seal, kus neil on identiteeti vaja

Tavalises hosti sillas kannab sillaseade hosti kolmanda kihi seadistust ning Etherneti ja TAP-i liikmed toimivad portidena. Iga liikmele oma aadressi andmine või ühe seadistusskripti kopeerimine mitmesse masinasse ilma aadressi muutmata on viis, kuidas üks segment saab sama väärtuse kolm omanikku. Liikmed ei vaja kaadrite edastamiseks oma identiteete. Neil on vaja täpselt üht identiteeti iga hosti kohta, mis peab selles segmendis kättesaadav olema.

Sild, mis ainult lülitab kaadreid, ei vaja selles segmendis üldse aadressi. Kui jätate selle nummerdamata, kaob terve kokkupõrgete klass, eeldusel et hostil on veel teie kontrollitud haldustee. Kinnitage esmalt juurdepääs, eemaldage teiseks aadress ja kontrollige kolmandaks kättesaadavust.

Kui aadress, mille kavatsete kustutada, on ainus tee masinasse, siis selle kustutamine eksperimendina on ise tekitatud katkestus, mitte diagnoos. Kontrollige ribavälist teed enne, kui midagi testite.

Tehke parandus taaskäivitusele vastupidavaks

Töötava liidese muutmine parandab praeguse käivituse ja mitte midagi muud. Mis iganes aadressi käivitamisel uuesti loob, taastab konflikti järgmisel taaskäivitusel, ja te järeldate, et parandus ei töötanud, kuigi tegelikult ei olnud see kunagi püsiv. Märkige üles, millist faili muutsite, et järgmine taaskäivitus kinnitaks otsust, mitte ei paljastaks üllatust.

Leidke selle seadistuse omanik: võrguhalduri profiil, liidesepõhine fail, konteineri või VM-i definitsioon või cloud-init fragment. Muutke seda seal, seejärel taaskäivitage meelega üks mõjutatud host, et kinnitada, et tagasi tuleb uus väärtus. Taaskäivitus on ainus test, mis tõestab püsivust.

Reserveerige silla-aadressid DHCP-vahemiku sees eranditena või viige need sellest välja. Ainult tabelis olemas olev reserveering ei ole erand ja jaotaja ei loe seda.

Tõestage seda kõigi klientidega võrgus

Üks õnnestunud ühendus ei tõesta midagi, sest algne sümptom ilmnes ainult siis, kui järjekord muutus. Tõstke üles iga kavandatud klient, muutke käivitusjärjekorda ja korrake pärast taasühendamist. Seejärel taaskäivitage host, mis varem võidujooksu kaotas, ja kinnitage, et aadress püsib.

Otseseks kinnituseks uurige enne aadressi määramist duplikaatomanikku ja jälgige pärast naabritabelit. Kui miski ei vasta uurimisele ja aadress püsib kogu taaskäivitustsükli vältel ainulaadselt omatud, on konflikt lahendatud, mitte ainult peidetud. Allolevad käsud teevad mõlemad kontrollid sillasõlmel. RFC 5227 kirjeldab uurimis- ja teavituskäitumist, mida need tööriistad rakendavad, ja see on viide, mida tsiteerida, kui keegi pakub tuvastamise hoopis väljalülitamist.

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

Uurimine, mis ei saa vastust, on puhtas segmendis oodatav tulemus. Uurimine, mis toob esile vastuse, annab teile allesjäänud omaniku riistvara-aadressi, sama tõendi, mille Windowsi sündmus teile alguses andis. Hoidke see väljund muudatuste kirje juures, sest see on ainus tõestus, et aadress on ainulaadselt hoitud.