Jedno Windows računalo drži 10.8.0.2 i radi dok se redoslijed podizanja ne promijeni, a tada se ista adresa prijavljuje kao sukob iako se na klijentu ništa nije promijenilo. Drugi host na istom premoštenom segmentu traži istu vrijednost, a računalo koje završi konfiguraciju posljednje obično gubi. Oba vjeruju da je posjeduju, a gubitnik tiho prestaje koristiti adresu koju mu je naloženo da koristi. Upravo tretiranje toga kao problema s vremenom čini da se ponavlja pri svakom podizanju sustava.

Pročitajte dokaze sukoba prije nego dotaknete most

Windows prijavljuje sukob adrese zajedno s hardverskom adresom drugog podnositelja zahtjeva. Ta hardverska adresa je korisna činjenica jer vodi na jedno sučelje na jednom hostu, dok prikazano ime događaja ne govori ništa o tome gdje duplikat živi. Zapišite hardversku adresu prije nego bilo što promijenite.

ARP otkrivanje duplikata provjerava konkurentske vlasnike prije nego se adresa upotrijebi i nastavlja motriti poslije. Zato host koji je bio odsutan dok ste konfigurirali mrežu može izazvati sukob i sat kasnije. Provjera nije jednokratna pri podizanju. Računalo koje se pojavi kasnije može zauzeti adresu koja je cijeli dan bila u mirnoj upotrebi, i zato kvar izgleda kao utrka, a ne kao pogreška u konfiguraciji.

Događaj sukoba sam po sebi ne kaže koja je konfiguracija stvorila drugi zahtjev, a eksperimentalno brisanje adresa uništava mapiranje koje bi vam to reklo. Smisao dokaza je pretvoriti hardversku adresu u sučelje koje možete pregledati. Pretraga inventara po imenu računala obično vas odvede na pogrešan host.

Popišite svaki zahtjev na segmentu

Premoštena TAP postavka spaja Ethernet segmente koji su prije bili odvojeni, pa se adrese koje su bile jedinstvene unutar svojih mreža mogu sudariti kada okviri dijele jednu vezu. Zato ova klasa kvarova postoji na VPN-u, a ne postoji na rutiranim mrežama koje je zamijenio. Nabrojite svakog mogućeg vlasnika, a ne prvog na koga posumnjate.

Prođite popis ovim redom: adrese na svakom mostovnom uređaju i njegovim članskim portovima, OpenVPN bazen i svaka fiksna dodjela po klijentu, te svaki DHCP poslužitelj koji pokriva premošteni segment. Zatim usporedite hardversku adresu iz izvješća o sukobu sa sučeljima koja ste pronašli.

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

Bazen i DHCP raspon su dva vlasnika koja ljudi zaboravljaju. Ispišite oba raspona zajedno i potražite preklapanje prije nego učinite bilo što drugo. Ručno dodijeljena adresa mosta i bazen koji izdaje istu vrijednost kad-tad će se sudariti, a sukob izgleda slučajan dok se oba raspona ne ispišu jedan uz drugi.

Numerirajte mostove samo tamo gdje im treba identitet

U normalnom host mostu mostovni uređaj nosi konfiguraciju trećeg sloja hosta, a Ethernet i TAP članovi djeluju kao portovi. Davanje svakom članu vlastite adrese ili kopiranje jedne skripte za postavljanje na više računala bez promjene adrese jest način na koji jedan segment dobije tri vlasnika iste vrijednosti. Članovi ne trebaju vlastite identitete da bi prosljeđivali okvire. Treba im točno jedan identitet po hostu koji mora biti dostupan na tom segmentu.

Most koji samo prebacuje okvire ne treba nikakvu adresu na tom segmentu. Ako ga ostavite bez broja, uklanjate cijelu klasu sukoba, pod uvjetom da host još ima provjeren put za upravljanje. Prvo potvrdite pristup, drugo uklonite adresu, a treće provjerite dostupnost.

Ako je adresa koju ćete obrisati jedini put u računalo, brisanje kao eksperiment samoizazvani je prekid rada, a ne dijagnoza. Provjerite izvanpojasni put prije nego bilo što testirate.

Neka ispravak preživi podizanje sustava

Promjena aktivnog sučelja popravlja trenutno podizanje i ništa drugo. Što god ponovno stvara adresu pri podizanju, vratit će sukob pri sljedećem podizanju, a vi ćete zaključiti da ispravak nije radio, iako zapravo nikada nije bio trajan. Zabilježite koju ste datoteku promijenili, da sljedeće podizanje potvrdi odluku umjesto da otkrije iznenađenje.

Nađite vlasnika te konfiguracije: profil mrežnog upravitelja, datoteku po sučelju, definiciju kontejnera ili VM-a, ili cloud-init fragment. Promijenite je tamo, pa namjerno podignite jedan pogođeni host da potvrdite da se vraća nova vrijednost. Podizanje je jedini test koji dokazuje trajnost.

Rezervirajte adrese mosta unutar DHCP raspona kao izuzetke ili ih premjestite izvan njega. Rezervacija koja postoji samo u tablici nije izuzetak i alokator je neće pročitati.

Dokažite to sa svakim klijentom na mreži

Jedna uspješna veza ne dokazuje ništa, jer se izvorni simptom pojavljivao samo kada se redoslijed promijeni. Podignite svakog predviđenog klijenta, mijenjajte redoslijed podizanja i ponovite nakon ponovnog spajanja. Zatim ponovno podignite host koji je prije gubio utrku i potvrdite da adresa preživljava.

Za izravnu potvrdu provjerite postoji li dupli vlasnik prije dodjele adrese i nakon toga motrite tablicu susjeda. Ako ništa ne odgovori na provjeru i adresa ostane jedinstveno posjedovana kroz cijeli ciklus podizanja, sukob je riješen, a ne samo skriven. Naredbe ispod izvode obje provjere na mostovnom uređaju. RFC 5227 opisuje ponašanje provjere i najave koje ovi alati izvode, i to je referenca koju treba citirati kada netko predloži da se otkrivanje umjesto toga isključi.

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

Provjera koja ne dobije odgovor očekivani je rezultat na čistom segmentu. Provjera koja izazove odgovor daje vam hardversku adresu preostalog vlasnika, isti dokaz koji vam je Windows događaj dao na početku. Sačuvajte taj izlaz uz zapis o promjeni, jer je to jedini dokaz da je adresa jedinstveno držana.

Povezani članci