Dva vlasnika, jedna adresa: duple IP adrese na TAP mostu

Jedan Windows klijent 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 podnosioca zahtjeva. Ta hardverska adresa je korisna činjenica jer vodi na jedan interfejs na jednom hostu, dok prikazano ime događaja ne govori ništa o tome gdje duplikat živi. Zapišite hardversku adresu prije nego bilo šta promijenite.

ARP otkrivanje duplikata provjerava konkurentske vlasnike prije nego se adresa upotrijebi i nastavlja motriti poslije. Zato host koji je bio odsutan dok ste konfigurisali 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 greš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 interfejs koji 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 listu ovim redom: adrese na svakom mostovnom uređaju i njegovim članskim portovima, OpenVPN bazen i svaka fiksna dodjela po klijentu, te svaki DHCP server koji pokriva premošteni segment. Zatim uporedite hardversku adresu iz izvještaja o sukobu s interfejsima koje 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 šta 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.

Numerišite 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 jeste 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 uslovom 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 je samoizazvani prekid rada, a ne dijagnoza. Provjerite vanpojasni put prije nego bilo šta testirate.

Neka ispravka preživi podizanje sustava

Promjena aktivnog interfejsa popravlja trenutno podizanje i ništa drugo. Šta god ponovno stvara adresu pri podizanju, vratit će sukob pri sljedećem podizanju, a vi ćete zaključiti da ispravka nije radila, iako zapravo nikada nije bila trajna. 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 interfejsu, 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.

Rezervišite adrese mosta unutar DHCP raspona kao izuzetke ili ih premjestite izvan njega. Rezervacija koja postoji samo u tabeli 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 ponovo 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 neko 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.