Я попробовал описанное выше с Vagrant/VirtualBox и ansible, но почему-то это вообще не сработало в моей среде разработки.
Старые имена интерфейсов сохранялись, что бы я ни делал, до полного перезапуска.
Я добавил следующие правила в/etc/udev/rules.d/60-persistent-net.rules
(на основе:https://access.redhat.com/solutions/112643)
Моя цель состояла в том, чтобы дать интерфейсу конкретное имя на основе адреса PCI.
Пример:
ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:09.0", NAME:="int0"
ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:10.0", NAME:="ext0"
После добавления этих правил я выполнил следующие команды:
ip link set eth0 down
udevadm control --reload-rules
udevadm trigger
ip link set int0 up
Сообщение об ошибке Cannot find device "int0"
в команде ip link set * up
. А в /var/log/messages
заметил следующие сообщения
Aug 16 17:08:41 localhost ansible-command: Invoked with creates=None executable=None _uses_shell=True strip_empty_ends=True _raw_params=ip link set eth0 down && udevadm control --reload-rules && udevadm trigger && ip link set int0 up#012 removes=None argv=None warn=True chdir=None stdin_add_newline=True stdin=None
Aug 16 17:08:41 localhost NetworkManager[6989]: [1565975321.5971] device (eth6): state change: disconnected -> unavailable (reason 'carrier-changed', sys-iface-state: 'managed')
Aug 16 17:08:41 localhost systemd-udevd: Network interface NamePolicy= disabled on kernel command line, ignoring.
Но следующее сработало, получив доступ к виртуальной машине через VirtualBox и выполнив следующие команды, чтобы удалить и повторно -добавить модуль ядра.
rmmod e1000
modprobe e1000
Я нашел это в следующей теме:https://www.centos.org/forums/viewtopic.php?t=54695
Странная вещь, которую я заметил, заключалась в том, что lsmod
дает мне (примечаниеUsed by
)
[vagrant@node-01 ~]$ lsmod
Module Size Used by
e1000 137586 0
Благодаря обсуждению в чате мне удалось решить свою проблему и кое-что узнать.
Здесь происходят две неприятные вещи, обе они связаны с сетевым коммутатором, расположенным между моим маршрутизатором и Интернетом:
Компьютер --> Маршрутизатор --> Коммутатор--> Интернет
Коммутатор блокирует пакеты проверки связи.
Это означает, что такие инструменты, как ping
, traceroute
, tracepath
и mtr
, не будут работать, даже если я смогу подключиться к Интернету, поэтому в данном случае они бесполезны в качестве диагностических инструментов. Судя по всему, некоторые администраторы отключают эти инструменты по «соображениям безопасности», хотя в моем случае они просто посеяли много путаницы. Поскольку я никогда раньше не видел этого в дикой природе и даже не слышал о том, что это делается, я не рассматривал это как вариант. Урок, который следует здесь усвоить, состоит в том, что вы не можете всегда полагаться на то, что ping
будет доступен.
Обратите внимание, что сам маршрутизатор нормально обрабатывает ping-пакеты. Это объясняет, почему я мог пинговать любое другое устройство, подключенное к тому же маршрутизатору, но больше ничего.
(На самом деле, это рассуждение может быть слишком наивным. По словам @Cbhihe в чате , в конце концов, маршрутизатор может выполнять блокировку. Я не смог сказать, но приведенная выше картинка по-прежнему является полезной моделью того, что происходит не так.)
Однако само по себе это не является причиной проблемы.Это просто расстраивает попытки его исследовать. Но, учитывая, что переключатель является злом в одном отношении, он, вероятно, является злом и в других отношениях. Это подводит нас к...
Локальный DHCP-сервер неправильно взаимодействовал с моим DHCP-клиентом.
Каждому компьютеру нужен DHCP-клиент, чтобы ему можно было назначить IP-адрес при подключении к сети. Мой был внутренним dhcp-клиентом NetworkManager, о чем свидетельствует dhcp=internal
в NetworkManager.conf
. Оказывается, этот DHCP-клиент довольно прост. Хотя в прошлом это всегда работало, с этим сервером DHCP это не сработало. В результате информация об IP-адресации на моем компьютере была установлена неправильно.
Я не знаю точно, что было установлено неправильно. Конечно, мой компьютер получил действительный IP-адрес, как показано ip addr
, иначе я не смог бы пропинговать его со своего телефона. Но что-то еще, должно быть, было не так, потому что коммутатор не успокоился, и это заставило его отбросить все мои IP-пакеты.
Обратите внимание, что адрес обратной связи 127.0.0.1 в /etc/resolv.conf
не является ошибкой. Это просто отражает тот факт, что я использую dnsmasq для кэширования DNS, о чем свидетельствует dns=dnsmasq
в NetworkManager.conf
. Идея состоит в том, что dnsmasq прослушивает DNS-запросы на 127.0.0.1, проверяет, есть ли они в его кеше, и, если нет, перенаправляет их на настоящий DNS-сервер. Я включил это давным-давно в качестве микро -оптимизации. Реальный DNS-сервер был установлен на разумное значение, поэтому кажется, что DNS не был здесь напрямую фактором. Я все еще не мог связаться с DNS-сервером, чтобы что-то решить, но это было из-за уже упомянутых проблем, а не из-за того, что он был установлен неправильно.
Корень проблемы — мой DHCP-клиент. Вместо этого я заменил его на более функциональный dhclient
, и все заработало. Я по-прежнему не мог пинговать, но у меня был доступ в интернет, а это главное.
После дополнительной настройкиЯ решил заменить dnsmasq на более новый systemd -, и все по-прежнему работает. Мой NetworkManager.conf
теперь читается как
[main]
plugins=keyfile
dns=systemd-resolved # Not strictly necessary, but helpful to remind me
dhcp=dhclient
Из них dhclient не требует настройки, а systemd -разрешено требует
systemctl start systemd-resolved
systemctl enable systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf