Корневой сервер с измененными настройками сети - как постараться не быть закрытым?
Я просто работал над локальным сервером Linux в своем офисе, соединяясь с ним через SSH. Я изменил некоторые настройки сети. А именно, я добавил простой сетевой мост, который заменил предыдущее соединение Ethernet (eth0). В обоих случаях сетевой адрес является статическим адресом IPv4.
После того, как я сделал те изменения и перезапустил сетевого демона, использующего systemctl restart systemd-networkd, Я был заблокирован, и не мог ssh назад в машину.
К счастью у меня был доступ к физической консоли. В то время как перезапуск сети действительно давал мне новый мост с корректным адресом, это не удалило адрес из eth0 - даже при том, что все параметры конфигурации корректны. Так, я имел к вручную ip a flush eth0, и я назад был в порядке.
Я предполагаю, было ли это корневым сервером в удаленном месте вместо локальной машины, я выглядел бы очень старым теперь.
Что я должен был сделать по-другому, каков правильный подход здесь?
Обновление: Из двух предоставленных ответов до сих пор я вижу, что должен был быть более ясным. Я полностью осведомлен обо всех аппаратных опциях, как сохранить доступ к моей станции. Поскольку я имею и использую их, я чувствую себя комфортно для вызова определенных изменений рискуя чем-то плохо случай. Это - что-то вроде стычки, но я могу просто войти в систему через последовательную консоль, и все хорошо снова. Но я задавался вопросом, что, если у меня не было их, как был бы, остальная часть Вас идет об изменении настроек сети, которые могут теоретически разъединить Вас?
И откровенно говоря, я также просто задаюсь вопросом в очень конкретном способе, почему мой интерфейс eth0 сохранил старый IP-адрес даже при том, что я перезапустил сетевую службу с новыми настройками? Это просто не похоже на желаемое поведение мне.
Есть как минимум два способа сделать это по-другому:
- Удаленная консоль (HP ILO, DELL DRAC, ...), позволяющая получить доступ через собственный сетевой адаптер и собственный 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 link-local общение. То, как работает локальная связь IPv6, делает его немного более устойчивым к неверно сконфигурированной сети, поэтому есть хорошие шансы, что это сработает. Этот метод работает только в том случае, если у вас есть доступ по крайней мере к одному другому функциональному узлу в том же сегменте сети, что и ваша цель.
Более назойливый способ решения проблемы - перезагрузка. Даже если у вас нет оборудования для полного удаленного доступа, у вас все еще может быть оборудование для удаленного запуска перезагрузки. Это может быть достигнуто с помощью оборудования, которое может запускать линию сброса на материнской плате, или с помощью оборудования, которое включает и выключает питание хоста.
Если на хосте нет оборудования для внеполосного администрирования, вам может потребоваться запросить: сотрудники сайта в помощь. В таких случаях, безусловно, легче попросить их перезагрузить машину, чем попросить их отладить сетевое соединение.
После перезагрузки машины вам нужно каким-то образом гарантировать, что она действительно вернется в оперативный режим. Если плохое изменение было только в памяти и после перезагрузки вернется заведомо исправная конфигурация, особого внимания не потребуется. В более проблемных случаях может быть полезно настроить хост на попытку загрузки PXE и загрузку только с локального диска, если в сети нет PXE-сервера. Однако этот подход имеет смысл только в том случае, если вы знаете, что можете доверять сети.
Наиболее назойливым является применение любых имеющихся у вас процедур для обработки ситуации, когда хост полностью потерян. Эти процедуры обычно предназначены для отказа оборудования или, что еще хуже, если здание сгорело дотла. Но они могут быть применены для такой тривиальной задачи, как неправильно настроенная сеть. (Каким бы навязчивым ни был этот подход, он редко бывает предпочтительным решением.)