Два ўладальнікі, адзін адрас: дублікаты IP на мосце TAP

Адзін кліент Windows трымае 10.8.0.2 і працуе, пакуль не зменіцца парадак запуску; тады той жа адрас паведамляецца як канфлікт, хоць у кліенце нічога не змянілася. Другі хост у тым жа аб'яднаным сегменце прэтэндуе на тое ж значэнне, і машына, якая скончыць наладку апошняй, звычайна прайграе. Абодва ўпэўненыя, што валодаюць ім, і той, хто прайграў, ціха перастае карыстацца адрасам, які яму загадалі выкарыстоўваць. Менавіта стаўленне да гэтага як да праблемы часу і робіць так, што яно вяртаецца пры кожнай перазагрузцы.

Прачытайце доказы канфлікту, перш чым чапаць мост

Windows паведамляе пра канфлікт адраса разам з апаратным адрасам іншага прэтэндэнта. Менавіта гэты апаратны адрас і ёсць карысным фактам, бо ён адпавядае аднаму інтэрфейсу на адным хосце, а паказанае імя падзеі нічога не кажа пра тое, дзе жыве дублікат. Запішыце апаратны адрас, перш чым нешта змяняць.

Выяўленне дублікатаў на аснове ARP правярае канкурэнтных уладальнікаў да выкарыстання адраса і працягвае назіраць пасля. Таму хост, якога не было падчас наладкі сеткі, можа выклікаць канфлікт і праз гадзіну. Праверка не з'яўляецца аднаразовай дзеяй пры загрузцы. Машына, якая з'явіцца пазней, можа заняць адрас, які спакойна выкарыстоўваўся ўвесь дзень, і менавіта таму збой выглядае як гонка, а не як памылка канфігурацыі.

Падзея канфлікту сама па сабе не кажа, якая канфігурацыя стварыла другую прэтэнзію, а эксперыментальнае ачышчэнне адрасоў знішчае супастаўленне, якое магло б вам сказаць. Сэнс доказаў у тым, каб ператварыць апаратны адрас у інтэрфейс, які можна агледзець. Пошук у інвентары па імені машыны звычайна вядзе не да таго хоста.

Пералічыце ўсе прэтэнзіі ў сегменце

Аб'яднаная ўстаноўка TAP злучае сегменты Ethernet, якія раней былі асобнымі, таму адрасы, унікальныя ўнутры сваіх сетак, могуць сутыкнуцца, калі кадры пачынаюць дзяліць адно звяно. Таму гэты клас збояў існуе на VPN і не існуе ў маршрутызаваных сетках, якія ён замяніў. Пералічыце кожнага магчымага ўладальніка, а не першага, каго падазраяце.

Прайдзіце спіс у такім парадку: адрасы на кожнай прыладзе моста і яго партах-удзельніках, пул OpenVPN і любое фіксаванае прызначэнне для кліента, а таксама любы сервер DHCP, які абслугоўвае аб'яднаны сегмент. Затым супастаўце апаратны адрас са справаздачы пра канфлікт з знойдзенымі інтэрфейсамі.

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

Пул і дыяпазон DHCP — гэта два ўладальнікі, пра якіх забываюць. Выведзіце абодва дыяпазоны разам і пашукайце перасячэнне, перш чым рабіць што-небудзь яшчэ. Адрас моста, прызначаны ўручную, і пул, які выдае тое ж значэнне, рана ці позна сутыкнуцца, і сутыкненне выглядае выпадковым, пакуль абодва дыяпазоны не выведзены побач.

Нумаруйце масты толькі там, дзе ім патрэбная ідэнтычнасць

У звычайным мосце хосце прылада моста нясе канфігурацыю трэцяга ўзроўню хосце, а ўдзельнікі Ethernet і TAP выступаюць як парты. Калі даць кожнаму ўдзельніку свой адрас або скапіяваць адзін скрыпт наладкі на некалькі машын, не змяніўшы адрас, адзін сегмент і атрымлівае трох уладальнікаў аднаго значэння. Удзельнікам не патрэбныя ўласныя ідэнтычнасці, каб перадаваць кадры. Ім патрэбна роўна адна ідэнтычнасць на кожны хост, які павінен быць дасяжным у гэтым сегменце.

Мост, які толькі камутуе кадры, зусім не патрабуе адраса ў гэтым сегменце. Калі пакінуць яго без нумара, знікае цэлы клас сутыкненняў — пры ўмове, што ў хосце ўсё яшчэ ёсць правераны шлях кіравання. Спачатку пацвердзіце доступ, потым выдаліце адрас, а трэцяй справай праверце дасяжнасць.

Калі адрас, які вы збіраецеся выдаліць, — адзіны шлях у машыну, то выдаленне яго як эксперыменту — гэта самастойна створаны збой, а не дыягностыка. Праверце пазапалосны шлях, перш чым нешта тэставаць.

Зрабіце выпраўленне ўстойлівым да перазагрузкі

Змена жывога інтэрфейса выпраўляе бягучую загрузку і больш нічога. Усё, што стварае адрас пры запуску, верне канфлікт пры наступнай перазагрузцы, і вы зробіце выснову, што выпраўленне не спрацавала, хоць насамрэч яно ніколі не было пастаянным. Запішыце, які файл вы змянілі, каб наступная перазагрузка пацвердзіла рашэнне, а не выявіла сюрпрыз.

Знайдзіце ўладальніка гэтай канфігурацыі: профіль сеткавага кіраўніка, файл для інтэрфейса, вызначэнне кантэйнера або ВМ, ці фрагмент cloud-init. Змяніце яго там, затым свядома перазагрузіце адзін закрануты хост, каб пацвердзіць, што вяртаецца новае значэнне. Перазагрузка — адзіны тэст, які даказвае пастаянства.

Зарэзервуйце адрасы моста ўнутры дыяпазону DHCP як выключэнні або перанясіце іх за яго межы. Рэзерваванне, якое існуе толькі ў табліцы, не з'яўляецца выключэннем, і размеркавальнік яго не прачытае.

Дакажыце гэта пры ўсіх кліентах онлайн

Адно паспяховае падключэнне нічога не даказвае, бо першапачатковы сімптом з'яўляўся толькі пры змене парадку. Падніміце ўсіх патрэбных кліентаў, змяніце парадак запуску і паўтарыце пасля перападключэння. Затым перазагрузіце хост, які раней прайграваў гонку, і пацвердзіце, што адрас выжыў.

Для прамой праверкі праверце наяўнасць дублюючага ўладальніка перад прызначэннем адраса і пасля гэтага назірайце за табліцай суседзяў. Калі нішто не адказвае на праверку і адрас застаецца ўнікальным на працягу поўнага цыкла перазагрузкі, канфлікт вырашаны, а не проста схаваны. Каманды ніжэй выконваюць абедзве праверкі на прыладзе моста. RFC 5227 апісвае паводзіны праверкі і аб'явы, якія выконваюць гэтыя сродкі, і гэта крыніца, на якую спасылаюцца, калі хтосьці прапануе адключыць выяўленне замест гэтага.

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

Праверка, якая не атрымала адказу, — чаканы вынік у чыстым сегменце. Праверка, якая выклікала адказ, дае вам апаратны адрас пакінутага ўладальніка — тыя ж доказы, што падзея Windows дала напачатку. Захоўвайце гэты вывад разам з запісам змен, бо гэта адзіны доказ таго, што адрас унікальна ўтрымліваецца.