Dva lastnika, en naslov: podvojeni IP na mostu TAP

En odjemalec Windows drži 10.8.0.2 in deluje, dokler se ne spremeni vrstni red zagona; takrat je isti naslov prijavljen kot spor, čeprav se na odjemalcu ni nič spremenilo. Drugi gostitelj v istem mostovnem segmentu zahteva isto vrednost, in stroj, ki konfiguracijo konča zadnji, običajno izgubi. Oba verjameta, da je naslov njun, in poraženec tiho preneha uporabljati naslov, ki mu je bilo rečeno, naj ga uporablja. Prav obravnavanje tega kot časovne težave povzroča, da se ponovi ob vsakem ponovnem zagonu.

Preberite dokaze o sporu, preden se dotaknete mosta

Windows sporoči spor naslova skupaj z naslovom strojne opreme drugega zahtevatelja. Prav ta naslov strojne opreme je koristen podatek, ker kaže na en vmesnik na enem gostitelju, medtem ko prikazano ime dogodka ne pove ničesar o tem, kje je dvojnik. Zapišite naslov strojne opreme, preden karkoli spremenite.

Zaznavanje dvojnikov na podlagi ARP pred uporabo naslova preveri konkurenčne lastnike in po tem še naprej opazuje. Zato lahko gostitelj, ki ga med konfiguriranjem omrežja ni bilo, povzroči spor tudi uro kasneje. Preverjanje ni enkraten pregled ob zagonu. Stroj, ki se pojavi pozneje, lahko zavzame naslov, ki je bil ves dan v mirni uporabi, in zato se napaka bere kot tekma in ne kot konfiguracijska napaka.

Dogodek spora sam po sebi ne pove, katera konfiguracija je ustvarila drugo zahtevo, in eksperimentalno brisanje naslovov uniči preslikavo, ki bi vam to povedala. Smisel dokaza je spremeniti naslov strojne opreme v vmesnik, ki ga lahko pregledate. Iskanje v inventarju po imenu stroja vas običajno pošlje k napačnemu gostitelju.

Popišite vsako zahtevo v segmentu

Mostovna nastavitev TAP poveže segmente Ethernet, ki so bili prej ločeni, zato lahko naslovi, ki so bili edinstveni znotraj svojih omrežij, trčijo, ko si okviri delijo eno povezavo. Zato ta razred napak obstaja v VPN in ne obstaja v usmerjenih omrežjih, ki jih je nadomestil. Naštejte vsakega možnega lastnika, ne prvega, ki ga sumite.

Pojdite skozi seznam v tem vrstnem redu: naslovi na vsaki mostovni napravi in njenih članskih vratih, OpenVPN in vsaka fiksna dodelitev za odjemalca ter vsak strežnik DHCP, ki pokriva mostovni segment. Nato primerjajte naslov strojne opreme iz poročila o sporu z vmesniki, ki ste jih našli.

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

Pool in obseg DHCP sta dva lastnika, ki ju ljudje pozabijo. Natisnite oba obsega skupaj in pred čimer koli drugim poiščite prekrivanje. Ročno dodeljen naslov mostu in pool, ki izdaja isto vrednost, se bosta prej ali slej zaletela, in trčenje se zdi naključno, dokler oba obsega nista natisnjena drug ob drugem.

Oštevilčite mostove le tam, kjer potrebujejo identiteto

V običajnem gostiteljskem mostu mostovna naprava nosi konfiguracijo tretje plasti gostitelja, člani Ethernet in TAP pa delujejo kot vrata. Dajanje vsakemu članu lastnega naslova ali kopiranje ene namestitvene skripte na več strojev brez spremembe naslova je način, kako en segment dobi tri lastnike iste vrednosti. Člani ne potrebujejo lastnih identitet za posredovanje okvirov. Potrebujejo natanko eno identiteto na gostitelja, ki mora biti dosegljiv v tem segmentu.

Most, ki samo preklaplja okvire, v tem segmentu sploh ne potrebuje naslova. Če ga pustite brez številke, odstranite cel razred trčenj, pod pogojem, da ima gostitelj še vedno preverjeno pot upravljanja. Najprej potrdite dostop, drugo odstranite naslov in tretje preverite dosegljivost.

Če je naslov, ki ga boste izbrisali, edina pot v stroj, je brisanje kot poskus samo povzročena prekinitev in ne diagnoza. Preden karkoli preizkusite, preverite zunajpasovno pot.

Poskrbite, da bo popravek preživel ponovni zagon

Sprememba delujočega vmesnika popravi trenutni zagon in nič drugega. Karkoli naslov ob zagonu znova ustvari, bo obnovilo spor ob naslednjem ponovnem zagonu, in sklepali boste, da popravek ni deloval, čeprav v resnici nikoli ni bil trajen. Zapišite, katero datoteko ste spremenili, da bo naslednji ponovni zagon potrdil odločitev, namesto da bi razkril presenečenje.

Poiščite lastnika te konfiguracije: profil upravitelja omrežja, datoteko na vmesnik, definicijo vsebnika ali VM, ali fragment cloud-init. Spremenite jo tam in nato namerno znova zaženite enega prizadetega gostitelja, da potrdite, da se vrača nova vrednost. Ponovni zagon je edini test, ki dokazuje trajnost.

Rezervirajte naslove mostu znotraj obsega DHCP kot izjeme ali jih premaknite izven njega. Rezervacija, ki obstaja samo v preglednici, ni izjema in dodeljevalnik je ne bo prebral.

Dokažite to z vsemi odjemalci na spletu

Ena uspešna povezava ne dokaže ničesar, ker se je prvotni simptom pojavil le ob spremembi vrstnega reda. Zaženite vsakega predvidenega odjemalca, spreminjajte vrstni red zagona in ponovite po ponovni povezavi. Nato znova zaženite gostitelja, ki je prej izgubljal tekmo, in potrdite, da naslov preživi.

Za neposredno potrditev pred dodelitvijo naslova preverite, ali obstaja podvojen lastnik, in nato opazujte tabelo sosedov. Če se nič ne odzove na preverjanje in naslov ostane edinstveno v lasti skozi celoten cikel ponovnega zagona, je spor rešen in ne le skrit. Spodnji ukazi izvedejo oba pregleda na mostovni napravi. RFC 5227 opisuje vedenje preverjanja in napovedi, ki ga izvajajo ta orodja, in je referenca, na katero se sklicujemo, ko nekdo predlaga, da bi zaznavanje raje izklopili.

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

Preverjanje brez odgovora je pričakovan rezultat v čistem segmentu. Preverjanje, ki izzove odgovor, vam da naslov strojne opreme preostalega lastnika, isti dokaz, ki vam ga je dogodek Windows dal na začetku. Shranite ta izpis skupaj z zapisom spremembe, ker je edini dokaz, da je naslov edinstveno zadržan.