Пропала сеть на машине

«Сеть пропала» — это два разных случая: до машины не доходят снаружи и машина сама никуда не ходит. Начинать нужно с консоли, потому что SSH в такой ситуации недоступен, а консоль работает всегда — она подключена к машине напрямую, минуя сеть.

Шаг 1. Зайти через консоль

Откройте /hosting/vds/<id>, вкладку «Консоль». Текстовая консоль (последовательный порт) подойдёт для любых команд, «Экран» (VNC) нужен, если система не отдаёт приглашение в последовательную линию. Если консоль показывает приглашение входа — машина жива, проблема именно в сети, а не в загрузке.

Если приглашения нет и на «Экране» видно сообщение ядра об ошибке, смотрите статью Ядро упало: kernel panic и что дальше.

Шаг 2. Проверить интерфейс и адрес

ip -brief address
ip route

На интерфейсе должен стоять ваш публичный адрес IPv4 из вкладки «Обзор», а в маршрутах — строка default via .... Частые находки:

• интерфейс в состоянии DOWN — поднимите его: ip link set dev ens18 up;
• адрес пропал после ручной правки конфигурации — восстановите файл настроек и перезапустите службу сети (systemctl restart systemd-networkd или netplan apply в Ubuntu);
• нет маршрута по умолчанию — временно верните его командой ip route add default via <шлюз>, чтобы восстановить доступ, и затем поправьте конфигурацию, иначе после перезагрузки всё повторится.

Правки через ip живут до перезагрузки. Настоящее исправление всегда в конфигурационном файле.

Шаг 3. Разделить «нет связи» и «нет имён»

ping -c3 1.1.1.1
ping -c3 millida.net

Если адрес пингуется, а имя — нет, сеть в порядке, сломано разрешение имён: перейдите к статье Не разрешаются имена (DNS).

Шаг 4. Посмотреть фильтр пакетов

Самая частая причина потери доступа — собственное правило, закрывшее вход. Проверьте:

nft list ruleset
iptables -S
ufw status verbose

Если видите политику DROP на входящих без разрешения 22-го порта, вы отрезали себе SSH. Через консоль верните доступ:

ufw allow 22/tcp
ufw reload

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

Шаг 5. Проверить сам демон SSH

Сеть может работать, а порт быть закрыт, потому что служба упала:

systemctl status ssh
ss -tlnp | grep :22

Разбор состояния службы — в статье Служба не запускается: разбор по systemd.

Если ничего не помогло

Загрузитесь в диск восстановления SystemRescue из вкладки «Доступ»: вход root без пароля, диск машины виден как /dev/sda. Смонтируйте корень и поправьте конфигурацию сети «снаружи» системы. Когда закончите, верните обычный режим загрузки и перезагрузите машину — иначе она так и будет стартовать в SystemRescue.