Итак, с недавнего времени заблокирован очередной сервис (который Discord). Довольно скоро в комментах под публикациями недовольных пользователей появились адепты VPN (ничего не имею против этой технологии и технологий-спутников, т.к. в рамках рабочего процесса активно это всё используется) с насмешкой в адрес обычных юзеров, далёких от ИТ.
Так вот, любая страна подключается к глобальной сети через трансграничные каналы связи (Internet backbone). Нагрузка на эти каналы всегда высчитывается и мониторится с целью избежать (через замену оборудования) чрезмерной утилизации канала/каналов связи.
VPN всегда увеличивает объем трафика в момент времени за счёт шифрования.
Нужно ли говорить, что будет, если в какой-то момент времени пропускной способности каналов (нагрузка увеличится, кстати, не только на трансграничные каналы, но и на внутренние) не хватит для обработки трафика? (гугол в помощь)
На полноценную публикацию для Хабра не тянет, но описанный ниже момент для кого-то может оказаться полезным.
Итак, краткие исходные данные таковы (полный расклад в статье по ссылке выше): 1) 2 видеокарты: "Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]" (используется для ВМ с Win10) и "Park [Mobility Radeon HD 5430]" (используется для хост-системы);
2) "Radeon HD 5430" (старенькая видюха) воткнута в первый pcie-слот материнки, а "Lexa PRO" (железяка поновее) - во второй (кстати, в статье этот момент описан не совсем корректно);
Видеокарту "Radeon HD 5430" понадобилось перекинуть с хост-системы на ВМ, а "Lexa PRO" - на хост-систему.
Чтобы это сделать корректно, необходимо карту из первого слота явно отвязать от хост-системы. Небольшая сложность тут в том, что она идёт первой в очереди на инициализацию хост-системой.
Очерёдность инициализации выводится посредством получения содержимого procfs-файла "/proc/fb" (fb = framebuffer). Выглядеть это будет, например, так
0 efifb vga 1 amdgpudrmfb
Чтобы не использовать видеокарту в хост-системе для передачи в ВМ в статье было задействовано как изменение параметров ядра (grub) при загрузке, так и механизм подгружаемых модулей ядра (modprobe), т.е.
1) добавление параметров «intel_iommu=on iommu=on rd.driver.pre=pci-stub pci-stub.ids=1002:67ff,1002:aae0» (идентификаторы "Lexa PRO") в grub и 2) «blacklist amdgpu» и «options pci-stub ids=1002:699f,1002:aae0» -> «/etc/modprobe.d/local.conf».
Т.к. первой хост-система (ОС AlmaLinux8) захватывала "Radeon HD 5430", то проблем в рамках описанной в статье конфигурации не было.
В случае же, когда есть необходимость в ВМ прокинуть карту, находящуюся в более приоритетном слоте, в параметры загрузки мы должны прописать явный запрет на захват целевой карты. Делается это посредством добавления подстроки "video=efifb:off" (подстрока "efifb" взята из вывода "cat /proc/fb") в параметр GRUB_CMDLINE_LINUX ("/etc/default/grub") и последущим исполнением команд grub2-mkconfig + dracut + перезагрузка.
Итого, файл "/etc/default/grub" должен иметь примерно такой вид.
1002:68e1,1002:aa68 - идентификаторы "Radeon HD 5430"
В файле «/etc/modprobe.d/local.conf» также меняем идентификаторы, но не отправляем в блэк-лист драйвер "radeon", т.к. оный необходим ОС при загрузке. В общем, файл "local.conf" должен содержать только одну строку - "options pci-stub ids=1002:68e1,1002:aa68".
Занимательный (и чуточку возмутительный) факт обнаружил при скриптовании правил фаервола (который firewalld) в ОС вида "RHEL8" (AlmaLinux8, Rocky Linux 8, etc).
По какой-то неведомой причине добавление элементов ipset-а в сам ipset через файл работает "через раз" (в общем, как повезёт), если использовать "--add-entries-from-file" в рамках bash-скрипта.
Провёл не менее десятка попыток запуска скрипта. Корректно ряд подобных команд (для 4-х ipset-ов) отработал только единожды, хотя ввод вручную отрабатывает стабильно (не проверял более трёх раз).
При этом, если в рамках скрипта использовать в цикле команду на добавление единичного элемента в конкретный ipset ("--add-entry"), то проблем не возникает.
В общем, в скриптах лучше задействовать добавление элементов в ipset при помощи "--add-entry".
Максимальное время нахождения элемента ipset-а во временном наборе (элемента ipset-а в ipset-е, где при создании был указан параметр "timeout" > 0) - чуть менее 25 дней, а если точнее, то 24 дня, 20 часов, 31 минута и 23 секунды или 2147483 секунд.
Поэтому, если, например, требуется предоставить некий доступ через firewalld на довольно долгий срок, но всё-таки не на постоянной основе, то требуется решение, отличное от временных элементов ipset-ов.
Столкнулся недавно с весьма интересной неполадкой. Начало классическое - после отправки в reboot домашний сервер (от сервера тут только одно название, т.к. системный блок собран из того, что возможно купить на потребительском рынке) операционная система (AlmaLinux8) хоть кое-как загрузилась (через раз), но дальше приглашения ввести логин/пароль дело не пошло. При вводе корректных авторизационных данных - возврат к приглашению.
Симптомы весьма таки знакомые. Подозрение пало на жесткий диск, поэтому решил вытащить из запаса новенький диск и восстановить ОС из заранее подготовленного бэкапа посредством замечательной команды "dd if=/dev/SOURCE_DISK_DEVICE of=/dev/TARGET_DISK_DEVICE bs=4096" (где *_DISK_DEVICE - символьное обозначение дискового устройства), дабы не тратить время на новую установку. И финт ушами не сработал, хотя я точно помнил, что после покупки диск был мной проверен через "smartctl -t short /dev/DISK_DEVICE", о чем сообщала надпись с датой проверки на монтажной ленте, наклеенной сразу после тестирования.
Проблема разрешилась довольно быстро. Помогла замена data-кабеля SATA III (хорошо, что запас разного рода "шнурков" всегда под рукой), что спасло старенький HDD от физических повреждений и отправки в утиль. Читал, конечно, когда-то про то, что некачественный data-кабель может привести к потере данных, но на практике столкнулся впервые (видимо, до этого везло с data-кабелями). Дело в том, что наилучший вариант - это кабель с позолоченными контактами (стандарт де-факто), но в данном случае, видимо, это было не так (думал, кстати, просто протереть контакты, но у современных sata-шлейфов они хорошо так утоплены в пластик), что привело к постепенному окислению соединений (позолота или иное покрытие от этого защищает).
P.S. Наглядный пример вывода команды "dmesg", демонстрирующий в том числе описанную выше проблему.
Довольно забавный момент связан с "механикой" добавления/удаления ipset-элементов в ipset-списки с ограниченным временем жизни (параметр "timeout") элементов. Для краткости будем называть такие списки "temporary_ipset".
2. Добавим в ipset пару элементов "firewall-cmd --ipset=temporary_ipset --add-entry="11.12.13.14"" "firewall-cmd --ipset=temporary_ipset --add-entry="14.13.12.11"".
3. Попытаемся посмотреть список элементов через firewall-cmd "firewall-cmd --permanent --info-ipset=temporary_ipset".
Список элементов мы не увидим, т.к. для просмотра элементов с ограниченным временем жизни необходимо использовать команду "ipset list temporary_ipset". Так вот не очень удобно реализовано (RHEL8).
4. Удаление элемента из temporary_ipset тоже с подвохом. Команда "firewall-cmd --permanent --ipset=temporary_ipset --remove-entry="11.12.13.14"" не даст нужного результата и выдаст ответ вида "Error: IPSET_WITH_TIMEOUT".
Для удаления из temporary_ipset необходимо воспользоваться утилитой ipset - "ipset del temporary_ipset 11.12.13.14".
5. Добавление элемента в temporary_ipset с таймаутом, отличным от заданного, невозможно через firewall-cmd. В этом случае нам также поможет утилита ipset - "ipset add temporary_ipset 11.12.13.144 timeout 500".
6. Чтобы переопределить таймаут уже добавленного элемента, необходимо через утилиту ipset сначала удалить элемента, а после добавить с иным таймаутом.
(Небольшой бонус) 7. Удаление temporary_ipset осуществляется уже стандартно - "firewall-cmd --permanent --delete-ipset=temporary_ipset". После необходимо выполнить "firewall-cmd --reload". Если этого не сделать, то ipset всё ещё будет доступен через одноимённую утилиту.
Если по каким-то причинам нежелательно проводить reload, то исполняем команду удаления ipset-а (выше), а после удаляем temporary_ipset посредством команды "ipset destroy temporary_ipset".
Как оказалось, в код ansible-хелпера "conf_int_ipv4_via_network_scripts" закралась ошибочка, не позволявшая корректно настраивать сетевые интерфейсы (или их сочетание), связанные с VLAN-ами.
Ошибка устранена. === Если вы пользуетесь репозиторием и нашли баг, то send email to vladimir.chursin000@yandex.ru
