Du savininkai, vienas adresas: pasikartojantys IP TAP tilte

Vienas Windows klientas laiko 10.8.0.2 ir veikia, kol pasikeičia paleidimo tvarka; tada tas pats adresas pranešamas kaip konfliktas, nors kliente niekas nepasikeitė. Antrasis to paties sujungto segmento hostas reikalauja tos pačios reikšmės, o mašina, kuri konfigūraciją baigia paskutinė, paprastai pralaimi. Abu tiki, kad adresas jų, o pralaimėtojas tyliai nustoja naudoti adresą, kurį jam buvo liepta naudoti. Būtent vertinimas to kaip laiko problemos ir lemia, kad tai kartojasi po kiekvieno paleidimo.

Perskaitykite konflikto įrodymus prieš liesdami tiltą

Windows praneša apie adreso konfliktą kartu su kito pretendento aparatinės įrangos adresu. Būtent šis aparatinės įrangos adresas yra naudingas faktas, nes jis atitinka vieną sąsają viename hoste, o įvykio rodomas pavadinimas nieko nesako apie tai, kur yra dublikatas. Užsirašykite aparatinės įrangos adresą prieš ką nors keisdami.

ARP pagrįstas dublikatų aptikimas tikrina konkuruojančius savininkus prieš naudojant adresą ir toliau stebi po to. Todėl hostas, kurio nebuvo, kai konfigūravote tinklą, gali sukelti konfliktą ir po valandos. Patikra nėra vienkartinė paleidimo metu. Vėliau pasirodžiusi mašina gali paimti adresą, kuris visą dieną buvo ramiai naudojamas, ir todėl gedimas atrodo kaip lenktynės, o ne konfigūracijos klaida.

Konflikto įvykis pats savaime nenurodo, kuri konfigūracija sukūrė kitą pretenziją, o eksperimentinis adresų šalinimas sunaikina atitikimą, kuris būtų tai pasakęs. Įrodymo esmė – paversti aparatinės įrangos adresą sąsaja, kurią galite patikrinti. Inventoriaus paieška pagal mašinos pavadinimą paprastai nuveda jus prie netinkamo hosto.

Surašykite kiekvieną segmento pretenziją

Sujungta TAP sąranka sujungia Ethernet segmentus, kurie anksčiau buvo atskiri, todėl adresai, buvę unikalūs savo tinkluose, gali susidurti, kai kadrai naudoja vieną jungtį. Todėl ši gedimų klasė egzistuoja VPN ir neegzistuoja maršrutizuotuose tinkluose, kuriuos ji pakeitė. Išvardykite kiekvieną galimą savininką, o ne pirmąjį, kuriuo įtariate.

Pereikite sąrašą tokia tvarka: adresai kiekviename tilto įrenginyje ir jo nario portuose, OpenVPN baseinas ir bet koks fiksuotas priskyrimas klientui, taip pat bet kuris DHCP serveris, apimantis sujungtą segmentą. Tada sugretinkite konflikto ataskaitos aparatinės įrangos adresą su rastoms sąsajomis.

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

Baseinas ir DHCP diapazonas yra du savininkai, kuriuos žmonės pamiršta. Išspausdinkite abu diapazonus kartu ir prieš ką nors darydami ieškokite persidengimo. Rankiniu būdu priskirtas tilto adresas ir baseinas, išduodantis tą pačią reikšmę, anksčiau ar vėliau susidurs, o susidūrimas atrodo atsitiktinis, kol abu diapazonai neišspausdinami vienas šalia kito.

Numeruokite tiltus tik ten, kur jiems reikia tapatybės

Įprastame hosto tilte tilto įrenginys neša hosto trečiojo sluoksnio konfigūraciją, o Ethernet ir TAP nariai veikia kaip prievadai. Kiekvienam nariui suteikti savo adresą arba kopijuoti vieną sąrankos scenarijų į kelias mašinas nekeičiant adreso – tai būdas, kuriuo vienas segmentas įgyja tris tos pačios reikšmės savininkus. Nariams nereikia savo tapatybių kadrams persiųsti. Jiems reikia tiksliai vienos tapatybės kiekvienam hostui, kuris turi būti pasiekiamas tame segmente.

Tiltui, kuris tik perjungia kadrus, tame segmente adreso visai nereikia. Palikus jį be numerio, pašalinama visa susidūrimų klasė, su sąlyga, kad hostas vis dar turi jūsų patikrintą valdymo kelią. Pirmiausia patvirtinkite prieigą, antra pašalinkite adresą, trečia patikrinkite pasiekiamumą.

Jei adresas, kurį ketinate ištrinti, yra vienintelis kelias į mašiną, jo trynimas kaip eksperimentas yra paties sukelta prastova, o ne diagnostika. Patikrinkite užjuostinį kelią prieš ką nors testuodami.

Padarykite, kad pataisymas išliktų po paleidimo

Veikiančios sąsajos keitimas sutaiso dabartinį paleidimą ir nieko daugiau. Kas bebūtų, kas paleidimo metu iš naujo sukuria adresą, atkurs konfliktą kitą kartą paleidus, ir jūs padarysite išvadą, kad pataisymas neveikė, nors iš tikrųjų jis niekada nebuvo ilgalaikis. Užsirašykite, kurį failą pakeitėte, kad kitas paleidimas patvirtintų sprendimą, o ne atskleistų netikėtumą.

Raskite tos konfigūracijos savininką: tinklo tvarkyklės profilis, failas kiekvienai sąsajai, konteinerio ar VM apibrėžtis arba cloud-init fragmentas. Pakeiskite jį ten, tada sąmoningai paleiskite iš naujo vieną paveiktą hostą, kad patvirtintumėte, jog grįžta nauja reikšmė. Paleidimas iš naujo yra vienintelis testas, įrodantis ilgaamžiškumą.

Rezervuokite tilto adresus DHCP diapazone kaip išimtis arba perkelkite juos už jo ribų. Rezervacija, egzistuojanti tik skaičiuoklėje, nėra išimtis, ir paskirstytojas jos neskaito.

Įrodykite tai, kai visi klientai prisijungę

Vienas sėkmingas prisijungimas nieko neįrodo, nes pradinis simptomas pasireikšdavo tik pasikeitus tvarkai. Pakelkite kiekvieną numatytą klientą, keiskite paleidimo tvarką ir pakartokite po prisijungimo iš naujo. Tada paleiskite iš naujo hostą, kuris anksčiau pralaimėdavo lenktynes, ir patvirtinkite, kad adresas išlieka.

Tiesioginiam patvirtinimui prieš priskirdami adresą patikrinkite, ar nėra dublikato savininko, o po to stebėkite kaimynų lentelę. Jei niekas neatsako į patikrą ir adresas išlieka unikaliai valdomas per visą paleidimo ciklą, konfliktas išspręstas, o ne tik paslėptas. Toliau pateiktos komandos atlieka abu patikrinimus tilto įrenginyje. RFC 5227 aprašo patikros ir paskelbimo elgseną, kurią taiko šie įrankiai, ir tai yra šaltinis, kuriuo remiamasi, kai kas nors siūlo išjungti aptikimą.

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

Patikra, kuri negauna atsakymo, yra laukiamas rezultatas švariame segmente. Patikra, kuri iššaukia atsakymą, duoda jums likusio savininko aparatinės įrangos adresą, tą patį įrodymą, kurį Windows įvykis davė pradžioje. Saugokite šią išvestį su pakeitimo įrašu, nes tai vienintelis įrodymas, kad adresas laikomas unikaliai.