Dmitry Tallmange, на самом деле, нет разницы, натить в VPN, или натить в белый IP "ретранслятора". Другой вопрос, что SIP могуть быть проблемы -- не очень-то он приспособлен для обхода NAT-ов, тем более нескольких. С остальным -- вполне реализуемо.
ilovemaryjane, относится напрямую. Если вы по открытым каналам связи гоняете чувствительную информацию, или по телефону случайным людям её разглашаете (наша контора проводит периодически телефонный фишинг, и там вплоть до паспортных данных генерального директора у некоторых организаций можно заполучить, просто по телефону), то с безопаностью, в том числе и IT у вас всё плохо :-)
perrfect, keepalived работает только в случае, если у оба сервера в одном L2-сегменте. В случае VPS это совсем не факт, что они в одном сегменте. И кроме того, хостер может резать VRRP на своей сети.
Камера не отвечает на ARP-запрос сервера. Вариантов тут два -- либо она не видит ARP-запроса, либо видит и отвечает, но ответ не долетает до сервера.
Попробуйте какое-нибудь устройство подключить в порт свича, куда камера подключена, и присвоить этому устройству такой же IP-адрес. Затем пингануть с сервера этот IP.
sflyer, это означает, что не пришёл arp-ответ от камеры. Такое бывает в случае, когда нет L2-связности между устройствами. Но так как вы говорите, что другие устройства камеру отлично пингуют, и одновременно пингуют сервер, то тогда это странно всё.
Попробуйте следующее:
1. Если коммутаторы управляемые, то зачистить на них ARP-кэш. Если неуправляемые, то просто перезагрузить оба;
2. На сервере зачистить ARP-кэш (ip neigh flush -statistics);
3. Запустить tcpdump -ni eno1 arp and icmp на сервере и попробовать пингануть камеру ещё раз, посмотреть, что покажет дамп трафика на этом этапе.
Да, и зайдите в админку камеры, посмотрите её реальный MAC. И сравните её с MAC-адресом, который видят на этом IP другие компы в сети, которые пингуют камеру. Возможно, у вас конфликт IP или MAC-адресов в сети.
Роман Кистин, заблочьте исходящие TCP SYN-пакеты с сервера, до выяснение. Заодно можно также UDP исходящие закрыть, кроме 53 порта прописанных на сервере DNS-серверов и 123 портов прописанных NTP-серверов. Хотя, если там действительно PE, то это может и не помочь. Но в любом случае, лишним не будет.
Также поменять пароли всем учётка, прошерстить, у кого есть доступ к sudo, настроить отгрузку логов на другой сервер, увеличить их (логов) детализацию, особенно в весте, веб-, почтовом сервере и PHP или что у вас там.
Верно я понимаю, это ддосят какой-то сайт на сервере?
Нет, судя по их письму: "there was an attack from your server." Т. е. с ВАШЕГО сервера.
Также судя по тому, на основании какого критерия они делают такой вывод -- это может быть и вовсе не атака, а вполне легитимный трафик. Что за сайт у вас? Файлы какие-то большие могут с сайта скачиваться?
squidw, а, так это злобный препод виноват в том, что вы не смогли man nfcapd и man nfdump прочитать?
Какие у вас проблемы с настройкой netflow на микротике? Там штук 8 параметров всего, из которых 7 вообще не нужно трогать на начальном этапе. Достаточно указать поднять nfcapd на линуксе/фряхе, а потом прописать на микротике /ip traffic-flow target ip-адрес:порт этого линукса. Nfcapd будет заботливо складывать netflow в файлики. Которые потом можно будет прошерстить nfdump'ом в любом разрезе, какой вам только захочется. Надо только силу воли в кулак собрать, и документацию прочитать.
Станислав Бодро́в, клонирование на ESXi происходит так же, как и не на зашифрованных виртуалках -- клонируется содержимое виртуального диска (содержимое которого зашифровано драйвером). Так что с этой стороны риска нет.
JunDevTest, помимо сказанного коллегой Moskus выше, вы к тому ещё и выложили не минидамп, а всего-лишь его описание :-) Из которого следует, что сбой происходит прямо в ядре ОС. Более никакой информации о проблеме оттуда извлечь не удастся. И да -- если вам нужна более детальная информация, то дело может сдвинуться, если вы для начала предложите материальное вознаграждение за анализ дампа.
alexdora, но тем не менее, если вывести за скобки вопросы отказоустойчивости, то сегментацию имеет делать хотя бы с целью обеспечения безопасности и упрощения обслуживания инфраструктуры. Если у вас на одном сервере куча сервисов, то компрометация этого сервера затронет все сервисы, которые на нём работают. А если сервисы у вас поделены на несколько серверов (виртуалок), то придётся отдельно вскрывать каждый сервер.
С обслуживанием то же самое. Если нужно ребутнуть сервак после обновлений, то ребут сервера с кучей сервисов, как вы понимаете, приведёт к тому, что вся эта куча будет недоступна для пользователей.
alexdora, сегментация сервисов и сетей -- всегда обоснована, если делать всё грамотно. Другой вопрос, что если у вас гипервизор один, то с его падением один хрен поляжет всё :-)
alex-1917, да-да, расскажите, какие вы там нано-технологии внедряете в дефолтные конфигурации, ради которых клиент должен раскошеливаться на 6k $, как тут некоторые выше пишут :-)
