Dwóch właścicieli, jeden adres: duplikaty IP na moście TAP

Jeden klient Windows trzyma 10.8.0.2 i działa, dopóki nie zmieni się kolejność uruchamiania; wtedy ten sam adres jest zgłaszany jako konflikt, choć w kliencie nic się nie zmieniło. Drugi host w tym samym pomostowanym segmencie rości sobie tę samą wartość, a maszyna, która kończy konfigurację jako ostatnia, zwykle przegrywa. Oba uważają, że adres jest ich, a przegrany po cichu przestaje używać adresu, który kazano mu używać. Właśnie traktowanie tego jako problemu z czasem sprawia, że powraca przy każdym restarcie.

Przeczytaj dowody konfliktu, zanim dotkniesz mostu

Windows zgłasza konflikt adresu wraz z adresem sprzętowym drugiego roszczącego. Ten adres sprzętowy jest użytecznym faktem, bo wskazuje jeden interfejs na jednym hoście, podczas gdy wyświetlana nazwa zdarzenia nie mówi nic o tym, gdzie mieszka duplikat. Zapisz adres sprzętowy, zanim cokolwiek zmienisz.

Wykrywanie duplikatów oparte na ARP sonduje konkurencyjnych właścicieli przed użyciem adresu i obserwuje dalej po nim. Dlatego host, którego nie było podczas konfiguracji sieci, może wywołać konflikt jeszcze godzinę później. Sonda nie jest jednorazowym sprawdzeniem przy starcie. Maszyna, która pojawi się później, może zająć adres używany spokojnie przez cały dzień, i dlatego awaria czyta się jak wyścig, a nie błąd konfiguracji.

Samo zdarzenie konfliktu nie mówi, która konfiguracja stworzyła drugie roszczenie, a eksperymentalne czyszczenie adresów niszczy powiązanie, które by ci to powiedziało. Sens dowodu polega na zamianie adresu sprzętowego w interfejs, który możesz sprawdzić. Szukanie w inwentarzu po nazwie maszyny zwykle prowadzi do niewłaściwego hosta.

Zinwentaryzuj każde roszczenie w segmencie

Pomostowa konfiguracja TAP łączy segmenty Ethernet, które wcześniej były osobne, więc adresy unikalne w swoich sieciach mogą się zderzyć, gdy ramki dzielą jedno łącze. Dlatego ta klasa awarii istnieje w VPN, a nie istnieje w sieciach rutowanych, które zastąpiła. Wymień każdego możliwego właściciela, a nie pierwszego, którego podejrzewasz.

Przejdź listę w tej kolejności: adresy na każdym urządzeniu mostu i jego portach członkowskich, OpenVPN i wszelkie stałe przypisanie dla klienta oraz każdy serwer DHCP obejmujący pomostowany segment. Następnie dopasuj adres sprzętowy z raportu konfliktu do znalezionych interfejsów.

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

Pula i zakres DHCP to dwaj właściciele, o których się zapomina. Wydrukuj oba zakresy razem i poszukaj nakładania, zanim zrobisz cokolwiek innego. Ręcznie przypisany adres mostu i pula wydająca tę samą wartość prędzej czy później się zderzą, a kolizja wygląda losowo, dopóki oba zakresy nie zostaną wydrukowane obok siebie.

Numeruj mosty tylko tam, gdzie potrzebują tożsamości

W normalnym moście hosta urządzenie mostu niesie konfigurację trzeciej warstwy hosta, a członkowie Ethernet i TAP działają jako porty. Dawanie każdemu członkowi własnego adresu albo kopiowanie jednego skryptu instalacyjnego na kilka maszyn bez zmiany adresu to sposób, w jaki jeden segment zyskuje trzech właścicieli tej samej wartości. Członkowie nie potrzebują własnych tożsamości, aby przekazywać ramki. Potrzebują dokładnie jednej tożsamości na host, który musi być osiągalny w tym segmencie.

Most, który tylko przełącza ramki, w ogóle nie potrzebuje adresu w tym segmencie. Pozostawienie go bez numeru usuwa całą klasę kolizji, pod warunkiem że host nadal ma zweryfikowaną przez ciebie ścieżkę zarządzania. Najpierw potwierdź dostęp, drugie usuń adres, a trzecie sprawdź osiągalność.

Jeśli adres, który zamierzasz usunąć, jest jedyną drogą do maszyny, usunięcie go jako eksperymentu jest samo wyrządzoną awarią, a nie diagnozą. Zweryfikuj ścieżkę poza pasmem, zanim czegokolwiek spróbujesz.

Spraw, aby poprawka przetrwała restart

Zmiana działającego interfejsu naprawia bieżące uruchomienie i nic więcej. Cokolwiek odtwarza adres przy starcie, przywróci konflikt przy następnym restarcie, a ty dojdziesz do wniosku, że poprawka nie zadziałała, choć w rzeczywistości nigdy nie była trwała. Zanotuj, który plik zmieniłeś, aby następny restart potwierdził decyzję, a nie ujawnił niespodziankę.

Znajdź właściciela tej konfiguracji: profil menedżera sieci, plik dla interfejsu, definicja kontenera lub VM, albo fragment cloud-init. Zmień go tam, a następnie celowo zrestartuj jeden dotknięty host, aby potwierdzić, że wraca nowa wartość. Restart to jedyny test, który dowodzi trwałości.

Zarezerwuj adresy mostu w zakresie DHCP jako wykluczenia albo przenieś je poza niego. Rezerwacja istniejąca tylko w arkuszu kalkulacyjnym nie jest wykluczeniem, a alokator jej nie odczyta.

Udowodnij to przy wszystkich klientach online

Jedno udane połączenie niczego nie dowodzi, bo pierwotny objaw pojawiał się tylko przy zmianie kolejności. Uruchom każdego zamierzonego klienta, zmień kolejność startu i powtórz po ponownym połączeniu. Następnie zrestartuj host, który wcześniej przegrywał wyścig, i potwierdź, że adres przetrwa.

Aby potwierdzić bezpośrednio, sprawdź przed przypisaniem adresu, czy nie ma duplikatu właściciela, a potem obserwuj tablicę sąsiadów. Jeśli nic nie odpowiada na sondę, a adres pozostaje unikalnie posiadany przez pełny cykl restartu, konflikt jest rozwiązany, a nie tylko ukryty. Poniższe polecenia wykonują oba sprawdzenia na urządzeniu mostu. RFC 5227 opisuje zachowanie sondowania i ogłaszania, które wykonują te narzędzia, i jest to źródło, na które się powołuje, gdy ktoś proponuje wyłączenie wykrywania.

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

Sonda bez odpowiedzi to oczekiwany wynik w czystym segmencie. Sonda, która wywoła odpowiedź, daje adres sprzętowy pozostałego właściciela, ten sam dowód, który zdarzenie Windows dało na początku. Zachowaj ten wynik wraz z zapisem zmian, bo to jedyny dowód, że adres jest unikalnie trzymany.