Вопросы Теги

Маршрутизатор блокирует одно конкретное устройство

Я попробовал описанное выше с 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

0
19.09.2021, 14:43
1 ответ

Благодаря обсуждению в чате мне удалось решить свою проблему и кое-что узнать.

Причина

Здесь происходят две неприятные вещи, обе они связаны с сетевым коммутатором, расположенным между моим маршрутизатором и Интернетом:

Компьютер --> Маршрутизатор --> Коммутатор--> Интернет

  1. Коммутатор блокирует пакеты проверки связи.

    Это означает, что такие инструменты, как ping, traceroute, tracepathи mtr, не будут работать, даже если я смогу подключиться к Интернету, поэтому в данном случае они бесполезны в качестве диагностических инструментов. Судя по всему, некоторые администраторы отключают эти инструменты по «соображениям безопасности», хотя в моем случае они просто посеяли много путаницы. Поскольку я никогда раньше не видел этого в дикой природе и даже не слышал о том, что это делается, я не рассматривал это как вариант. Урок, который следует здесь усвоить, состоит в том, что вы не можете всегда полагаться на то, что pingбудет доступен.

    Обратите внимание, что сам маршрутизатор нормально обрабатывает ping-пакеты. Это объясняет, почему я мог пинговать любое другое устройство, подключенное к тому же маршрутизатору, но больше ничего.

    (На самом деле, это рассуждение может быть слишком наивным. По словам @Cbhihe в чате , в конце концов, маршрутизатор может выполнять блокировку. Я не смог сказать, но приведенная выше картинка по-прежнему является полезной моделью того, что происходит не так.)

Однако само по себе это не является причиной проблемы.Это просто расстраивает попытки его исследовать. Но, учитывая, что переключатель является злом в одном отношении, он, вероятно, является злом и в других отношениях. Это подводит нас к...

  1. Локальный 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
1
20.09.2021, 12:40

Теги

Похожие вопросы