Doi proprietari, o singură adresă: IP-uri duplicate pe un pod TAP

Un client Windows păstrează 10.8.0.2 și funcționează până când se schimbă ordinea de pornire; atunci aceeași adresă este raportată ca un conflict, deși la client nu s-a schimbat nimic. Un al doilea gazdă din același segment punte revendică aceeași valoare, iar mașina care termină configurarea ultima pierde de obicei. Ambele cred că adresa este a lor, iar învinsul încetează în liniște să folosească o adresă despre care i s-a spus să o folosească. Tocmai tratarea acestui lucru ca o problemă de sincronizare face ca el să revină la fiecare repornire.

Citiți dovezile conflictului înainte de a atinge un pod

Windows raportează un conflict de adresă împreună cu adresa de hardware a celuilalt solicitant. Acea adresă de hardware este faptul util, pentru că indică o singură interfață de pe un singur gazdă, în timp ce numele afișat al evenimentului nu spune nimic despre locul unde se află duplicatul. Notați adresa de hardware înainte de a schimba ceva.

Detectarea duplicatelor bazată pe ARP testează proprietarii concurenți înainte ca o adresă să fie folosită și continuă să supravegheze după aceea. De aceea un gazdă care lipsea cât timp configurați rețeaua poate provoca un conflict și o oră mai târziu. Verificarea nu este una unică la pornire. O mașină care apare mai târziu poate lua o adresă care a fost în uz liniștit toată ziua, și de aceea defectul se citește ca o cursă, nu ca o eroare de configurare.

Un eveniment de conflict singur nu spune ce configurație a creat cealaltă revendicare, iar ștergerea experimentală a adreselor distruge maparea care v-ar fi spus. Scopul dovezii este să transforme o adresă de hardware într-o interfață pe care o puteți inspecta. Căutarea în inventar după numele mașinii vă trimite de obicei la gazda greșită.

Inventariați fiecare revendicare din segment

O instalare TAP punte unește segmente Ethernet care înainte erau separate, așa că adrese care erau unice în propriile rețele pot intra în coliziune de îndată ce cadrele împart o singură legătură. De aceea această clasă de defecte există pe un VPN și nu există pe rețelele rutate pe care le-a înlocuit. Enumerați fiecare proprietar posibil, nu pe primul pe care îl bănuiți.

Parcurgeți lista în această ordine: adresele de pe fiecare dispozitiv de pod și porturile sale membre, OpenVPN și orice alocare fixă pentru fiecare client, precum și orice server DHCP care acoperă segmentul punte. Apoi potriviți adresa de hardware din raportul de conflict cu interfețele găsite.

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

Pool-ul și intervalul DHCP sunt cei doi proprietari pe care oamenii îi uită. Tipăriți ambele intervale împreună și căutați o suprapunere înainte de a face orice altceva. O adresă de pod atribuită manual și un pool care emite aceeași valoare se vor ciocni mai devreme sau mai târziu, iar ciocnirea pare aleatorie până când ambele intervale sunt tipărite unul lângă altul.

Numerotați podurile doar acolo unde au nevoie de o identitate

Într-un pod de gazdă normal, dispozitivul de pod poartă configurația de nivel trei a gazdei, iar membrii Ethernet și TAP acționează ca porturi. A da fiecărui membru propria adresă sau a copia un script de instalare pe mai multe mașini fără a schimba adresa este felul în care un singur segment ajunge cu trei proprietari ai aceleiași valori. Membrii nu au nevoie de identități proprii pentru a transmite cadre. Au nevoie de exact o identitate pe gazdă care trebuie să fie accesibilă în acel segment.

Un pod care doar comută cadre nu are nevoie deloc de o adresă în acel segment. Lăsarea lui fără număr elimină o întreagă clasă de coliziuni, cu condiția ca gazda să aibă încă o cale de administrare pe care ați verificat-o. Confirmați accesul primul, eliminați adresa al doilea și verificați accesibilitatea al treilea.

Dacă adresa pe care urmează să o ștergeți este singura rută către mașină, ștergerea ei ca experiment este o întrerupere auto-provovată, nu un diagnostic. Verificați calea din afara benzii înainte de a testa ceva.

Faceți corecția să supraviețuiască unei reporniri

Modificarea unei interfețe active repară pornirea curentă și nimic altceva. Orice recreează adresa la pornire va readuce conflictul la următoarea repornire, iar dumneavoastră veți concluziona că remedierea nu a funcționat, deși în realitate nu a fost niciodată persistentă. Notați ce fișier ați modificat, pentru ca următoarea repornire să confirme o decizie în loc să dezvăluie o surpriză.

Găsiți proprietarul acelei configurații: un profil de manager de rețea, un fișier pe interfață, o definiție de container sau VM, sau un fragment cloud-init. Modificați-o acolo, apoi reporniți intenționat un gazdă afectată pentru a confirma că valoarea nouă este cea care revine. O repornire este singurul test care dovedește persistența.

Rezervați adresele podului în interiorul intervalului DHCP ca excluderi, sau mutați-le în afara lui. O rezervare care există doar într-un tabel de calcul nu este o excludere, iar alocatorul nu o va citi.

Dovediți-o cu toți clienții online

O singură conexiune reușită nu dovedește nimic, pentru că simptomul original apărea doar când se schimba ordinea. Porniți fiecare client dorit, variați ordinea de pornire și repetați după o reconectare. Apoi reporniți gazda care obișnuia să piardă cursa și confirmați că adresa supraviețuiește.

Pentru confirmare directă, testați dacă există un proprietar duplicat înainte de a atribui adresa și urmăriți tabelul de vecini după aceea. Dacă nimic nu răspunde la test și adresa rămâne deținută în mod unic pe parcursul unui ciclu complet de repornire, conflictul este rezolvat, nu doar ascuns. Comenzile de mai jos efectuează ambele verificări pe dispozitivul de pod. RFC 5227 descrie comportamentul de testare și anunțare pe care îl exercită aceste instrumente, și este referința de citat atunci când cineva propune să dezactiveze detectarea.

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

Un test fără răspuns este rezultatul așteptat pe un segment curat. Un test care atrage un răspuns vă dă adresa de hardware a proprietarului rămas, aceeași dovadă pe care evenimentul Windows v-a dat-o la început. Păstrați acea ieșire împreună cu registrul modificărilor, pentru că este singura dovadă că adresa este deținută în mod unic.