Dvaja vlastníci, jedna adresa: duplicitné IP na TAP moste

Jeden klient Windows drží 10.8.0.2 a funguje, kým sa nezmení poradie spúšťania; potom je tá istá adresa hlásená ako konflikt, hoci sa na klientovi nič nezmenilo. Druhý hostiteľ v tom istom premostenom segmente si nárokuje rovnakú hodnotu a stroj, ktorý konfiguráciu dokončí ako posledný, zvyčajne prehráva. Obaja veria, že ju vlastnia, a porazený ticho prestane používať adresu, ktorú mal používať. Práve pokladanie tejto veci za problém s časovaním spôsobuje, že sa vracia pri každom reštarte.

Prečítajte si dôkazy konfliktu, než sa dotknete mosta

Windows hlási konflikt adresy spolu s hardvérovou adresou druhého nárokovateľa. Práve táto hardvérová adresa je užitočný údaj, pretože zodpovedá jednému rozhraniu na jednom hostiteľovi, zatiaľ čo zobrazený názov udalosti nehovorí nič o tom, kde duplikát sídli. Než čokoľvek zmeníte, hardvérovú adresu si zapíšte.

Detekcia duplicít založená na ARP sondou overuje konkurenčných vlastníkov pred použitím adresy a potom ďalej sleduje. Preto hostiteľ, ktorý pri konfigurácii siete chýbal, môže spôsobiť konflikt aj o hodinu neskôr. Sonda nie je jednorazová kontrola pri štarte. Stroj, ktorý sa objaví neskôr, môže obsadiť adresu, ktorá bola celý deň v pokojnom používaní, a preto sa porucha javí ako preteky, nie ako chyba konfigurácie.

Udalosť konfliktu sama o sebe nehovorí, ktorá konfigurácia vytvorila druhý nárok, a experimentálne mazanie adries ničí mapovanie, ktoré by vám to povedalo. Zmyslom dôkazu je premeniť hardvérovú adresu na rozhranie, ktoré môžete preskúmať. Hľadanie v inventári podľa názvu stroja vás zvyčajne zavedie na nesprávneho hostiteľa.

Zinventarizujte každý nárok v segmente

Premostené zapojenie TAP spája segmenty Ethernetu, ktoré bývali oddelené, takže adresy jedinečné v rámci vlastných sietí sa môžu zraziť, hneď ako rámce zdieľajú jedno spojenie. Preto táto trieda porúch existuje na VPN a neexistuje na routovaných sieťach, ktoré nahradila. Vymenujte každého možného vlastníka, nie prvého, na ktorého máte podozrenie.

Prejdite zoznam v tomto poradí: adresy na každom mostovom zariadení a jeho členských portoch, OpenVPN fond a akékoľvek pevné priradenie pre klienta a akýkoľvek server DHCP pokrývajúci premostený segment. Potom porovnajte hardvérovú adresu zo správy o konflikte s rozhraniami, ktoré ste našli.

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

Fond a rozsah DHCP sú dvaja vlastníci, na ktorých sa zabúda. Vypíšte oba rozsahy spoločne a pred čímkoľvek ďalším hľadajte prekryv. Ručne pridelená adresa mosta a fond, ktorý vydáva rovnakú hodnotu, sa skôr či neskôr zrazia a zrážka vyzerá náhodne, kým sa oba rozsahy nevypíšu vedľa seba.

Číslujte mosty len tam, kde potrebujú identitu

V bežnom moste hostiteľa nesie mostové zariadenie konfiguráciu tretej vrstvy hostiteľa a členovia Ethernet a TAP fungujú ako porty. Dať každému členovi vlastnú adresu alebo skopírovať jeden inštalačný skript na viacero strojov bez zmeny adresy je spôsob, akým jeden segment získa troch vlastníkov rovnakej hodnoty. Členovia nepotrebujú vlastné identity na to, aby posielali rámce ďalej. Potrebujú presne jednu identitu na hostiteľa, ktorý musí byť v tomto segmente dosiahnuteľný.

Most, ktorý iba prepína rámce, v tomto segmente nepotrebuje žiadnu adresu. Ak ho necháte bez čísla, odstránite celú triedu kolízií, za predpokladu, že hostiteľ má stále overenú cestu správy. Najprv potvrďte prístup, potom adresu odstráňte a nakoniec skontrolujte dostupnosť.

Ak je adresa, ktorú sa chystáte zmazať, jedinou cestou do stroja, jej zmazanie ako experiment je samo spôsobený výpadok, nie diagnóza. Overte mimopásmovú cestu, než čokoľvek otestujete.

Zaistite, aby oprava prežila reštart

Zmena živého rozhrania opraví aktuálne spustenie a nič iné. Čokoľvek adresu pri štarte znova vytvára, obnoví konflikt pri ďalšom reštarte a vy uzavriete, že oprava nefungovala, hoci v skutočnosti nikdy nebola trvalá. Poznamenajte si, ktorý súbor ste zmenili, aby ďalší reštart potvrdil rozhodnutie, namiesto toho, aby odhalil prekvapenie.

Nájdite vlastníka tejto konfigurácie: profil správcu siete, súbor pre rozhranie, definíciu kontajnera alebo VM, alebo fragment cloud-init. Zmeňte ju tam a potom zámerne reštartujte jedného zasiahnutého hostiteľa, aby ste potvrdili, že sa vracia nová hodnota. Reštart je jediný test, ktorý preukazuje trvalosť.

Rezervujte adresy mosta v rozsahu DHCP ako výnimky, alebo ich presuňte mimo neho. Rezervácia, ktorá existuje len v tabuľke, nie je výnimkou a alokátor ju neprečíta.

Dokážte to so všetkými klientmi online

Jediné úspešné pripojenie nič nedokazuje, pretože pôvodný príznak sa objavoval len pri zmene poradia. Zapnite každého zamýšľaného klienta, meňte poradie spúšťania a po opätovnom pripojení to zopakujte. Potom reštartujte hostiteľa, ktorý predtým prehrával preteky, a potvrďte, že adresa prežije.

Na priame potvrdenie vykonajte pred pridelením adresy sondu na duplicitného vlastníka a potom sledujte tabuľku susedov. Ak na sondu nič neodpovie a adresa zostane jedinečne vlastnená počas celého cyklu reštartu, konflikt je vyriešený, nie len skrytý. Nižšie uvedené príkazy vykonávajú obe kontroly na mostovom zariadení. RFC 5227 opisuje správanie sondy a oznámenia, ktoré tieto nástroje uplatňujú, a je to referencia, na ktorú sa odkazuje, keď niekto navrhne detekciu radšej vypnúť.

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

Sonda, ktorá nedostane odpoveď, je očakávaný výsledok v čistom segmente. Sonda, ktorá vyvolá odpoveď, vám dá hardvérovú adresu zostávajúceho vlastníka, rovnaký dôkaz, aký vám na začiatku dal udalosť Windows. Uchovajte tento výstup pri zázname o zmene, pretože je jediným dôkazom, že adresa je jedinečne držaná.