Dalawang May-ari, Isang Address: Doble ang IP sa TAP Bridge

Isang Windows client ang humahawak ng 10.8.0.2 at gumagana hanggang magbago ang pagkakasunod-sunod ng boot; pagkatapos ay ang parehong address ay iniulat bilang salungatan habang wala namang nagbago sa client. Ang ikalawang host sa parehong naka-bridge na segment ay nag-aangkin ng parehong halaga, at ang makina na huling natapos ang configuration ang kadalasang natatalo. Pareho nilang iniisip na kanila ito, at ang natatalo ay tahimik na humihinto sa paggamit ng address na sinabihan siyang gamitin. Ang pagtingin dito bilang problema sa oras ang dahilan kung bakit bumabalik ito sa bawat reboot.

Basahin ang ebidensya ng salungatan bago hawakan ang isang bridge

Iniuulat ng Windows ang salungatan ng address kasama ang hardware address ng kabilang nag-aangkin. Ang hardware address na iyon ang kapaki-pakinabang na katotohanan, dahil tumutugma ito sa isang interface sa isang host, samantalang ang ipinapakitang pangalan ng event ay walang sinasabi tungkol sa kung saan naroon ang duplikado. Isulat ang hardware address bago magbago ng anuman.

Ang pagtuklas ng duplikado batay sa ARP ay nagsisiyasat ng mga karibal na may-ari bago gamitin ang isang address at patuloy na nagmamasid pagkatapos. Iyon ang dahilan kung bakit ang isang host na wala noong kinokonpigura mo ang network ay maaari pa ring magdulot ng salungatan makalipas ang isang oras. Ang pagsisiyasat ay hindi isang beses na pagsusuri sa boot. Ang isang makina na lumilitaw mamaya ay maaaring kumuha ng address na tahimik na ginagamit buong araw, at iyon ang dahilan kung bakit ang pagkabigo ay binabasa bilang karera at hindi bilang error sa configuration.

Ang isang event ng salungatan lamang ay hindi nagsasabi kung aling configuration ang gumawa ng kabilang pag-aangkin, at ang pagbura ng mga address sa paraang eksperimental ay sumisira sa pagmamapa na sana ay nagsabi sa iyo. Ang layunin ng ebidensya ay gawing interface ang isang hardware address na maaari mong suriin. Ang paghahanap sa imbentaryo sa pangalan ng makina ay kadalasang nagdadala sa iyo sa maling host.

Iimbentaryo ang bawat pag-aangkin sa segment

Ang naka-bridge na TAP setup ay nag-uugnay ng mga segment ng Ethernet na dating hiwalay, kaya ang mga address na natatangi sa loob ng kanilang sariling mga network ay maaaring magbanggaan kapag ang mga frame ay nagbabahagi ng isang link. Iyon ang dahilan kung bakit may ganitong klase ng pagkabigo sa isang VPN at wala sa mga naka-ruta na network na pinalitan nito. Ilista ang bawat posibleng may-ari sa halip na ang unang pinaghihinalaan mo.

Daanan ang listahan sa ganitong pagkakasunod-sunod: ang mga address sa bawat bridge device at sa mga member port nito, ang OpenVPN at anumang fixed na paglalaan kada client, at anumang DHCP server na sumasaklaw sa naka-bridge na segment. Pagkatapos ay itugma ang hardware address mula sa ulat ng salungatan sa mga interface na natagpuan mo.

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

Ang pool at ang DHCP range ang dalawang may-ari na nakakalimutan ng mga tao. I-print ang dalawang range nang magkasama at maghanap ng overlap bago gawin ang anupaman. Ang address ng bridge na itinalaga sa kamay at isang pool na naglalabas ng parehong halaga ay magbabangga sa kalaunan, at ang banggaan ay mukhang random hanggang sa mai-print ang dalawang range nang magkatabi.

Bigyan ng numero ang mga bridge lamang kung saan kailangan nila ng pagkakakilanlan

Sa isang normal na host bridge, ang bridge device ang may configuration ng ikatlong layer ng host at ang mga miyembro ng Ethernet at TAP ay gumaganap bilang mga port. Ang pagbibigay sa bawat miyembro ng sarili nitong address, o ang pagkopya ng isang setup script sa maraming makina nang hindi binabago ang address, ay ang paraan kung paano nagtatapos ang isang segment na may tatlong may-ari ng parehong halaga. Hindi kailangan ng mga miyembro ng sariling pagkakakilanlan upang ipasa ang mga frame. Kailangan nila ng eksaktong isang pagkakakilanlan kada host na dapat maabot sa segment na iyon.

Ang bridge na nag-switch lamang ng mga frame ay hindi nangangailangan ng address sa segment na iyon. Ang pag-iwan dito na walang numero ay nag-aalis ng isang buong klase ng banggaan, sa kondisyon na may natitirang landas ng pamamahala ang host na na-verify mo. Kumpirmahin muna ang access, alisin ang address bilang pangalawa, at suriin ang maabot bilang pangatlo.

Kung ang address na buburahin mo ay ang tanging daan papasok sa makina, ang pagbura nito bilang eksperimento ay isang pagkagambala na ikaw mismo ang gumawa at hindi isang diagnosis. I-verify ang landas sa labas ng banda bago subukan ang anuman.

Gawing nakakaligtas sa reboot ang pagwawasto

Ang pagbabago ng isang live na interface ay nag-aayos lamang ng kasalukuyang boot at wala nang iba. Anuman ang muling gumagawa ng address sa boot ay magbabalik ng salungatan sa susunod na reboot, at maghihinuha ka na hindi gumana ang pagwawasto gayong sa katunayan ay hindi ito kailanman naging permanente. Itala kung aling file ang binago mo, upang ang susunod na reboot ay magkumpirma ng desisyon sa halip na magbunyag ng sorpresa.

Hanapin ang may-ari ng configuration na iyon: isang profile ng tagapamahala ng network, isang file kada interface, isang depinisyon ng container o VM, o isang fragment ng cloud-init. Baguhin ito doon, pagkatapos ay sadyang i-reboot ang isang apektadong host upang kumpirmahin na ang bagong halaga ang bumabalik. Ang reboot ang tanging pagsubok na nagpapatunay ng pagiging permanente.

Ireserba ang mga address ng bridge sa loob ng DHCP range bilang mga pagbubukod, o ilipat ang mga ito sa labas. Ang reserbasyon na umiiral lamang sa isang spreadsheet ay hindi pagbubukod, at hindi ito babasahin ng tagapaglalaan.

Patunayan ito habang online ang lahat ng client

Ang isang matagumpay na koneksyon ay walang pinapatunayan, dahil ang orihinal na sintomas ay lumitaw lamang kapag nagbago ang pagkakasunod-sunod. Ilunsad ang bawat inaasahang client, ibahin ang pagkakasunod-sunod ng boot, at ulitin pagkatapos ng muling pagkonekta. Pagkatapos ay i-restart ang host na dating natatalo sa karera at kumpirmahin na nabubuhay ang address.

Para sa direktang kumpirmasyon, siyasatin kung may dobleng may-ari bago italaga ang address at pagkatapos ay bantayan ang talahanayan ng kapitbahay. Kung walang sumasagot sa pagsisiyasat at nananatiling kakaiba ang pagmamay-ari ng address sa buong ikot ng restart, nareresolba ang salungatan at hindi lamang nakatago. Isinasagawa ng mga utos sa ibaba ang dalawang pagsusuri sa bridge device. RFC 5227 inilalarawan ang pag-uugali ng pagsisiyasat at pagpapahayag na isinasagawa ng mga tool na ito, at iyon ang reperensyang dapat banggitin kapag may nagmumungkahi na patayin na lamang ang pagtuklas.

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

Ang pagsisiyasat na walang sagot ay ang inaasahang resulta sa isang malinis na segment. Ang pagsisiyasat na humihila ng sagot ay nagbibigay sa iyo ng hardware address ng natitirang may-ari, ang parehong ebidensya na ibinigay sa iyo ng event ng Windows sa simula. Itago ang output na iyon kasama ng talaan ng pagbabago, dahil iyon lamang ang patunay na ang address ay pinapanatiling kakaiba.