Divi īpašnieki, viena adrese: dublētas IP uz TAP tilta

Viens Windows klients tur 10.8.0.2 un darbojas, līdz mainās startēšanas secība; tad tā pati adrese tiek ziņota kā konflikts, lai gan klientā nekas nav mainījies. Otrs resursdators tajā pašā tiltotajā segmentā pieprasa to pašu vērtību, un mašīna, kas konfigurāciju pabeidz pēdējā, parasti zaudē. Abi uzskata, ka tā pieder viņiem, un zaudētājs klusi pārstāj lietot adresi, kas tam tika likts lietot. Tieši šī uzskatīšana par laika problēmu ir iemesls, kāpēc tas atkārtojas katrā pārstartēšanā.

Izlasiet konflikta pierādījumus pirms tilta aizskāriena

Windows ziņo par adreses konfliktu kopā ar otra prasītāja aparatūras adresi. Tieši šī aparatūras adrese ir noderīgais fakts, jo tā atbilst vienai saskarnei vienā resursdatorā, bet notikuma rādītais nosaukums neko nepasaka par to, kur atrodas dublikāts. Pierakstiet aparatūras adresi pirms kaut kā maiņas.

ARP balstīta dublikātu noteikšana pārbauda konkurentus pirms adreses lietošanas un turpina novērot arī pēc tam. Tāpēc resursdators, kas nebija klāt, kamēr konfigurējāt tīklu, var izraisīt konfliktu arī stundu vēlāk. Pārbaude nav vienreizēja startēšanas pārbaude. Vēlāk parādījusies mašīna var paņemt adresi, kas visu dienu bijusi mierīgā lietošanā, un tāpēc kļūme izskatās pēc sacensībām, nevis konfigurācijas kļūdas.

Konflikta notikums pats par sevi nepasaka, kura konfigurācija radīja otru prasību, un adrešu eksperimentāla dzēšana iznīcina atbilstību, kas to būtu pateikusi. Pierādījuma mērķis ir pārvērst aparatūras adresi saskarnē, ko varat pārbaudīt. Inventāra meklēšana pēc mašīnas nosaukuma parasti aizved pie nepareizā resursdatora.

Uzskaitiet katru segmenta prasību

Tiltotais TAP iestatījums savieno Ethernet segmentus, kas agrāk bija atsevišķi, tāpēc adreses, kas bija unikālas savos tīklos, var sadurties, tiklīdz kadri dala vienu saiti. Tāpēc šī kļūmju klase pastāv VPN un nepastāv maršrutētajos tīklos, ko tā aizstāja. Uzskaitiet katru iespējamo īpašnieku, nevis pirmo, ko aizdomās turat.

Izejiet sarakstu šādā secībā: adreses katrā tilta ierīcē un tās dalības portos, OpenVPN pūls un jebkurš fiksēts piešķīrums klientam, kā arī jebkurš DHCP serveris, kas aptver tiltoto segmentu. Pēc tam salīdziniet konflikta pārskata aparatūras adresi ar atrastajām saskarnēm.

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

Pūls un DHCP diapazons ir divi īpašnieki, ko cilvēki aizmirst. Izdrukājiet abus diapazonus kopā un pirms kaut kā cita meklējiet pārklāšanos. Ar roku piešķirta tilta adrese un pūls, kas izsniedz to pašu vērtību, agrāk vai vēlāk sadursies, un sadursme izskatās nejauša, līdz abi diapazoni tiek izdrukāti blakus.

Numurējiet tiltus tikai tur, kur tiem vajadzīga identitāte

Parastā resursdatora tiltā tilta ierīce nes resursdatora trešā slāņa konfigurāciju, un Ethernet un TAP dalībnieki darbojas kā porti. Katram dalībniekam piešķirt savu adresi vai kopēt vienu iestatīšanas skriptu uz vairākām mašīnām, nemainot adresi, ir veids, kā viens segments iegūst trīs vienas vērtības īpašniekus. Dalībniekiem nav vajadzīgas savas identitātes, lai pārsūtītu kadrus. Viņiem vajadzīga tieši viena identitāte uz katru resursdatoru, kam jābūt sasniedzamam šajā segmentā.

Tiltam, kas tikai pārslēdz kadrus, šajā segmentā adrese vispār nav vajadzīga. Atstājot to bez numura, tiek novērsta vesela sadursmju klase, ar nosacījumu, ka resursdatoram joprojām ir jūsu pārbaudīts pārvaldības ceļš. Vispirms apstipriniet piekļuvi, otrais noņemiet adresi, trešais pārbaudiet sasniedzamību.

Ja adrese, ko gatavojaties dzēst, ir vienīgais ceļš uz mašīnu, tās dzēšana kā eksperiments ir paša radīts pārtraukums, nevis diagnostika. Pirms kaut kā testēšanas pārbaudiet ārpusjoslas ceļu.

Padariet labojumu noturīgu pret pārstartēšanu

Darbojošās saskarnes maiņa izlabo pašreizējo startēšanu un neko citu. Lai kas arī startēšanas laikā atjaunotu adresi, tas atjaunos konfliktu nākamajā pārstartēšanā, un jūs secināsiet, ka labojums nedarbojās, lai gan patiesībā tas nekad nebija pastāvīgs. Pierakstiet, kuru failu mainījāt, lai nākamā pārstartēšana apstiprinātu lēmumu, nevis atklātu pārsteigumu.

Atrodiet tās konfigurācijas īpašnieku: tīkla pārvaldnieka profils, fails katrai saskarnei, konteinera vai VM definīcija vai cloud-init fragments. Mainiet to tur, pēc tam apzināti pārstartējiet vienu skarto resursdatoru, lai apstiprinātu, ka atgriežas jaunā vērtība. Pārstartēšana ir vienīgais tests, kas pierāda noturību.

Rezervējiet tilta adreses DHCP diapazonā kā izņēmumus vai pārvietojiet tās ārpus tā. Rezervācija, kas pastāv tikai izklājlapā, nav izņēmums, un sadalītājs to nelasīs.

Pierādiet to, kad visi klienti ir tiešsaistē

Viens veiksmīgs savienojums neko nepierāda, jo sākotnējā pazīme parādījās tikai tad, kad mainījās secība. Palaidiet katru paredzēto klientu, mainiet startēšanas secību un atkārtojiet pēc atkārtotas pievienošanās. Pēc tam pārstartējiet resursdatoru, kas agrāk zaudēja sacensībās, un apstipriniet, ka adrese izdzīvo.

Tiešai apstiprināšanai pirms adreses piešķiršanas pārbaudiet, vai nav dublēta īpašnieka, un pēc tam novērojiet kaimiņu tabulu. Ja nekas neatbild uz pārbaudi un adrese paliek unikāli turēta visā pārstartēšanas ciklā, konflikts ir atrisināts, nevis tikai paslēpts. Tālāk dotās komandas veic abas pārbaudes uz tilta ierīces. RFC 5227 apraksta pārbaudes un paziņošanas uzvedību, ko īsteno šie rīki, un tas ir avots, uz ko atsaukties, kad kāds ierosina izslēgt noteikšanu.

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

Pārbaude, kas nesaņem atbildi, ir gaidītais rezultāts tīrā segmentā. Pārbaude, kas izraisa atbildi, dod jums atlikušā īpašnieka aparatūras adresi, to pašu pierādījumu, ko Windows notikums deva sākumā. Saglabājiet šo izvadi kopā ar izmaiņu ierakstu, jo tas ir vienīgais pierādījums, ka adrese tiek turēta unikāli.