Astra linux SE 1.7 Орел не работает сеть (нет линка) после загрузки ОС

[Ckadi]

После установки Astra linux SE 1.7 Орел (без GUI, kernel 5.4.0-54-generic, hardware name: Aquarius P30 K44/AQB560M) подключил локальный репозиторий (из архива devel-1.7.3-uu2-03.03.2023_11_09.tar).
В /etc/network/interface прописал auto eth0, iface eth0 inet static, address 10.79.192.135/24, gateway 10.79.192.1, dns-domain, dns-nameservers 10.79.192.11, 10.79.192.12. После ifconfig eth0 down \ up сеть появилась, по IP пинг пошел.
Установил DNS клиент resolvconf (apt install resolvconf ), в /etc/resolvconf/resolv.conf.d/base прописал: nameserver 10.79.192.11, nameserver 10.79.192.12, добавил сервис в автозагрузку: systemctl enable resolvconf.service, перезапустил сервисы networking.service, resolvconf.service - по имени пошел пинг. Установил kesl_11.3.0-7508.cert_amd64.deb, сконфигурировал, установил klnagent64_14.0.0-4646_amd64.deb, сконфигурировал. Перезагрузился - светодиод линка не горит, сети нет (пинга нет), сервисы ( systemctl status resolvconf.service, systemctl status networking.service) работают (active), команда ifconfig выдает информацию о eth0 с ip 10.79.192.135/24, lo.

Команда lshw -C network выдала инфу о сетевой карте, в том числе о названии драйвера: igc.
lsmod | grep Igc:
Module size used by
igc 89112 0

Попробовал загрузить модуль igc:
modprobe igc
не дало эффекта.

В /var/log по диагонали посмотрел файлы логов - ошибок не нашел.

Подскажите куда копать?

 

[Ckadi]

ifconfig eth0 down
ifconfig eth0 up
помогло, пинг по IP, по сетевому имени пошел. НО: после перезагрузки опять нет сети\линка.

 

[gfh1gfh1]

Контроль устройств в касперском включен? Может он блокирует...

 

[Ckadi]

Остановил службы Касперского - не заработала сеть, перезагрузился - не заработала. Также через ifconfig eth0 down/up поднимается только.

 

[Alex-der]

Покажите, на всякий случай, ifconfig -a -v до и после ifconfig up|down. Может, что-то все вместе увидим?..
А! и это - grep eth0 /var/log/messages и grep eth0 /var/log/syslog|tail -40. Это уже после ifconfig up.

 

[Ckadi]

До ifconfig eth0 down\up:
eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 10.79.192.135 netmask 255.255.255.0 broadcast 10.79.192.255
ether 00:58:3f:1b:ac:22 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xa1200000-a12fffff

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 2631 bytes 238760 (233.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2631 bytes 238760 (233.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
После:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.79.192.135 netmask 255.255.255.0 broadcast 10.79.192.255
inet6 fe80::258:3fff:fe1b:ac22 prefixlen 64 scopeid 0x20<link>
ether 00:58:3f:1b:ac:22 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device memory 0xa1200000-a12fffff

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 2641 bytes 239618 (234.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2641 bytes 239618 (234.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

grep eth0 /var/log/messages :
Nov 7 05:58:19 bender3 kernel: [ 1.204464] igc 0000:01:00.0 eth0: MAC: 00:58:3f:1b:ac:22
Nov 7 07:47:55 bender3 kernel: [ 1.214345] igc 0000:01:00.0 eth0: MAC: 00:58:3f:1b:ac:22
Nov 8 05:56:02 bender3 kernel: [ 1.209509] igc 0000:01:00.0 eth0: MAC: 00:58:3f:1b:ac:22
Nov 8 07:51:08 bender3 kernel: [ 6909.049561] igc 0000:01:00.0 eth0: igc: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Nov 8 07:51:08 bender3 kernel: [ 6909.050762] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Nov 8 07:53:03 bender kernel: [ 1.213916] igc 0000:01:00.0 eth0: MAC: 00:58:3f:1b:ac:22
Nov 8 07:53:13 bender kernel: [ 13.181566] igc 0000:01:00.0 eth0: igc: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Nov 8 07:53:13 bender kernel: [ 13.182459] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Nov 9 03:44:50 bender kernel: [71509.533093] igc 0000:01:00.0 eth0: igc: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Nov 9 03:44:50 bender kernel: [71509.533950] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Nov 9 04:13:39 bender kernel: [ 1.209497] igc 0000:01:00.0 eth0: MAC: 00:58:3f:1b:ac:22
Nov 9 05:42:13 bender kernel: [ 1.204585] igc 0000:01:00.0 eth0: MAC: 00:58:3f:1b:ac:22
Nov 9 07:51:31 bender kernel: [ 7760.457707] igc 0000:01:00.0 eth0: igc: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Nov 9 07:51:31 bender kernel: [ 7760.458886] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Nov 9 07:53:38 bender kernel: [ 1.213819] igc 0000:01:00.0 eth0: MAC: 00:58:3f:1b:ac:22
Nov 10 03:34:11 bender kernel: [70836.028075] igc 0000:01:00.0 eth0: igc: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Nov 10 03:34:11 bender kernel: [70836.029546] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

grep eth0 /var/log/syslog|tail -40 :
Nov 10 03:34:05 bender avahi-daemon[542]: Interface eth0.IPv4 no longer relevant for mDNS.
Nov 10 03:34:05 bender avahi-daemon[542]: Leaving mDNS multicast group on interface eth0.IPv4 with address 10.79.192.135.
Nov 10 03:34:05 bender avahi-daemon[542]: Withdrawing address record for 10.79.192.135 on eth0.
Nov 10 03:34:09 bender avahi-daemon[542]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.79.192.135.
Nov 10 03:34:09 bender avahi-daemon[542]: New relevant interface eth0.IPv4 for mDNS.
Nov 10 03:34:09 bender avahi-daemon[542]: Registering new address record for 10.79.192.135 on eth0.IPv4.
Nov 10 03:34:11 bender kernel: [70836.028075] igc 0000:01:00.0 eth0: igc: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Nov 10 03:34:11bender kernel: [70836.029546] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Nov 10 03:34:12 bender avahi-daemon[542]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::258:3fff:fe1b:ac22.
Nov 10 03:34:12 bender avahi-daemon[542]: New relevant interface eth0.IPv6 for mDNS.
Nov 10 03:34:12 bender avahi-daemon[542]: Registering new address record for fe80::258:3fff:fe1b:ac22 on eth0.*.

 

[Alex-der]

1. Хотелось бы, конечно, увидеть "чистый" результат - сразу после перезагрузки системы, ну да ладно... Не думаю, что я увижу что-то принципиально новое.
2. Ну, из того, что бросается в глаза - до up/down на интерфейсе не было адреса inet6, а после передёргивания - появляется. И в логе этот момент тоже отмечается. Недавно в каком-то обсуждении по FreeBSD мне рассказывали, что в новых ядрах/системе категорически не рекомендуется отключать поддержку inet6. В онлайн конференции по Windows 10/11 тоже была высказана такая мысль.
Хоть с моей точки зрения наличие/отсутствие протокола не должно влиять на работоспособность системы в сети (я ещё помню зверинец, бегавший в локалках - ipx|NETBEUI|AppleTalk), но, похоже, в новых ядрах идёт достаточно жёсткая привязка к inet6. Надо разбираться...

Как вариант решения - я бы попробовал убрать настройки сетевой карты из системы вообще и поигрался бы командой ifconfig, обращая внимание на результат. Ну или, если не хочется долго разбираться, добавил бы связку ifconfig up|down в стартовый скрипт (cron или rc.local, например).

 

[oko]

to Alex-der
Ни у ALSE, ни у Debian вплоть до 6.1+ ядер нет принципиального требования активности IPv6. Проверено не раз...

*в сторону*
Все последующее надо бы выбить на стартовой странице форума аля скрижали с заповедями. Ибо...
Primo, ставить ALSE только с 1.7.0-iso без каких-либо сборок 1.7.2, 1.7.3-by-hattab и т.п. Даже если их предоставил поставщик в фирменной упаковке со всеми документами. И уж тем более не юзать какие-то devel-iso и проч., потому что для ALSE 1.7.+ корректнее собрать собственное зеркало центральных репозиториев с серверов Astra. И его уже либо таскать с собой, либо раздавать по сети...
Secundo, нужно (чтобы не потерять действие сертификата) накатить последнее куммулятивное обновление (на текущий момент 1.7.5, но с ним есть нюансы, расписанные в вики, поэтому лучше пока 1.7.4 и 1.7.4.uu1 друг за другом). А такие обновления лучше всего устанавливаются на чистую ОС 1.7.0...
Tertio, убивать на корню ненужные (зачастую) сервисы resolvconf (и без него конфигурация /etc/resolv.conf прекрасно отрабатывает), avahi и т.п. Блокировать IPv6 (если не нужен) напрямую через GRUB, а не sysctl.conf. Настраивать сеть через /etc/network/interfaces (если меняться не будет), либо через богомерзкий NetworkManager, если это мобильное АРМ, например...
Quatro, отлаживать состояние системы до проверки работоспособности всех возможных сервисов, служб и задач. И только потом натягивать какие-либо СЗИ, предварительно читая документацию и ограничения по ним...
Last, юзать в ALSE контроли устройств, сетевые экраны, защиту от сетевых угроз средствами KESL - это, imho, только для случая инфраструктуры KSC с раздачей централизованных политик. А в такой ситуации как правило уже знаю, что, как, куда и зачем...

ЗЫ Все это при условии, что познание долгий дорог начинается с первый шаг, ага. У матерых импортозаместителей уже давно свои пути, понимания и т.п. - к ним все вышесказанное не относится...

 

[Ckadi]

to oko
to Primo: ALSE c ISO 1.7.0 ставил, доступны ISO 1.6, 1.7.0, 1.7.2.
to Tertio: Попробую без resolvconfig. Намерений блокировать IPv6 не имел и не предпринимал шагов к этому.
В /etc/network/interfaces прописал IP, gw, dns-nameservers, затем выполнил ifconfig eth0 up - линк поднялся, пинг по IP пошел, DNS клиент как будто не заработал. И я решил, что его надо установить(+ /etc/resolv.conf по умолчанию является линком на /etc/resolvconf/...), resolvconfig упоминался в статье Wiki про настройку сети вторым абзацем (в 1м NetworkManager, которого предустановленным не нашел и не стал ставить), resolvconfig и установил. Возможно после редактирования /etc/network/interfaces стоило networking.service перезапустить или ребутнуть машину, чтобы без resolvconf DNS клиент заработал.
to Quatro: думал сначала сеть, KESL, агент, машину в домен для не автономного SNS, установка SNS (исполнение нормативки), а потом уже перенос сервисов. Документацию к СЗИ не читал, но чую придется.
to Last: KESL с политиками KSC и планируется.

 

[oko]

to Ckadi
Если у вас все "по ФСТЭК", то...
Согласно Приказу 55 за 2018 г. любое сертифицированное СЗИ (в случае ALSE, ОС со встроенными СЗИ согласно профилю ИТ.ОС...) считается соответствующим своему сертификату соответствия при условии обеспечения техподдержки производителя (тут спорный вопрос, нужно ли ее оплачивать эксплуатанту, но это больше о взаимодействии эксплуатант-производитель). А также при условии исправления актуальных уязвимостей, особенно зарегистрированных в БДУ. В противном случае, при любых контрольных испытаниях установленное СЗИ (ОС) только очень тупой представитель регулятора или очень тупой/жадный лицензиат назовет "достаточным"...
Актуальное обновление безопасности, устраняющее актуальные уязвимости для ALSE 1.7.x - это 1.7.5. Но с ним есть проблема с расширенным репозиторием (см. официальную wiki). К этому и было мое предыдущее сообщение. Если пакеты из расширенного репозитория вы не используете, то для полного соответствия обязаны обновиться именно до этой версии...
Официальный репозитории Астры с маркировкой "base" и "main" (один вложен в другой) проходят инспекционный (сертификационный) контроль и являются абсолютно легитимным источником пакетов и обновлений при эксплуатации ОС на любых защищаемых объектах в рамках действующего сертификата. Разумеется, копию репозитория нужно "сливать" к себе доверенными методами с составлением соответствующих актов и снятием контрольных сумм (если все серьезно, а не "чисто для галочки")...
Не существует раздельных репозиториев для 1.7.0, 1.7.2 и т.д. Только если кто-то в свое время сделал локальное зеркало и "заморозил" его для своих нужд...

Теперь на правах модуля экстрасенсорики:

• если у вас релиз ASLE "Орел" (т.е. "Базовый") + SN LSP - у вас явно не ГТ-система (потому что Орел и SN LSP требования ГТ не закрывают);
• если у вас ALSE "Орел" + SN LSP + "требование сверху" - у вас ГИС/МИС/ЗОКИИ с существующим Центром управления, которым рулят те, кто выставляют "требования";
• если все так, то можно юзать хоть ALSE, хоть ALCE, хоть OpenSUSE, хоть Debian, раз уж "поверх" применяются СЗИ НСД с достаточным сертификатом тем более в централизованном режиме;
• запрет SUSE, Debian и т.п. может вытекать только из криво трактованной задачи импортозамещения, но к вопросам ИБ и, например, последующей аттестации ОИ, на котором это все будет эксплуатироваться, это не имеет никакого отношения;
• и вообще, юзать сертифицированную ОС без встроенных в нее большинства средств защиты (коим и является релиз "Орел") + СЗИ НСД (тем более SN LSP) == бессмысленная трата сил и средств. Куда корректнее строить защищенный домен на базе защищенных ОС с полным набором встроенных средств защиты (о чем и ФСТЭК говорит, особенно в вопросах КИИ).

ЗЫ Возможно, у вас ситуация "МО РФ + часть нормативки ФСТЭК", тогда согласен, могут быть любые перегибы. Но при равных прочих с недавнего времени МО-требования == ФСТЭК-требования, если нет отдельного приказа/решения/ТЗ. И да, все сказанное выше про репозитории ALSE всецело отвечают и МО-линии (потому что подписаны ключом МО РФ). И сомневаюсь, что до сих пор только 1.7.2 прошло инспекционный контроль по МО-линии (ибо ему уже больше года с момента релиза)...

ЗЗЫ И главное в моем сообщении про resolvconf и avahi - это avahi. Легко подтверждается анализом выложенного вами журнала и беглым гуглом по проблемам с этим сервисом. Возможно, его тащит за собой KESL, но не уверен, потому что под Debian 11 + KESL (та же версия) такого не наблюдается. Так что начните с него, а остальное приложится...

 

[Ckadi]

Отключил службы avahi, перезагрузился - ситуация не изменилась. Удалил resolvconf, avahi*, перезагрузился - нет эффекта.

Установил 1.7.0 без GUI с нуля, репозитории не подключал, пакетов никаких не ставил. Внес информацию об eth0 в /etc/network/interfaces (как в 1 посте), перезагрузился. Сети нет, линка нет. Линк появляется после ifconfig eth0 down, ifconfig eth0 up или после ifdown eth0, ifup eth0.

 

[ALSE_User]

Network manager активен?

 

[Ckadi]

Network manager отсутствует + выполнял sudo systemctl --now mask NetworkManager

 

[oko]

to Ckadi
Как вариант в /etc/network/interfaces вместо опции ethX auto использовать ethX allow-hotplug (с перезагрузкой). Понятное дело, что auto должно стартовать интерфейс вне зависимости от, но иногда (особенно в случае кривого сажания сетевой карты на PCI, и речь даже не о дискретной сетевой карте)...
Нечто подобное смутно припоминаю на практике. Проверьте через ethtool параметры автосогласования интерфейса (с коммутатором). Модуль экстрасенсорики подсказывает, что пропавший физический линк - это проблема физического, а не софтового уровня. ifup/ifdown по-хорошему ее решить не могут (т.е. в вашей ситуации проблема не чисто аппаратная), но если вся соль в задержке/сбое автосогласования сети, то именно эти вызовы позволяют интерфейсу принять рабочее состояние...
И покажите, пожалуйста, статус службы (sudo systemctl status) networking до и после ifup. А то есть подозрение...

 

[Ckadi]

to oko
Пробовал - не помогло.

Решил использовать виртуальную машину (хост с esxi 5.5) - описанной в топике проблемы нет. Предполагаю, что вопрос был в поддержке железа.
p.s. Пробовал установить ALSE 1.6 на этот системник - инсталлятор "не видел" сетевую карту.