Я только что работал на локальном сервере Linux в моем офисе, подключаясь к нему через SSH. Я изменил некоторые настройки сети. В частности, я добавил простой сетевой мост, который заменил предыдущее соединение Ethernet (eth0). В обоих случаях сетевой адрес является статическим IPv4-адресом.
После того, как я внес эти изменения и перезапустил сетевой демон, используя systemctl restart systemd-networkd, Я был заблокирован и не мог вернуться в машину по ssh.
К счастью, у меня был доступ к физической консоли. Хотя перезапуск сети дал мне новый мост с правильным адресом, он не удалил адрес из eth0 - хотя все настройки конфигурации верны. Итак, мне пришлось вручную ip a flush eth0, и я вернулся к работе.
Думаю, если бы это был корневой сервер в удаленном месте, а не локальная машина, я бы выглядел очень старым.
Что я должен был сделать по-другому, какой здесь подход правильный?
Обновить: Из двух предоставленных ответов я понимаю, что должен был быть более ясным. Я полностью осведомлен обо всех аппаратных возможностях, позволяющих сохранить доступ к моей станции. Поскольку у меня есть и используются они, я чувствую себя комфортно, вызывая определенные изменения, рискуя что-то плохое. Это немного хлопотно, но я могу просто войти в систему через последовательную консоль, и все снова в порядке. Но мне было интересно, что, если бы у меня их не было, как бы остальные из вас изменили сетевые настройки, которые теоретически могут вас отключить?
И, честно говоря, я также очень конкретно задаюсь вопросом, почему мой интерфейс eth0 сохранил старый IP-адрес, даже если я перезапустил сетевой сервис с новыми настройками? Для меня это просто не похоже на желаемое поведение.
Есть как минимум два способа сделать это иначе:
Например.
sleep 15*60 && shutdown -r +NOW "I messed up. Rebooting"
(On a new shell)
ifconfig / ip whatever
Затем при рабочем измененном состоянии отмените перезагрузку.
PS1: Спящий режим и выключение используются, чтобы не спамить пользователей. (хотя вы можете просто выключить -t 15m, а затем отменить выключение.
PS2: Обратите внимание на сон && выключение и не спать ; неисправность.
В наименее навязчивый способы решения такой проблемы - это те, которые не требуют перезагрузки.
Последовательная консоль - один из способов получить доступ. Также существует другое более специализированное оборудование для доступа к хосту без функциональной сети.
Если у вас нет такого внеполосного доступа, стоит попробовать альтернативные способы связи с хостом через сеть. Первое альтернативное средство - использовать преимущества двойного стека, дающего вам некоторую избыточность. Если вы испортите конфигурацию IPv4, вы все равно сможете связаться с хостом через IPv6, и наоборот.
Если вы испортите и IPv4, и IPv6, вы все равно сможете связаться с хостом через локальную связь IPv6. То, как работает локальная связь IPv6, делает его немного более устойчивым к неверно сконфигурированной сети, поэтому есть хорошие шансы, что это сработает. Этот метод работает только в том случае, если у вас есть доступ хотя бы к одному другому функциональному узлу в том же сегменте сети, что и ваша цель.
В более навязчивый Способы решения проблемы - перезагрузка. Даже если у вас нет оборудования для полного удаленного доступа, у вас все еще может быть оборудование для удаленного запуска перезагрузки. Это может быть достигнуто с помощью оборудования, которое может запускать линию сброса на материнской плате, или с помощью оборудования, которое включает и выключает питание хоста.
Если на хосте нет оборудования для внеполосного администрирования, возможно, вам потребуется обратиться за помощью к персоналу на месте. В таких случаях, безусловно, легче попросить их перезагрузить машину, чем попросить их отладить сетевое соединение.
После перезагрузки компьютера вам нужно как-то убедиться, что он действительно снова в сети. Если плохое изменение было только в памяти и после перезагрузки вернется заведомо исправная конфигурация, особого внимания не потребуется. В более проблемных случаях может быть полезно настроить хост на попытку загрузки PXE и загрузку только с локального диска, если в сети нет PXE-сервера. Однако этот подход имеет смысл только в том случае, если вы знаете, что можете доверять сети.
В самый навязчивый заключается в применении любых имеющихся у вас процедур для решения ситуации, когда хост полностью потерян. Эти процедуры обычно предназначены для отказа оборудования или, что еще хуже, если здание сгорело дотла. Но они могут быть применены для такой тривиальной задачи, как неправильно настроенная сеть. (Каким бы навязчивым ни был этот подход, он редко бывает предпочтительным решением.)