Конфликт 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 запросе обоими узлами будет генерироваться ошибка о конфликтных адресах.