Когда я использую ifconfig ens4 down и ifconfig ens4 up в google vm, соединение не возвращается и остается отключенным
sudo -s
apt install screen
screen -s test sh start.sh
ctrl + a + d
echo "1"
ifconfig ens4 up
sleep 5
echo "2"
ifconfig ens4 down
sleep 5
echo "3"
sleep 5
ifconfig ens4 up
echo "4"
останавливаться после завершения ifconfig ens4 и не выполнять ifconfig ens4 up
поэтому я перезапускаю панель облачной консоли Google, чтобы вернуться в нормальное состояние
Мне нужно выключить и включить его, чтобы перевести машину в режим моста, но он перестает работать, когда Ens4 выключен, даже с использованием screen -s test sh start.sh;
я тоже пробую
ip link set dev ens4 up
я обновляю для: соединение linux bridge.sh потеряно
Когда интерфейс отключен, любой ручной маршрут, связанный с IP-адресом на этом интерфейсе, удаляется. Когда интерфейс запущен, этот (е) ручной маршрут (ы), безусловно, включая дефолт маршрут все еще утерян.
Для современности заменю любое появление ifconfig ens4 down by (с использованием полного синтаксиса) ip link set dev ens4 down и ifconfig ens4 up по ip link set dev ens4 up
Предположим Ens4 должно быть назначено 192.0.2.2/24 с маршрутом по умолчанию, использующим 192.0.2.1 в качестве шлюза.
Добавить адрес:
ip address add 192.0.2.2/24 dev ens4
Поднять интерфейс административно:
ip link set dev ens4 up
Если бы не было noprefixroute в адресе, то этот маршрут будет автоматически (=> proto kernel) добавлен при административном запуске интерфейса:
192.0.2.0/24 dev ens4 proto kernel scope link
(Если команда была ip address add dev 192.0.2.2/24 dev ens4 noprefixroute тогда конфигурация также должна была бы добавить маршрут вручную, например, ip route add 192.0.2.0/24 dev ens4.)
Добавить маршрут по умолчанию:
ip route add default via 192.0.2.1 dev ens4
Повторное включение интерфейса просто не имеет никакого эффекта. Теперь, когда интерфейс отключен, любой маршрут, требующий его адреса, исчезает (в цепном эффекте): 192.0.2.0/24 и, следовательно, дефолт route, поскольку он зависит от маршрута к 192.0.2.1.
Как только интерфейс снова заработает, только автоматический (прото-ядро) ссылка на область действия возвращается маршрут, а не маршрут по умолчанию, добавленный вручную: соединение остается потерянным. Просто добавьте еще раз этот маршрут по умолчанию:
ip link set dev ens4 up
ip route add default via 192.0.2.1 dev ens4
Предположим, есть мост под названием bridge0.
ip link add name bridge0 type bridge
ip link set dev bridge0 up
Когда интерфейс становится портом моста, что-то вроде:
ip link set dev ens4 master bridge0
Маршрутизация для этого интерфейса останавливается: пакеты, полученные на нем, пересылаются на мост, а не на уровень маршрутизации IPv4 (подробности в этом блог, проверьте пункт 5). Но в то же время на интерфейсе остается определенный маршрут, если его не удалить, что может запутать сетевой стек для исходящих пакетов, строгой пересылки обратного пути и т. Д.
Таким образом, все адреса должны быть удалены (=> автоматически удаляет и маршруты), желательно раньше, например:
ip address flush dev ens4
и добавил вместо этого к мосту, а также маршрут по умолчанию:
ip address add 192.0.2.2/24 dev bridge0
ip route add default via 192.0.2.1 dev bridge0
Все эти шаги нарушают работу сети на несколько секунд, поэтому должны выполняться автоматически, с доступом к консоли, или даже все сразу в течение экран слой.