Канфлікт IP адрасы ў сеткі: выяўленне і дазвол

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

Канфлікт IP адрасы ў сеткі і сеткавыя пратаколы

Адзінай рэччу, якая адказвае за кантроль дублявання сеткавых адрасоў, з'яўляецца пратакол пераўтварэнні адрасоў ARP. Можна прадставіць у пэўнай форме ўсё гэта ўзаемадзеянне. Пры атрыманні новага адрасы IP вузел А адпраўляе адмысловы броакдаст добраахвотны запыт у фармаце ARP. Важна разумець, што на ўвесь гэты працэс не аказвае ніякага ўплыву IP адрас DNS сервера. Запыт з'яўляецца спецыяльнай формай перадачы інфармацыі, у якой поля SPA і TRA ўтрымліваюць ўласныя адрасы. Калі на гэты запыт быў атрыманы адказ, то гэта і ўяўляе сабой канфлікт IP адрасы ў сеткі. Калі адказу няма, значыць, і дублёраў адрасу таксама няма, і ён з'яўляецца ў сетцы унікальным. Нашмат цікавей сітуацыя, калі прыходзіць адказ, што ж у такім выпадку адбываецца ў сеткі?

Вузел, які адпраўляе запыт у сетку, набывае статус так званага атакавалага вузла, а той, які даў адказ на запыт, атрымлівае статус атакаванага вузла. Што ж адбываецца з кожным з іх у працэсе выяўлення дадзенага канфлікту?

Разгледзім атакуючы вузел. Калі ў яго не быў усталяваны дынамічны IP адрас, а налада вырабляецца ўручную, то пасля атрымання адказу скідаецца ініцыялізацыя адрасы, то ёсць вузел не можа прысвоіць канфліктах адрас інтэрфейсу. Запіс аб гэтым будзе ўнесена ў сістэмны часопіс, а на экране высвяціцца памылка. Калі налада адрасы вырабляецца праз DHCP, то кліентам будуць правераны на канфлікт той адрас, які быў атрыманы ім ад DHCP-сервера ў спецыяльным пакеце DHCPOFFER. У тым выпадку, калі апынецца, што адрас з DHCPOFFER дублюючы, то пасля атрымання кліентам адказу на запыт будзе адпраўлены адмысловы пакет DHCPDECLINE DHCP-сервера. У залежнасці ад рэалізацыі сэрвісу дадзены адрас будзе пазначаны як няспраўны, пасля чаго ён павінен быць выдалены з спісу свабодных адрасоў. Пасля гэтага кліентам будуць прадпрымацца новыя спробы атрымаць ip адрас ад сервера, адпраўляючы пакеты DHCPDISCOVER.

Цяпер можна разгледзець канфлікт IP адрасы ў сетцы з боку атакаванага вузла. Ім канфлікт вызначаецца вельмі проста, калі поле SPA, то вузлом канстатуецца канфлікт. Дадзены факт таксама рэгіструецца ў спецыяльным часопісе падзей, а карыстальнік атрымлівае апавяшчэнне пра памылку. Пры гэтым з атакаванага вузла не здымаецца ip адрас, які стаў прычынай канфлікту. Пасля канстатацыі канфлікту да працы прыступае механізм дазволу склаўся канфлікту. Сутнасць праблемы ў дадзеным выпадку складаецца ў наступным: пасля адпраўкі аднаго добраахвотнага запыту адбываецца адпраўка запытаў усімі кліентамі сегмента па пэўнай схеме. Вынікам з'яўляецца атрыманне карціны з паслядоўнага абмену тройкай кадраў.

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