У меня есть проблема, которую я не смог выяснить путем поиска с помощью Google:
Мы недавно установили Сервер Ubuntu 18.04 на нашем vmware vSphere. После нескольких незначительных проблем клавиатуры о консоли и некоторых не так незначительные проблемы с нашим корпоративным прокси / man-in-the-middle сеть, сервер работает главным образом стабильный (я должен был установить новый корневой сертификат, настроить прокси для способного и удара). Это только работает в нашей корпоративной сети, никакой внешний возможный доступ (который прекрасен на данный момент / желаем).
Остающаяся проблема: Ежедневно между ~8-11 часами сервер не может быть достигнут. Никакой ping, ssh, приложения хоста докера доступны. После 11 все хорошо работает. Я взглянул на журналы сервера, но не смог найти любые проблемы. Это может иметь некоторое отношение к ежедневным стандартным программам обновления, но я не знаю, где посмотреть. Я уже изменил случайный сон в /etc/cron.daily/apt-compat
к 10 секундам (с 1800).
системный журнал:
Jul 11 06:25:01 servername rsyslogd: [origin software="rsyslogd" swVersion="8.32.0" x-pid="5678" x-info="http://www$
Jul 11 06:54:15 servername systemd[1]: Starting Daily apt upgrade and
clean activities...
Jul 11 06:54:18 servername systemd[1]: Started Daily apt upgrade and clean activities.
Jul 11 07:17:01 servername CRON[9579]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 11 07:46:28 servername systemd[1]: Starting Daily apt download activities...
Jul 11 07:46:57 servername systemd[1]: Started Daily apt download activities.
Jul 11 08:17:01 servername CRON[9995]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 11 09:17:01 servername CRON[10009]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 11 10:17:01 servername CRON[10022]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jul 11 10:41:48 servername systemd[1]: Started Session 54 of user user.
Кто-либо знает, как решить эту проблему?
Удачи!
Одной из возможностей является конфликт IP-адресов: кто-то подключает ноутбук с таким же фиксированным адресом критического сервера через некоторый промежуток времени. У меня была эта проблема несколько раз в моей университетской сети. Использование утилиты arping
с другого сервера в той же VLAN показало, что два MAC-адреса отвечают на один и тот же IP-адрес, затем с помощью интерфейса администратора коммутаторов выследил физический порт, используемый преступником, и отключил его в соответствующем офисном коммутаторе. Затем пользователь пришел, чтобы сообщить о проблеме «у меня нет интернета»;)