Dva vlastníci, jedna adresa: duplicitní IP na TAP mostu

Jeden klient Windows drží 10.8.0.2 a funguje, dokud se nezmění pořadí spouštění; pak je stejná adresa hlášena jako konflikt, i když se na klientovi nic nezměnilo. Druhý hostitel na stejném přemostěném segmentu si nárokuje stejnou hodnotu a stroj, který konfiguraci dokončí jako poslední, obvykle prohrává. Oba věří, že ji vlastní, a poražený tiše přestane používat adresu, kterou mu bylo řečeno používat. Právě pokládání této věci za problém s časováním způsobuje, že se vrací při každém restartu.

Přečtěte si důkazy konfliktu, než se dotknete mostu

Windows hlásí konflikt adresy spolu s hardwarovou adresou druhého nárokovatele. Právě tato hardwarová adresa je užitečný údaj, protože odpovídá jednomu rozhraní na jednom hostiteli, zatímco zobrazený název události neříká nic o tom, kde duplikát sídlí. Než cokoli změníte, hardwarovou adresu si zapište.

Detekce duplicit založená na ARP sondou ověřuje konkurenční vlastníky před použitím adresy a poté dál sleduje. Proto hostitel, který při konfiguraci sítě chyběl, může způsobit konflikt i o hodinu později. Sonda není jednorázová kontrola při startu. Stroj, který se objeví později, může obsadit adresu, jež byla celý den v klidném užívání, a proto se porucha jeví jako závod, nikoli jako chyba konfigurace.

Událost konfliktu sama o sobě neříká, která konfigurace vytvořila druhý nárok, a experimentální mazání adres ničí mapování, které by vám to řeklo. Smyslem důkazů je převést hardwarovou adresu na rozhraní, které můžete prozkoumat. Hledání v inventáři podle názvu stroje vás obvykle zavede na špatného hostitele.

Zinventarizujte každý nárok v segmentu

Přemostěné zapojení TAP spojuje segmenty Ethernetu, které bývaly oddělené, takže adresy jedinečné uvnitř vlastních sítí se mohou srazit, jakmile rámce sdílejí jedno spojení. Proto tato třída poruch existuje na VPN a neexistuje na routovaných sítích, které nahradila. Vyjmenujte každého možného vlastníka, ne prvního, na kterého máte podezření.

Projděte seznam v tomto pořadí: adresy na každém mostovém zařízení a jeho členských portech, OpenVPN fond a jakékoli pevné přiřazení pro klienta a jakýkoli server DHCP pokrývající přemostěný segment. Potom porovnejte hardwarovou adresu ze zprávy o konfliktu s rozhraními, která jste našli.

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

Fond a rozsah DHCP jsou dva vlastníci, na které se zapomíná. Vypište oba rozsahy společně a před čímkoli dalším hledejte překryv. Ručně přidělená adresa mostu a fond, který vydává stejnou hodnotu, se dříve či později srazí a srážka vypadá náhodně, dokud se oba rozsahy nevypíšou vedle sebe.

Číslujte mosty jen tam, kde potřebují identitu

V běžném mostu hostitele nese mostové zařízení konfiguraci třetí vrstvy hostitele a členové Ethernet a TAP fungují jako porty. Dát každému členu vlastní adresu nebo zkopírovat jeden instalační skript na několik strojů beze změny adresy je způsob, jak jeden segment získá tři vlastníky stejné hodnoty. Členové ke směrování rámců vlastní identity nepotřebují. Potřebují přesně jednu identitu na hostitele, který musí být v tomto segmentu dosažitelný.

Most, který jen přepíná rámce, v tomto segmentu žádnou adresu nepotřebuje. Ponecháte-li ho bez čísla, odstraníte celou třídu kolizí, ovšem za předpokladu, že hostitel má stále ověřenou cestu pro správu. Nejprve potvrďte přístup, potom adresu odstraňte a nakonec zkontrolujte dostupnost.

Pokud je adresa, kterou se chystáte smazat, jedinou cestou do stroje, je její smazání jako experiment samo sobě způsobený výpadek, nikoli diagnóza. Ověřte mimosíťovou cestu, než cokoli otestujete.

Zajistěte, aby oprava přežila restart

Změna živého rozhraní opraví aktuální spuštění a nic jiného. Cokoli adresu při startu znovu vytváří, obnoví konflikt při příštím restartu a vy uzavřete, že oprava nefungovala, ačkoli ve skutečnosti nikdy nebyla trvalá. Poznamenejte si, který soubor jste změnili, aby příští restart potvrdil rozhodnutí, místo aby odhalil překvapení.

Najděte vlastníka této konfigurace: profil správce sítě, soubor pro rozhraní, definici kontejneru nebo VM, nebo fragment cloud-init. Změňte ji tam a poté záměrně restartujte jeden zasažený hostitel, abyste potvrdili, že se vrací nová hodnota. Restart je jediný test, který prokáže trvalost.

Rezervujte adresy mostu uvnitř rozsahu DHCP jako výjimky, nebo je přesuňte mimo něj. Rezervace, která existuje jen v tabulce, není výjimkou a alokátor ji nečte.

Dokažte to se všemi klienty online

Jediné úspěšné připojení nic nedokazuje, protože původní příznak se objevoval jen při změně pořadí. Zapněte každého zamýšleného klienta, měňte pořadí spouštění a po opětovném připojení to zopakujte. Poté restartujte hostitele, který dřív závod prohrával, a potvrďte, že adresa přežije.

Pro přímé potvrzení proveďte před přidělením adresy sondu na duplicitního vlastníka a poté sledujte tabulku sousedů. Pokud na sondu nic neodpoví a adresa zůstane jedinečně vlastněná během celého cyklu restartu, konflikt je vyřešen, ne jen skryt. Níže uvedené příkazy provádějí obě kontroly na mostovém zařízení. RFC 5227 popisuje chování sondy a oznámení, které tyto nástroje uplatňují, a je to reference, na kterou se odkazuje, když někdo navrhne detekci raději vypnout.

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

Sonda, která nedostane odpověď, je očekávaný výsledek v čistém segmentu. Sonda, která vyvolá odpověď, vám dá hardwarovou adresu zbývajícího vlastníka, stejný důkaz, jaký vám na začátku dal událost Windows. Uchovejte tento výstup u záznamu o změně, protože je jediným důkazem, že adresa je jedinečně držena.