Du posedantoj, unu adreso: duobligitaj IP-oj sur TAP-ponto

Unu Windows-kliento tenas 10.8.0.2 kaj funkcias ĝis la startordo ŝanĝiĝas; tiam la sama adreso estas raportata kiel konflikto dum nenio pri la kliento ŝanĝiĝis. Dua gastiganto sur la sama pontigita segmento postulas la saman valoron, kaj la maŝino, kiu finas la agordon lasta, kutime malgajnas. Ambaŭ kredas, ke ili posedas ĝin, kaj la malgajninto silente ĉesas uzi adreson, kiun oni diris al ĝi uzi. Ĝuste traktado de tio kiel tempigo-problemo kaŭzas, ke ĝi revenas ĉe ĉiu restartigo.

Legi la konfliktajn pruvojn antaŭ ol tuŝi ponton

Windows raportas adresan konflikton kune kun la aparata adreso de la alia postulanto. Tiu aparata adreso estas la utila fakto, ĉar ĝi mapas al unu interfaco sur unu gastiganto, dum la montrata nomo de la okazaĵo diras al vi nenion pri tio, kie loĝas la duoblaĵo. Notu la aparatan adreson antaŭ ol vi ŝanĝos ion ajn.

ARP-bazita duoblaĵa detektado esploras konkurantajn posedantojn antaŭ ol adreso uziĝas kaj plu observas poste. Tial gastiganto, kiu forestis dum vi agordis la reton, ankoraŭ povas kaŭzi konflikton horon poste. La esploro ne estas unufoja kontrolo ĉe starto. Maŝino, kiu aperas poste, povas preni adreson, kiu estis en trankvila uzo la tutan tagon, kaj tial la paneo aspektas kiel kurado anstataŭ agorda eraro.

Konflikta okazaĵo sola ne diras, kiu agordo kreis la alian postulon, kaj forigi adresojn eksperimente detruas la mapadon, kiu dirus al vi. La senco de la pruvo estas transformi aparatan adreson en interfacon, kiun vi povas ekzameni. Serĉado en la inventaro laŭ maŝinnomo kutime sendas vin al la malĝusta gastiganto.

Inventarigu ĉiun postulon sur la segmento

Pontigita TAP-agordo kunigas Ethernet-segmentojn, kiuj antaŭe estis apartaj, do adresoj unikaj ene de siaj propraj retoj povas kolizii, kiam kadroj dividas unu ligon. Tial ĉi tiu panea klaso ekzistas sur VPN kaj ne ekzistas sur la enkursigaj retoj, kiujn ĝi anstataŭis. Listigu ĉiun eblan posedanton anstataŭ la unuan, kiun vi suspektas.

Trairu la liston en ĉi tiu ordo: la adresoj sur ĉiu ponthava aparato kaj ĝiaj anaj havenoj, la OpenVPN provizo kaj ĉiu fiksa asigno por kliento, kaj ĉiu DHCP-servilo kovranta la pontigitan segmenton. Poste kongruigu la aparatan adreson el la konflikta raporto kun la interfacoj, kiujn vi trovis.

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

La provizo kaj la DHCP-gamo estas la du posedantoj, kiujn homoj forgesas. Presu ambaŭ gamojn kune kaj serĉu interkovron antaŭ ol fari ion alian. Mane asignita ponta adreso kaj provizo, kiu eldonas la saman valoron, kolizios fine, kaj la kolizio aspektas hazarda ĝis ambaŭ gamoj estos presitaj unu apud la alia.

Numeru pontojn nur tie, kie ili bezonas identecon

En normala gastiganta ponto la ponta aparato portas la agordon de la tria tavolo de la gastiganto, kaj la Ethernet- kaj TAP-anoj agas kiel havenoj. Doni al ĉiu ano propran adreson, aŭ kopii unu agordan skripton al pluraj maŝinoj sen ŝanĝi la adreson, estas la maniero, kiel unu segmento finas kun tri posedantoj de la sama valoro. La anoj ne bezonas proprajn identecojn por plusendi kadrojn. Ili bezonas precize unu identecon por gastiganto, kiu devas esti atingebla sur tiu segmento.

Ponto, kiu nur komutas kadrojn, tute ne bezonas adreson sur tiu segmento. Lasi ĝin sennombra forigas tutan klason de kolizio, kondiĉe ke la gastiganto ankoraŭ havas administran vojon, kiun vi kontrolis. Konfirmu aliron unue, forigu la adreson due, kaj kontrolu atingeblon trie.

Se la adreso, kiun vi baldaŭ forigos, estas la sola vojo en la maŝinon, forigi ĝin kiel eksperimenton estas memkaŭzita interrompo, ne diagnozo. Kontrolu la eksterkanalan vojon antaŭ ol testi ion ajn.

Igu la korekton postvivi restartigon

Ŝanĝi vivan interfacon riparas la nunan starton kaj nenion alian. Kio ajn rekreas la adreson ĉe starto, restarigos la konflikton ĉe la sekva restartigo, kaj vi konkludos, ke la korekto ne funkciis, kvankam fakte ĝi neniam estis daŭra. Notu, kiun dosieron vi ŝanĝis, por ke la sekva restartigo konfirmu decidon anstataŭ malkaŝi surprizon.

Trovu la posedanton de tiu agordo: retadministrila profilo, dosiero por interfaco, uja aŭ VM-difino, aŭ cloud-init-fragmento. Ŝanĝu ĝin tie, poste restartigu intence unu trafitan gastiganton por konfirmi, ke la nova valoro revenas. Restartigo estas la sola testo, kiu pruvas daŭrecon.

Rezervu la pontajn adresojn ene de la DHCP-gamo kiel ekskludojn, aŭ movu ilin ekster ĝin. Rezervo, kiu ekzistas nur en kalkultabelo, ne estas ekskludo, kaj la asignilo ne legos ĝin.

Pruvu ĝin kun ĉiu kliento enrete

Unu sukcesa konekto pruvas nenion, ĉar la origina simptomo aperis nur kiam la ordo ŝanĝiĝis. Ŝaltu ĉiun celitan klienton, variigu la startordon, kaj ripetu post rekonekto. Poste restartigu la gastiganton, kiu kutimis malgajni la kuradon, kaj konfirmu, ke la adreso postvivas.

Por rekta konfirmo, esploru ĉu ekzistas duobla posedanto antaŭ ol asigni la adreson, kaj poste observu la najbaran tabelon. Se nenio respondas al la esploro kaj la adreso restas unike posedata dum plena restartiga ciklo, la konflikto estas solvita kaj ne simple kaŝita. La subaj komandoj plenumas ambaŭ kontrolojn sur la ponta aparato. RFC 5227 priskribas la esploran kaj anoncan konduton, kiun ĉi tiuj iloj praktikas, kaj ĝi estas la referenco citenda, kiam iu proponas male malŝalti detektadon.

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

Esploro sen respondo estas la atendata rezulto sur pura segmento. Esploro, kiu eltiras respondon, donas al vi la aparatan adreson de la restanta posedanto, la saman pruvon, kiun la Windows-okazaĵo donis al vi komence. Konservu tiun eligon kun la ŝanĝa registro, ĉar ĝi estas la sola pruvo, ke la adreso estas unike tenata.