Как узнать, пытается ли кто-то использовать мой IP-адрес?
Я использую относительно недорогой хостинг для своего личного сервера, и иногда я получаю множество предупреждений о простоях. Это все с сегодняшнего дня.
Если бы мой хост («случайно») назначил мой IP-адрес кому-то другому, и этот сервер подключился бы и начал бороться с моим за контроль над IP-адресом, это выглядело бы так? Если нет, то я предполагаю, что у хоста проблемы с оборудованием или сетью, или, возможно, он имеет дело с какой-то DoS-атакой, верно? Конечно, их клиентский портал и веб-сайт компании тоже страдают от простоя; делая практически невозможным связаться с ними и спросить, что происходит.
В прошлом я иногда видел, что этот тип активности коррелирует с попыткой доступа к моему веб-сайту и просмотром веб-сайта по умолчанию с другого сервера (что имеет смысл, поскольку у них не было настроек хоста для моего домена).
Если не считать вручную все мои домены, чтобы увидеть, не вернется ли что-то неожиданное, могу ли я что-нибудь сделать, чтобы обнаружить, что кто-то еще пытается использовать мой IP-адрес?
If my host were to ("accidentally") assign my IP to someone else, and that server came online and started fighting with mine for control of the IP, would it look like this?
Сетевые устройства не «борются» за свой IP-адрес. Если вашему серверу был назначен статический IP-адрес, а другому серверу в той же физической сети был назначен тот же IP-адрес, тогда в сети возникнет конфликт IP-адресов, и трафик для этого IP-адреса будет идти на тот или иной сервер, в зависимости от того, какой сервер ответил на запрос ARP для этого IP-адреса, но серверы не будут «бороться» за IP-адрес. Ни один из серверов не может сказать другому серверу прекратить использование этого IP-адреса.
Если бы серверам был назначен их IP-адрес динамически (с помощью DHCP), тогда провайдер использовал бы статические резервирования в DHCP, чтобы гарантировать, что один и тот же IP-адрес назначен одному и тому же серверу (на основе MAC-адреса), и этот сценарий вряд ли когда-либо происходить. Если это произошло по какой-либо причине, одному из серверов будет назначен IP-адрес, а другому серверу будет назначен другой IP-адрес. Серверу, желающему использовать IP-адрес, назначенный другому серверу, будет отказано в его запросе на использование IP-адреса, и ему будет назначен другой IP-адрес, или ему не будет назначен IP-адрес, и он назначит себе IP-адрес в Диапазон APIPA, если ОС на сервере поддерживает APIPA.
Мое «обоснованное» предположение состоит в том, что у провайдера было отключение оборудования / сети, основываясь на том, что вы сказали о том, что его собственный веб-сайт не работает, и что вы не можете с ним связаться. Не думай об этом слишком много. У провайдера был сбой.
Я предлагаю найти более надежного поставщика.
Если вы хотите знать, отправляет ли другой хост в том же сегменте ARP-ответы при отправке запросов на ваш IP-адрес, самый простой подход - просто отправить несколько запросов самостоятельно и проверить, получили ли вы ответ. Вот пример команды (и используйте здесь свой собственный IP-адрес):
arping -I eth0 198.51.100.241
Если вы подозреваете, что это происходит с перерывами, то запуск команды tcpdump в сеансе экрана может собрать доказательства того, что это происходит:
tcpdump -pni eth0 'arp' -s0 -Uw /var/tmp/arp.pcap
Если ни один из подходов не даст вам достаточной информации, вы можете начать искать другие подсказки.
Конфликт IP-адресов повлияет только на пакеты, отправляемые в одном направлении. Поэтому, если вы настроите программное обеспечение на сервере и в другом месте, чтобы периодически отправлять пакеты друг другу и отслеживать время отправки, а также время получения каждого пакета, вы сможете увидеть, теряются ли пакеты в одном направлении, а не другой.
Кроме того, конфликт IP-адресов, скорее всего, затронет только одно семейство адресов. Поэтому, когда ваш IPv4-адрес недоступен, вы можете войти в систему, используя IPv6, и исследовать, поскольку проблема сохраняется.
Наконец, одновременные трассировки с каждого конца как во время сбоя, так и во время нормальной работы предоставят много информации о точном месте сбоя.