Két tulajdonos, egy cím: duplikált IP-k egy TAP-hídon

Egy Windows-kliens megtartja a 10.8.0.2 címet, és addig működik, amíg az indítási sorrend meg nem változik; akkor ugyanazt a címet ütközésként jelenti, pedig a kliensen semmi sem változott. Egy második gazdagép ugyanabban az áthidalt szegmensben ugyanarra az értékre tart igényt, és általában az a gép veszít, amelyik utoljára fejezi be a konfigurálást. Mindkettő azt hiszi, hogy övé, és a vesztes csendben felhagy egy olyan cím használatával, amelyet utasítottak rá, hogy használjon. Éppen az, hogy ezt időzítési problémának tekintjük, okozza, hogy minden újraindításnál visszatér.

Olvassa el az ütközés bizonyítékait, mielőtt hozzányúlna egy hídhoz

A Windows a címütközést a másik igénylő hardvercímével együtt jelenti. Ez a hardvercím a hasznos tény, mert egy gazdagépen egyetlen interfészre képez le, míg az esemény megjelenített neve semmit sem mond arról, hol lakik a duplikátum. Jegyezze fel a hardvercímet, mielőtt bármit megváltoztat.

Az ARP-alapú duplikátumészlelés a cím használata előtt versengő tulajdonosokat vizsgál, utána pedig tovább figyel. Ezért egy olyan gazdagép, amely hiányzott a hálózat konfigurálása közben, egy órával később is okozhat ütközést. A vizsgálat nem egyszeri ellenőrzés indításkor. Egy később megjelenő gép elvehet egy címet, amely egész nap nyugodt használatban volt, és ezért tűnik a hiba versenynek, nem konfigurációs hibának.

Egy ütközésesemény önmagában nem mondja meg, melyik konfiguráció hozta létre a másik igényt, a címek kísérleti törlése pedig megsemmisíti azt a leképezést, amely megmondta volna. A bizonyíték célja, hogy a hardvercímből vizsgálható interfész legyen. A leltár gépnév szerinti keresése általában a rossz gazdagéphez küldi.

Leltározza fel a szegmens minden igényét

Egy áthidalt TAP-beállítás olyan Ethernet-szegmenseket köt össze, amelyek korábban külön voltak, így a saját hálózatukban egyedi címek ütközhetnek, amint a keretek egy linket osztanak meg. Ezért létezik ez a hibaosztály VPN-en, és nem létezik az általa leváltott útvonalválasztott hálózatokon. Soroljon fel minden lehetséges tulajdonost, ne az elsőt, akire gyanakszik.

Járja végig a listát ebben a sorrendben: az egyes híd-eszközök és tagsági portjaik címei, a OpenVPN gyűjtő és bármilyen ügyfélre szabott állandó hozzárendelés, valamint minden DHCP-kiszolgáló, amely lefedi az áthidalt szegmenst. Ezután feleljen meg az ütközésjelentés hardvercíme a talált interfészeknek.

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

A gyűjtő és a DHCP-tartomány az a két tulajdonos, amelyről megfeledkeznek. Nyomtassa ki a két tartományt együtt, és keressen átfedést, mielőtt bármi mást tenne. Egy kézzel kiosztott híd-cím és egy ugyanazt az értéket osztó gyűjtő előbb-utóbb ütközni fog, és az ütközés véletlenszerűnek tűnik, amíg a két tartomány egymás mellett ki nem nyomtatják.

Csak ott számozzon hídakat, ahol identitásra van szükségük

Egy szokásos gazdagép-hídban a híd-eszköz hordozza a gazdagép harmadik rétegbeli konfigurációját, az Ethernet- és TAP-tagok pedig portként működnek. Ha minden tagnak saját címet ad, vagy egy telepítőszkriptet címváltoztatás nélkül több gépre másol, akkor jut egy szegmens három tulajdonoshoz ugyanarra az értékre. A tagoknak nincs szükségük saját identitásra a keretek továbbításához. Pontosan egy identitásra van szükségük gazdagépenként, amelynek elérhetőnek kell lennie azon a szegmensen.

Egy hídnak, amely csak kereteket kapcsol, egyáltalán nincs szüksége címre azon a szegmensen. Számozatlanul hagyása az ütközések egész osztályát szünteti meg, feltéve, hogy a gazdagépnek még van ellenőrzött felügyeleti útvonala. Először erősítse meg a hozzáférést, másodszor távolítsa el a címet, harmadszor ellenőrizze az elérhetőséget.

Ha a törölni kívánt cím az egyetlen út a géphez, akkor kísérletként törölni önmaga okozta kiesés, nem diagnózis. Ellenőrizze a sávon kívüli útvonalat, mielőtt bármit tesztel.

Tegye a javítást újraindításállóvá

Egy élő interfész módosítása az aktuális indítást javítja, semmi mást. Bármi, ami indításkor újra létrehozza a címet, visszaállítja az ütközést a következő újraindításkor, és arra a következtetésre jut, hogy a javítás nem működött, pedig valójában soha nem volt tartós. Jegyezze fel, melyik fájlt módosította, hogy a következő újraindítás megerősítsen egy döntést, ne pedig meglepetést tárjon fel.

Keresse meg a konfiguráció tulajdonosát: hálózatkezelő profil, interfészenkénti fájl, konténer- vagy VM-definíció, vagy cloud-init töredék. Ott módosítsa, majd szándékosan indítson újra egy érintett gazdagépet, hogy megerősítse: az új érték jön vissza. Az újraindítás az egyetlen teszt, amely bizonyítja a tartósságot.

Foglalja le a híd címeket a DHCP-tartományon belül kivételként, vagy helyezze azon kívülre. Egy csak táblázatban létező foglalás nem kivétel, és az osztó nem fogja elolvasni.

Bizonyítsa minden ügyfél online állapotában

Egyetlen sikeres kapcsolat semmit sem bizonyít, mert az eredeti tünet csak a sorrend változásakor jelent meg. Indítsa el az összes szándékolt ügyfelet, változtassa az indítási sorrendet, és ismételje meg újracsatlakozás után. Ezután indítsa újra a gazdagépet, amely korábban elvesztette a versenyt, és erősítse meg, hogy a cím túléli.

Közvetlen megerősítéshez a cím kiosztása előtt vizsgáljon duplikált tulajdonos után, utána pedig figyelje a szomszédtáblát. Ha semmi nem válaszol a vizsgálatra, és a cím egy teljes újraindítási cikluson át egyedüli tulajdonban marad, az ütközés megoldódott, nem csupán elrejtődött. Az alábbi parancsok mindkét ellenőrzést elvégzik a híd-eszközön. RFC 5227 írja le azt a vizsgálati és bejelentési viselkedést, amelyet ezek az eszközök gyakorolnak, és ez az a hivatkozás, amelyet idézni kell, amikor valaki az észlelés kikapcsolását javasolja.

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

A válasz nélküli vizsgálat a várt eredmény tiszta szegmensen. A választ kiváltó vizsgálat megadja a maradék tulajdonos hardvercímét, ugyanazt a bizonyítékot, amelyet a Windows-esemény adott az elején. Őrizze meg ezt a kimenetet a változási rekorddal, mert ez az egyetlen bizonyíték arra, hogy a címet egyedileg tartják.