Windows bezero batek 10.8.0.2 eusten dio eta abio-ordena aldatu arte funtzionatzen du; orduan helbide bera gatazka gisa jakinarazten da, bezeroan ezer aldatu ez bada ere. Segmentu zubidun berean dagoen bigarren ostalari batek balio bera eskatzen du, eta konfigurazioa azkenetan amaitzen duen makinak galdu ohi du. Biek uste dute berena dela, eta galtzaileak isilka uzten dio erabiltzeko esan zioten helbidea erabiltzeari. Hori denborazko arazo gisa hartzea da berrabiarazte bakoitzean errepikatzea eragiten duena.

Irakurri gatazkaren frogak zubia ukitu aurretik

Windowsek helbide-gatazka bat jakinarazten du beste eskatzailearen hardware helbidearekin batera. Hardware helbide hori da datu erabilgarria, ostalari bateko interfaze bakar bati dagokiolako, eta gertaeraren bistaratzeko izenak ez duelako ezer esaten bikoizketa non dagoen. Idatzi hardware helbidea ezer aldatu aurretik.

ARPn oinarritutako bikoizketen detekzioak lehian ari diren jabeak aztertzen ditu helbide bat erabili aurretik eta gero ere behatzen jarraitzen du. Horregatik sareak konfiguratzen ari zinen bitartean kanpoan zegoen ostalari batek ordu bat geroago gatazka sor dezake. Azterketa ez da abioan behin egiten den egiaztapena. Geroago agertzen den makina batek egun osoan lasai erabili den helbide bat har dezake, eta horregatik hutsak lasterketa dirudi konfigurazio-erroreak baino.

Gatazka-gertaera batek bere horretan ez du esaten zein konfiguraziok sortu zuen beste eskaria, eta helbideak esperimentalki garbitzeak esango zizun mapaketa suntsitzen du. Frogaren helburua hardware helbide bat azter dezakezun interfaze bihurtzea da. Inbentarioan makinaren izenaren arabera bilatzeak ostalari okerrengana eramaten zaitu normalean.

Zerrendatu segmentuko eskari guztiak

TAP konfigurazio zubidun batek lehenago bereiziak ziren Ethernet segmentuak elkartzen ditu, beraz beren sareetan bakarrak ziren helbideak talka daitezke markoek esteka bat partekatzen dutenean. Horregatik akats mota hau VPN batean dago eta ordezkatu zituen sare bideratuetan ez dago. Zerrendatu balizko jabe guztiak, susmatzen duzun lehenengoa baino.

Igo zerrenda ordena honetan: zubi-gailu bakoitzeko eta haren ataka kideetako helbideak, OpenVPN multzoa eta bezero bakoitzeko esleipen finkoa, eta segmentu zubiduna estaltzen duen DHCP zerbitzari oro. Gero parekatu gatazka-txosteneko hardware helbidea aurkitu dituzun interfazeekin.

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

Multzoa eta DHCP tartea jendeak ahazten dituen bi jabeak dira. Inprimatu bi tarteak elkarrekin eta bilatu gainjartze bat beste ezer egin aurretik. Eskuz esleitutako zubi-helbide batek eta balio bera banatzen duen multzo batek talka egingo dute noizbait, eta talka ausazkoa dirudi bi tarteak alboan inprimatzen diren arte.

Zenbakitu zubiak identitatea behar duten tokietan soilik

Ostalari-zubi arrunt batean, zubi-gailuak ostalariaren hirugarren geruzako konfigurazioa eramaten du eta Ethernet eta TAP kideek ataka gisa jarduten dute. Kide bakoitzari bere helbidea ematea, edo konfigurazio-script bat makina batzuetara helbidea aldatu gabe kopiatzea, horrela lortzen du segmentu bakar batek balio beraren hiru jabe izatea. Kideek ez dute beren identitaterik behar markoak birbidaltzeko. Ostalari bakoitzeko identitate zehatz bat behar dute, segmentu horretan irisgarria izan behar duena.

Markoak soilik kommutatzen dituen zubi batek ez du helbiderik behar segmentu horretan. Zenbakirik gabe uzten baduzu, talka-mota oso bat kentzen duzu, baldin eta ostalariak egiaztatu duzun kudeaketa-bide bat oraindik badu. Egiaztatu sarbidea lehenengo, kendu helbidea bigarren eta egiaztatu irisgarritasuna hirugarren.

Ezabatzeko dagoen helbidea makinara sartzeko bide bakarra bada, esperimentu gisa ezabatzea zuk zeuk eragindako etena da, ez diagnostikoa. Egiaztatu banda kanpoko bidea ezer probatu aurretik.

Egin zuzenketa berrabiarazteari eusten diona

Interfaze bizia aldatzeak uneko abioa konpontzen du eta besterik ez. Abioan helbidea birsortzen duen edozein gauzak gatazka berrezarriko du hurrengo berrabiaraztean, eta zuzenketak ez zuela funtzionatu ondorioztatuko duzu, nahiz eta inoiz ez zen iraunkorra izan. Idatzi zein fitxategi aldatu duzun, hurrengo berrabiarazteak erabaki bat berretsi dezan ezusteko bat agertu beharrean.

Aurkitu konfigurazio horren jabea: sare-kudeatzailearen profila, interfaze bakoitzeko fitxategia, edukiontzi edo VM definizioa, edo cloud-init zati bat. Aldatu hura han, eta gero berrabiarazi nahita eragindako ostalari bat balio berria dela itzultzen dena berresteko. Berrabiaraztea iraunkortasuna frogatzen duen proba bakarra da.

Erreserbatu zubi-helbideak DHCP tartearen barruan bazterketa gisa, edo mugitu tarte horretatik kanpo. Kalkulu-orri batean soilik dagoen erreserba ez da bazterketa, eta esleitzaileak ez du irakurriko.

Frogatu bezero guztiak linean daudela

Konexio arrakastatsu batek ez du ezer frogatzen, hasierako sintoma ordena aldatu zenean soilik agertzen baitzen. Igo nahi den bezero guztiak, aldatu abio-ordena eta errepikatu berrikonektatu ondoren. Gero berrabiarazi lasterketa galtzen zuen ostalaria eta berretsi helbideak bizirik dirauela.

Zuzeneko berrespena lortzeko, aztertu jabe bikoiztua dagoen helbidea esleitu aurretik eta begiratu bizilagun-taulari gero. Ezerk azterketari erantzuten ez badio eta helbidea berrabiarazte-ziklo osoan zehar jabetza bakarra izaten jarraitzen badu, gatazka konponduta dago, ez soilik ezkutatuta. Beheko komandoek bi egiaztapenak egiten dituzte zubi-gailuan. RFC 5227 tresna hauek erabiltzen duten azterketa- eta iragarpen-jokabidea deskribatzen du, eta hura da aipatzeko erreferentzia norbaitek detekzioa desgaitzea proposatzen duenean.

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

Erantzunik jasotzen ez duen azterketa segmentu garbi batean espero den emaitza da. Erantzuna erakartzen duen azterketak gainerako jabearen hardware helbidea ematen dizu, hasieran Windows gertaerak eman zizun froga bera. Gorde irteera hori aldaketaren erregistroarekin, helbidea modu bakarrean eusten dela frogatzen duen ebidentzia bakarra delako.

Erlazionatutako artikuluak