Назад | Перейти на главную страницу

Как предотвратить «кражу» IP-адреса нашего собственного сервера другим сервером в подсети при его перезапуске?

Мы арендуем корневой сервер Windows в Serverloft. Недавно, когда сервер перезагружался после установки регулярных обновлений Microsoft, он перезапускался правильно, но к нему больше не было доступа, и вместо этого отвечал сервер Linux!

Убедив горячую линию в том, что это не наша ошибка (на что потребовалось время), они обнаружили, что какой-то другой сервер в той же подсети каким-то образом (они не объяснили, как) «украл» публичный IP-адрес нашего сервера (или, скорее, " имел приоритет ").

Они отключили «вора», и на короткое время мы снова увидели наш сервер. Потом без перезагрузки повторилось! Примерно через час наш сервер вернулся.

Вопрос: есть ли в этом смысл (мы простые разработчики, которые толком ничего не знают)? И можно ли предотвратить такой сценарий? Или может кто-нибудь в типичной среде хостинга просто «украсть» другой IP-адрес, если он / она знает, как это сделать?

Статические записи ARP в кэше ARP коммутаторов могут помочь

Спросите у Serverloft, как настроены их переключатели, и запланировано ли что-то подобное.

редактировать:

Статические записи arp в коммутаторах не помешают кому-либо «украсть» IP-адрес, если это необходимо (поскольку MAC-адрес может быть изменен), но это предотвратит случайное появление.

Другое решение, которое я вижу для предотвращения кражи IP-адресов, - это реализация 802.1x на коммутаторах, например, с Wi-Fi.

802.1x на коммутаторе - это проверка подлинности на основе портов. В Википедии есть хорошая статья описание того, как хост общается с коммутатором, используя EAP, и коммутатор обращается к Radius-серверу.

На сервере RADIUS можно установить атрибуты для хоста и установить IP-адрес клиента в таблице MAC-адресов коммутатора после аутентификации (например, как у RADIUS с сервером LNS).

Невозможно предотвратить конфликты IP-адресов на сервере. Я подозреваю, что вы работаете у провайдера, который разрешает root или доступ администратора к серверам (тот или другой управляемый провайдер). Один раз - ошибка, дважды - недопустимо. У провайдера, который выполняет базовую конфигурацию за вас и управляет серверами за вас, этого не происходит. Я бы предложил сменить провайдера. Мое личное предложение orcsweb. Наиболее вероятная причина, по которой это происходит, заключается в том, что Linux не отвечает и не генерирует беспричинные запросы ARP, чтобы предотвратить конфликты IP.

Я что-то упустил? Или все упускают из виду тот факт, что кажется, что вы назначаете серверам динамические адреса (с DHCP)?

Как правило, серверам должны быть назначены статические адреса, чтобы не возникало подобных ситуаций.
Это также помогает гарантировать, что сервер не получит новый адрес при перезапуске, что, по-видимому, приведет к исчезновению сервера.

Вы ничего не можете сделать, чтобы помешать системному администратору назначить системе статический IP-адрес, который может конфликтовать с вашим собственным. И если эта машина окажется в том же vlan, что и ваш собственный ящик, тогда они вступят в конфликт (просто спросите сетевого специалиста, у которого пользователь назначил своей машине тот же IP-адрес, что и маршрутизатор, насколько это весело).

Это похоже на ошибку пользователя со стороны другого системного администратора. Если вы используете динамические назначения (DHCP), постоянная аренда или резервирование могут снизить вероятность этого. Ваш хостинг-провайдер также может реализовать меньшие подсети или частные vlan, чтобы снизить вероятность этого.

Краткий ответ: Измените MAC-адрес аппарата.

Возможное объяснение:

Один из возможных сценариев - это когда машины являются «виртуальными машинами» под управлением VMware или Hyper-V. Обычно люди создают эталонную машину и клонируют ее по запросу. Таким образом, обычно все настройки оборудования также копируются на «клонированную» машину.

Если мы перейдем к основам, IP назначается сетевому адаптеру, а DHCP-сервер назначает IP-адреса сетевым адаптерам .. и сетевые адаптеры идентифицируются по их MAC-адресам.