​​Выгрузка и загрузка информационных баз 1С при помощи автономного сервера

При работе с информационными базами 1С:Предприятие очень часто возникают задачи выгрузить или загрузить дамп информационной базы или ее конфигурацию.

Обычно для этих целей используют Конфигуратор, но данный способ имеет ряд неудобств. Во-первых, Конфигуратор требует монопольного доступа к базе, т.е. выгнать из нее всех пользователей.

Во-вторых, могут быть сложности с серверами на Linux без графического окружения, а так как Конфигуратор работает в режиме толстого клиента, то все данные в полном объеме гоняются по сети, таким образом удаленная работа на медленном канале становится попросту невозможной.

От всех этих недостатков вас может избавить Автономный сервер, который поставляется вместе с платформой и располагается в папке bin под именем ibcmd.

В нашем примере будет использована платформа Linux, но все команды будут прекрасно работать и в среде Windows.

Будем считать, что мы находимся в директории с бинарными файлами платформы, а дампы и конфигурации будем располагать в домашнем каталоге текущего пользователя.

Начнем с самого популярного, выгрузки базы в DT-файл:

./ibcmd infobase dump --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.dt

В целом параметры в комментариях не нуждаются, только уточним что в опции --db-server мы указываем имя или адрес сервера базы данных и указываем учетные данные также от сервера СУБД.

Параметр --dbms указывает тип СУБД, можете использовать PostgreSQL или MSSQLServer.

Выгонять пользователей для этого не нужно, но помните, что в возможно нарушение целостности создаваемого файла выгрузки.

Кроме того, следует помнить, что выгрузка информационной базы не является средством резервного копирования!

Загрузить базу можно обратной командой:

./ibcmd infobase restore --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.dt

Для выгрузки конфигурации используйте:

./ibcmd infobase config save --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.cf

Для загрузки:

./ibcmd infobase config load --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1 ~/1cv8.cf

После загрузки конфигурации вам потребуется обновить конфигурацию базы данных:

./ibcmd infobase config apply --db-server=srv-db --dbms=PostgreSQL --db-name=base-01 --db-user=postgres --db-pwd=Pa$$word_1

В данной заметке мы коснулись лишь малой части того, что умеет автономный сервер, показав лишь самые часто используемые операции. Больше информации можно найти в официальной документации.

​​Критерии выбора оборудования для сервера 1С:Предприятие. Процессор. Часть 1

Тема выбора оборудования для сервера 1С актуальная и с завидной регулярностью поднимается в комментариях. Поэтому сегодня уделим внимание этому вопросу.

Критически важным для 1С является частота центрального процессора, это связано с рядом особенностей, которые мы опишем ниже, точнее даже не с частотой как таковой, а с однопоточной производительностью, которая с частотой обычно связана напрямую.

Ниже 3 ГГц можете даже не смотреть, а лучше выбрать процессоры с частотой около 4 ГГц. Что касается буста, то смотрите не на абсолютные цифры частоты, а на то, как именно процессор ее поднимает, будет лучше если он одновременно может поднимать частоту сразу всех ядер.

А теперь перейдем к тому, почему это так. В админской среде гуляет мнение, что это от того, что 1С написана левой задней лапой и не умеет в многопоточность. Однако это не так. Умеет и там, где может – распараллеливается. Но может это сделать не везде.

Начнем с того, что 1С – это учетная система, предназначенная для ведения бухгалтерского и управленческого учета, расчета заработной платы и многих других специфичных вещей.

И именно предметная часть накладывает серьезные ограничения, бухгалтерия – не математика. Мы не можем взять и вычислить параллельно части выражения и потом произвести окончательные вычисления, в учете многие операции можно делать строго последовательно, в один поток.

Чтобы было проще понять, о чем мы говорим приведем очень сильно упрощенный пример: вы не можете продать товар пока не оприходуете его на склад, а оприходовать не сможете раньше, чем внесете оплату поставщику.

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

Поэтому всегда исходим из того, что у нас будут преимущественно однопоточные нагрузки и наш сервер должен уметь быстро и эффективно их обрабатывать.

Индикатором комфортной работы отдельного пользователя служит широко известный тест Гилева. Который проверяет способность оборудования переварить именно однопоточную нагрузку.
С увеличением количества пользователей растет количество однопоточных задач и нам нужно уметь быстро их обработать. Поэтому следующим вопросом становятся ядра и потоки. Их должно быть достаточно.

Точно сказать сколько надо ядер и потоков на N-пользователей обычно не представляется возможным, так как даже на одной и той же конфигурации, с одним и тем же количеством пользователей и даже с примерно одинаковым размером базы характер нагрузки может быть принципиально разный.

Так у производства и торговли будут совершенно разные сценарии. Да и торговля бывает разной, у кого-то есть партионный учет, у кого-то ВЭД и курсовые разницы и т.д. и т.п.

Где-то нагрузка будет равномерной, где-то пиковой. Все зависит от параметров учета конкретного предприятия. И советовать какое-то железо только исходя из конфигурации и количества пользователей – дело неблагодарное, кому-то ее будет с избытком, а кому-то сразу станет тесно.

Учитывая, что редко кто делает крупные внедрения 1С с нуля, всегда имеется возможность оценить характер нагрузки на уже имеющемся оборудовании и прикинуть необходимый вектор развития.

А также выяснить характер нагрузки и установить кто именно ее производит. Например, мы сталкивались с тем, что сильные пиковые нагрузки производила база ЗуП (Зарплата и управление персоналом), в которой работало три человека. В таких сценариях имеет смысл выносить подобные нагрузки на отдельные экземпляры Сервер-МИНИ.

Объем заметки не позволяет охватить все аспекты, поэтому на сегодня закончим. А в следующей заметке поговорим о менее очевидных вещах: рабочих процессах и веб-клиентах.

​​Критерии выбора оборудования для сервера 1С:Предприятие. Процессор. Часть 2

Во вчерашней заметке мы разобрали общие вопросы производительности сервера 1С в разрезе процессора, сегодня продолжим углубляться в специфику.

Рабочие процессы (rphost) – основная рабочая лошадка, которая выполняет серверный код и обслуживает пользовательские соединения. В целом рабочий процесс умеет эффективно использовать ядра процессора, но есть некоторые тонкости.

Официальная документация гласит:

…при работе на многопроцессорных системах, в зависимости от характера нагрузки, может наблюдаться неравномерная загрузка процессоров/ядер. В некоторых случаях может оказаться загружена только какая-то часть доступных ядер CPU, при этом другая часть будет простаивать. В таких случаях рекомендуется использовать лимит числа соединений на рабочий процесс…

Фактические рекомендации сводятся к тому, чтобы равномерно распределить рассчитанный максимум соединений на доступные ядра процессора, а если нагрузка будет продолжать оставаться неравномерной, то уменьшать этот лимит.

Проще говоря – количество рабочих процессов рекомендовано выставлять по количеству ядер.

Но тут беда пришла откуда не ждали, после разделения платформы на ПРОФ и КОРП. Теперь у пользователей ПРОФ нет возможности настраивать рабочие процессы, единственное доступное значение 8 ИБ на процесс и 256 соединений. Также платформа ПРОФ не может использовать более 12 процессорных ядер.

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

Отсюда проистекает также и схема масштабирования. Если ваши масштабы не предполагают переход на КОРП, а на одном сервере всем становится тесно, то лучший вариант – это увеличение количества серверов 1С.

Где-то ряд нагрузки можно вынести на Сервер-МИНИ, а где-то имеет смысл приобрести еще одну лицензию. При этом аппаратно можно продолжать использовать уже имеющееся оборудование.

Скажем тот же AMD Ryzen 9 5900X имеет 12 ядер / 24 потока, что позволит полноценно развернуть на нем две виртуальных машины или контейнера с серверами 1С по 12 ядер в каждом.

Следующий тонкий момент – веб-сервера, которые сейчас очень популярны как средство доступа к 1С.

Здесь мы начнем с вопроса: где исполняется код 1С? А исполняется он в двух местах: на клиенте и на сервере. На клиенте обрабатываются данные форм приложения и данные введенные в них пользователем.

Данные ИБ можно получить только на сервере и обычно там же происходит их обработка. Количество кода, исполняемого клиентом и сервером, различается от характера нагрузки.

При установке на компьютер пользователя платформы в режиме тонкого клиента, работающего через веб-сервер весь код клиентского приложения исполняется прямо на нем. А веб-сервер служит простым ретранслятором запросов к серверу, практически не оказывая нагрузки.

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

Следующий момент – это сеансы и соединения. Сеанс определяет активного пользователя информационной базы и поток управления этого пользователя. Среди доступных видов сеансов есть тонкий клиент и веб-клиент.

Соединение является средством доступа сеансов серверу 1С:Предприятия» и не отождествляется с активным пользователем. Среди видов соединений есть также тонкий клиент и модуль расширения веб-сервера.

О чем это говорит? О том что в режиме работы через веб-сервер количество сеансов не равно количеству соединений. И чаще всего множество входящих сеансов к веб-серверу обслуживаются единственным соединением к серверу 1С:Предприятия.

Поэтому здесь разумно будет распараллеливать нагрузку путем увеличения количества веб-серверов, а также обязательно разносить веб-сервера обслуживающие пользователей и используемые для веб-сервисов.

​​И снова про самосбор серверов

Тема самосбора является сильно дискуссионной, у каждой стороны имеются свои веские аргументы и доводы. И каждая позиция имеет свое право на существование.

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

Увы, это не так, а раз в год даже палка стреляет. В чем мы недавно в очередной раз убедились.

На февраль с одним из заказчиков у нас планировался некий проект, но все неожиданно стало на паузу по причине отсутствия свободных вычислительных мощностей.

Но начнем по порядку. Еще осенью администратор этого заказчика купил новый сервер, купил под самосбор на популярной платформе Supermicro. Докупил процессор, память, диски, поднял Proxmox и стал потихоньку переносить нагрузку.

Некоторое время все было хорошо, но, когда используемый объем памяти начал превышать 2/3 установленного – сервер начал падать в kernel panic и все данные показывали на память.

Так и есть, планка в 4-м слоту не проходит тестирование, отнесли в гарантию – тестирование прошла, все ОК. Перекинул планку в другой сервер – проходит. Вернул на место – тоже проходит.

Ну что тут можно сказать? Списали все на плохие контакты. Недели две все работало, потом снова сервер стал падать. Теперь перестала проходить тестирование планка в третьем слоте.

Протестировал в другом сервере – все проходит. Решил поменять память с другим сервером. «Косячная» память там завелась и стала работать без проблем, а та, что нормально работала в другом – снова стала чудить подобным образом.

Опытным путем было установлено, что чудеса начинаются только когда заняты все 4 слота, любые три работали нормально.

Ну тут или материнка или процессор, ни то, ни другое заменить на заведомо исправное возможности не было. Поэтому поехал данный самосбор в гарантию. Что разбивает главный аргумент самосборщиков, что в случае чего можно сдать комплектующие по частям.

Сначала поехал по гарантии к своему дистрибьютору процессор, там не стали заморачиваться и сразу его поменяли.

Вроде бы успех, все работает. Сервер вернулся, но ровно на неделю. Потом снова поехал в гарантию, теперь уже к дистрибьюторам Supermicro. Откуда вернулся с заключением, что с платформой все ОК, но так как память использована не из листа совместимости, то никакой ответственности за такое поведение они не несут.

В общем купили память из листа совместимости, хотя сделать это было не просто, потому как 80% перечисленного там в продаже отсутствует полностью.

И снова получили нестабильную работу. Платформа снова уехала к дистрибьюторам Supermicro и заменили ее только почти спустя месяц. Пока, вроде бы полет нормальный. Хотя времени прошло не так и много.

В итоге куча потраченного впустую времени и купленный дополнительный набор памяти, которую теперь не особо понятно куда девать.

Собственно, об этом мы и писали в цикле по гарантии: все сложные ситуации и дорогие комплектующие будут долго ездить по сервисам, так как никто на себя ответственность за них не возьмет. И свободных, заведомо исправных компонентов серверного класса в сервисах тоже нет.

Покупка сервера в сборе, именно как сервера по документам, не страхует от брака, но позволяет хотя бы уменьшить головняк и затраты, так как память в таком случае производитель или сборщик менял бы за свой счет.

Ну и самому покупателю проще – не работает и все! А там можно и ненадлежащее качество подтянуть через ст. 475 ГК РФ. В общем как бы и все тоже самое, но позиция покупателя, даже юридического лица, становится юридически гораздо более выгодной.

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

​​Критерии выбора оборудования для сервера 1С:Предприятие. Память

Вопрос выбора оперативной памяти, а точнее ее необходимого количества является с одной стороны простым, а с другой – весьма и весьма сложным и ниже мы поговорим почему.

Мы не будем касаться аппаратной части выбора, здесь все ясно – чем быстрее память, тем лучше, но такого критического значения как у процессора ее частота не имеет.

Основными критериями выбора будет являться ее необходимый объем.

На первый взгляд тут все просто, оцениваем выделение памяти на один работающий сеанс, умножаем на число сеансов. Посмотреть эти значения можно в оснастке Администрирование серверов 1С:Предприятие

Идем в сеансы и смотрим следующие показатели, естественно – в разгар работы: Память (5 мин) и Память (всего). Первый показатель покажет максимальное значение потребления памяти за пять минут, второй – за сеанс.

Исходя из них вычисляем среднее и пиковое потребление. Опять-таки, дать каких-то конкретных советов и цифр тут сложно, следует исходить из реальной обстановки.

А в реальной обстановке у нас могут иметь место утечки памяти, чаще всего по вине неоптимальных доработок или внешних отчетов, но могут «течь» и вполне типовые конфигурации.

Второе зло – зависшие сеансы. Стандартный срок жизни такого сеанса – 86400 секунд или 24 часа, что достаточно много. Возникать такие сеансы могут по многим причинам, чаще всего от мобильных пользователей, которые несколько раз переподключаются к серверу перемещаясь от одного провайдера к другому.

В результате реальное количество сеансов может оказаться существенно выше запланированного и привести к неприятным последствиям.

Дело в том, что у платформы уровня ПРОФ отобрали все инструменты управления памятью и заставили довольствоваться параметрами по умолчанию.

Первый из них: Временно допустимый объем памяти процессов, по умолчанию он равен 70% памяти сервера. Второй связанный с ним параметр: Интервал превышения допустимого объема памяти процессов, равный 300 секундам (5 минут).

Таким образом, если рабочие процессы на протяжении более 5 минут будут потреблять более 70% памяти сервера, то начнется их мягкий перезапуск. Для этого создается новый рабочий процесс и ему передаются текущие сеансы, после того как все сеансы будут переданы – процесс будет завершен.

При этом начнет сервер с самого «жирного» рабочего процесса. А теперь снова вспомним об ограничениях платформы ПРОФ и придем к пониманию, что самым «жирным» будет один единственный доступный нам рабочий процесс со всеми сеансами.

При этом далеко не факт, что нам хватит свободной памяти перенести все сеансы. Потому как 70% - это довольно высокий лимит, да и сама ОС тоже нуждается в памяти.

После чего на сцену выходит еще один параметр: Критический объем памяти процессов – по умолчанию 95% объема памяти сервера.

По его достижении рабочие процессы начинают завершаться аварийно, начиная с самого «жирного», а в нашем случае – единственного.

Но это мы рассмотрели сферический сервер в вакууме, в реальности администраторы очень любят совмещать все на одном узле. И сервер 1С, и сервер СУБД, и веб-сервер. Во многом это обусловлено многочисленными материалами типа «Сервер 1С с нуля за пять минут», где просто дается последовательность действий и не поясняется архитектура системы.

А как мы могли видеть все показатели завязаны именно на объем памяти сервера и не поддаются изменению.

В таком случае сервер просто никогда не доберется до перезапуска процессов, а просто тупо уйдет в аут исчерпав всю доступную оперативную память.

Выводы здесь довольно очевидны: обязательно выносим сервер 1С:Предприятие в отдельную виртуалку или контейнер и не совмещаем его с никакими другими ролями.

Рассчитываем потребности в памяти и накидываем сверху запас на зависшие сеансы и утечки памяти. А также принимаем меры по контролю сеансов и не забываем мониторить потребление памяти внутри системы с сервером 1С.

🟢 Протоколы OSPF и IS-IS: сходства и различия

 Получите ценные практические знания на бесплатном уроке от OTUS, где вы вместе с опытным экспертом:

1. Разберетесь в сходствах протоколов OSPF и IS-IS
2. Рассмотрите их различия
3. Настроите протоколы OSPF и IS-IS в сети на практике 

👉 Вебинар проведет Николай Колесов, профессионал с 18 летним опытом, эксперт ТАС вендора по решениям routing&switching и data center

Занятие пройдёт 7 марта в 20:00 мск и будет приурочено к старту курса «Network Engineer». Доступна рассрочка на обучение!

🔥 Пройдите короткий тест прямо сейчас, чтобы занять место на открытом уроке и получить запись: https://otus.pw/Rsll/

​​Там, где светлее

Буквально недавно мы поднимали вопрос диагностики и говорили о том, что это задача достаточно сложная, в которой нужен системный подход. Почитать об этом можно здесь: https://t.iss.one/interface31/2129

Но поведение многих наших коллег напоминает мужика из анекдота, который ищет часы не там, где потерял, а под фонарем, потому что там светлее.

Буквально сегодня столкнулся с тем, что в одном из каналов человек задает вопрос в стиле «Никто не сталкивался с такой ошибкой?» и прикладывает скриншот.

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

Когда у него поинтересовались, а что непонятного в ошибке, он снова начал о том, что «Никто не сталкивался?».

И только когда ему уже несколько раз сказали, что смотреть нужно на другой стороне, робко спросил: «А, так это на сайте?»

Квалификация и опыт у всех разные, это понятно. Но любой, подчеркну, любой специалист должен обладать начальными навыками диагностики. Самый первый и базовый принцип которой – смотри в логи!

Возможно, современных коллег разбаловала кажущаяся информационная доступность, когда проще всего попытаться загуглить ошибку и в большинстве типовых случаев получить результат.

Но шаг вправо, шаг влево и такой «специалист» становится беспомощным, так как даже не представляет, где и что ему посмотреть.

В былые времена, когда интернет был куда менее доступен и техническая его часть была представлена форумами такой фокус не прокатывал.

За дурные вопросы без конкретики твою тему могли просто снести, а тебя в довольно грубой форме послать читать документацию.

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

Очень часто, во время составления подобной темы на форуме проблема решалась, не сама собой, а именно благодаря тому, что пришлось-таки углубиться в логи, почитать, подумать.

В свое время чтение логов считалось занятием будничным, практически повседневным. Часто можно было услышать: «Сижу утром, пью кофе, читаю логи»

Действительно, когда-то давно, когда деревья были большие, а системы попроще чтение логов было практически единственным способом вовремя понять и устранить грядущие неисправности, не дожидаясь падения системы.

Сейчас все проще, системы мониторинга и сбора логов убрали с администраторов рутину, взяв ее на себя. Но, к сожалению, многие коллеги утратили в себе ценное умение читать и понимать логи.

Ведь лог – это не только сообщение об ошибке, это целое жизнеописание системы, по которому можно проследить что происходило до, во время, и после. И очень часто ключ к решению проблемы лежит именно там, во вроде бы обычных строках уровня «Информация».

Если провести аналогию, то инспектор ГИБДД приехав на место ДТП не зацикливается на факте происшествия и не спрашивает коллег, посылая фото: «Никто с таким не сталкивался?». А начинает методично восстанавливать события, предшествовавшие аварийной ситуации.

Ровно также должен действовать администратор, выясняя какие именно события предшествовали ошибке и каким образом они могли на ее возникновение повлиять. Это – нормальный инженерный подход.

А зацикливаться на самом факте ошибки и сразу пытаться искать ответ в поисковиках, форумах и телеграм-каналах – это как раз искать не там, где потерял, а там, где светлее.

​​Ошибка резидента (загадка на ночь)

Один мой коллега попал на днях в не очень приятную историю. А началось все с того, что он поменял провайдера на точке в другом населенном пункте.

Ехать туда не очень хотелось и он решил сделать все удаленно. У старого провайдера настройки получались по DHCP, новый выдавал по PPPoE.

Коллега заранее создал новый PPPoE-интерфейс, прописал для него маскарадинг и просто попросил сотрудника в удаленном офисе вынуть старый провод и вставить новый.

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

Примерный набор старых правил для понимания ситуации:

add action=accept chain=input connection-state=established,related in-interface=ether5
add action=drop chain=input connection-state=invalid in-interface=ether5
add action=accept chain=input in-interface=ether5 protocol=icmp
add action=accept chain=input dst-port=8291 in-interface=ether5 protocol=tcp
add action=drop chain=input in-interface=ether5

Посмотрев на них, он подумал, что вместо явного указания интерфейсов лучше использовать их список, он создал список, назвал его WAN, добавил туда нужные интерфейсы и стал менять правила. Работал через WinBox в графическом режиме.

И неожиданно потерял доступ. Подождал пока роутер откатит изменения назад (Safe Mode был включен), снова зашел и снова потерял доступ…

Планируемый набор новых правил:

add action=accept chain=input connection-state=established,related in-interface-list=WAN
add action=drop chain=input connection-state=invalid in-interface-list=WAN
add action=accept chain=input in-interface-list=WAN protocol=icmp
add action=accept chain=input dst-port=8291 in-interface-list=WAN protocol=tcp
add action=drop chain=input in-interface-list=WAN

Что мой коллега раз за разом делал не так?

Как углубить свои знания об архитектуре ПО всего за пару часов?

Прийти на бесплатный практический урок «Тактики работы с обнаруживаемостью в архитектуре программного обеспечения» от OTUS. На вебинаре разберём:
- что такое observability и почему это важно для бизнеса;
- как использовать инструменты мониторинга и алертинга для повышения обнаруживаемости;
- принципы и практические примеры использования USE и RED;
- четыре золотых сигнала, которые помогут оптимизировать работу с обнаруживаемостью.

Встречаемся 6 марта в 20:00 мск в рамках курса «Software Architect». Доступна рассрочка на обучение!

Пройдите короткий тест прямо сейчас, чтобы посетить бесплатный урок и получить запись: https://otus.pw/wcX1/?erid=LjN8KSvcn

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

​​Ошибка резидента (ответ на загадку)

Начнем с того, что результаты нас удивили и даже расстроили. Если отбросить 48% тех, кто зашел посмотреть ответы, то правильно ответили всего 19%.

При этом одними из самых популярных стали вообще абсурдные варианты (23% и 15%), которые были придуманы абсолютно из головы. Ну и предположения в комментариях совсем не порадовали.

Хотя ответ там лежит на поверхности, если, конечно, знать, как работает iptables, который находится у Mikrotik под капотом.

Такого критерия как список у iptables нет, и он воспринимает любой список как набор критериев, на основании которых он строит свои правила. Списки же используются для упрощения администрирования.

Фактически, если у нас в список WAN включены интерфейсы ether5 и pppoe-out1, то запись:

add action=drop chain=input in-interface-list=WAN

Будет эквивалентна:

add action=drop chain=input in-interface=ether5
add action=drop chain=input in-interface=pppoe-out1

Потому что список – это набор критериев, а несколько критериев всего объединяются через логическое И (или И-НЕ).

Как видим никакой магии в списках нет, и мы можем свободно сочетать списки с интерфейсами хоть в одном правиле, хоть в разных.

Если мы используем в одном правиле несколько списков, то результатом будут все возможные комбинации между ними.

Так если у нас есть еще один список LOCAL в который входят bridge1 и bridge2, то правило:

add action=drop chain=forward in-interface-list=WAN out-interface-list=LOCAL

Следует рассматривать как набор:

add action=drop chain=forward in-interface=bridge1 out-interface=ether5
add action=drop chain=forward in-interface=bridge1 out-interface=pppoe-out1
add action=drop chain=forward in-interface=bridge2 out-interface=ether5
add action=drop chain=forward in-interface=bridge2 out-interface=pppoe-out1

В данном случае это довольно удобно и очевидно, но так бывает не всегда и поэтому применяя в качестве критериев больше одного списка сразу проверяйте все возможные комбинации между ними во избежание недоразумений.

Но вернемся к нашим баранам, что произошло после того, как мы поменяли внешний интерфейс с ether5 на pppoe-out1? Мы получили полностью открытый брандмауэр, так как действие по умолчанию – ACCEPT и для интерфейса pppoe-out1 не было ни одного действующего правила.

В этом случае безусловно важен порядок действий. Правильный порядок – это изменять правила по порядку их прохождения пакетами, от первого к последнему. При этом желательно сначала изменить все разрешающие, убедиться, что по ним пошли счетчики и только после этого изменить или добавить запрещающие.

Если же начать менять правила в обратном порядке, то поменяв в

add action=drop chain=input in-interface=ether5

Интерфейс на лист вместо одного правила мы получим два:

add action=drop chain=input in-interface=ether5
add action=drop chain=input in-interface=pppoe-out1

А теперь вспоминаем, что никаких других правил для интерфейса pppoe-out1 у нас нет и мы только что благополучно отключили роутер от внешнего мира.

Поэтому правильный ответ может быть только один: неправильная очередность изменения правил.

​​Продолжаем игру в вопросы-ответы

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

Поэтому сегодня вариант попроще. Подобным образом нас любил спрашивать преподаватель по радиопередающим устройствам.

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

Итак, у нас имеется следующая конфигурация iptables:

*nat
:PREROUTING ACCEPT [55:2444]
:INPUT ACCEPT [55:2444]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.20.1.0/24 -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2330:3679979]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p udp -m udp --sport 123 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 34567 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 60200:60299 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

Вопрос №1: будет ли работать выход в интернет через WireGuard сервер, работающий на порту 34567?

Вопрос №2: что будет, если мы уберем первое правило в цепочке INPUT?

​​Ответы на вчерашние вопросы

В комментариях к предыдущей заметке нам посетовали, что мол мы не предоставили полной информации по вопросу, поэтому…

А нет никакого поэтому и быть не может. Любая диагностика и поиск неисправностей – это задача с неполной информацией. Обычно мы имеем некую систему и некое поведение системы, которое не является ожидаемым.

При этом у нас нет полной информации о том, что происходит, нам нужно опираясь на доступные данные максимально восстановить картину происходящего либо выдвинуть рабочую гипотезу, которую потом можно проверить.

И навык анализа в условиях недостатка информации является для администратора одним из важнейших. Тем более что были приведены варианты ответов (читай – гипотезы), которые следовало только проверить.

Ладно, вчера мы решили дать задачу попроще, с полной информацией, практически исчерпывающей, так как ответы фактически уже написаны.

Тем не менее на первый вопрос правильно ответила только половина читателей (из тех, кто отвечал), при этом треть из них ответила, скажем так, на «троечку». Почему?

Потому что ответ «Не будет» формально верный, но ниже есть более развернутый ответ, который наиболее точно характеризует поведение системы.

Давайте разберемся, порт 34567 в брандмауэре открыт и проблемы подключится к WireGuard не возникнет, подключение будет работать и узлы смогут обмениваться данными друг с другом.

Но вот выйти в интернет не получится, потому что цепочка FORWARD не содержит ни одного правила, разрешающего транзитный трафик.

Поэтому правильный ответ на первый вопрос: «Подключение будет, выход в интернет нет».

Со вторым вопросом все еще хуже, на него правильно ответили только 27% читателей, т.е. меньше трети.

Хотя он, в принципе, даже проще предыдущего. После того, как мы уберем первое правило, которое разрешает RELATED,ESTABLISHED – т.е. уже установленные соединения, у нас в цепочке INPUT останутся только правила для новых пакетов (NEW), все остальное будет запрещено последним REJECT.

Таким образом при попытке установить соединение у нас пройдет только первый пакет, а все остальные будут отброшены брандмауэром. Что сделает сервер недоступным с любого интерфейса, так как правила не содержат такого критерия.

А самое интересное в том, что правильный ответ со всеми необходимыми обоснованиями был дан еще вчера вечером в одном из первых комментариев.

В общем – выводы каждый должен сделать самостоятельно.

​​Забавная маршрутизация

Маршрутизация – пожалуй одна из самых сложных тем для начинающих, да и не только для них.

Вроде бы с одной стороны все просто, а с другой – не очень. Особенно если у нас есть пересекающиеся маршруты.

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

Задачка простая, но не совсем очевидная.

Итак, имеется следующая таблица маршрутизации:

192.168.0.0/24 – eth0
192.168.0.0/25 – eth1
192.168.0.0/26 – eth2
192.168.0.0/27 – eth3
192.168.0.0/28 – eth4

Будет ли такая таблица работать и какие сети находятся за каждым интерфейсом?

​​Забавная маршрутизация (ответы)

Есть такой принцип - Бритва Оккама, краткая суть которого в том, что не следует множить сущности без необходимости.

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

Итак, у нас есть таблица маршрутизации

192.168.0.0/24 – eth0
192.168.0.0/25 – eth1
192.168.0.0/26 – eth2
192.168.0.0/27 – eth3
192.168.0.0/28 – eth4

И несколько работающих сетей за каждым интерфейсом. Будет ли работать такая таблица? Да, почему нет. Вся тонкость именно в том, как она работает.

Начнем с того, что пакет не содержит такого поля как маска. Только адреса, в нашем случае имеет значение адрес назначения.

Далее вступает в дело таблица маршрутизации, в котором мы ищем наиболее подходящий маршрут для нашего пакета. Если к месту назначения ведут несколько маршрутов, то выбирается маршрут с маской, содержащий наименьшее количество узлов.

В нашем случае это будет 192.168.0.0/28, сеть /28 содержит 16 адресов, поэтому за eth4 у нас может находиться только 192.168.0.0/28.

Сеть /27 содержит уже 32 адреса, но в eth3 будут направлены только адреса не входящие в 192.168.0.0/28, т.е. следующие 16 адресов. Таким образом за eth3 у нас может быть только сеть 192.168.0.16/28.

Сеть 26 содержит уже 64 адреса, но 32 из них входят в уже указанные нами сети, поэтом за eth2 у нас находится сеть 192.168.0.32/27.

Аналогичным образом вычисляем и сети за eth1 – 192.168.0.64/26 и eth0 – 192.168.0.128/25.

Таким образом правильным является третий вариант ответа в вопросе. Количество ответивших правильно и сделать выводы каждый может самостоятельно.

Пятничное, вечернее. О жизни

Идем из гостей домой, решили зайти в магазин.

Навстречу семья, мама и папа впереди с пакетами, сзади топают девочка и мальчик, лет 9 и 12.

Не знаю о чем они там говорили, но при нашем приближении девочка отчитывала мальчика:

- Ты неправильно говоришь! Люди - это афганцы, а афганка - это конопля...

Жена призналась мне, что до этого она не знала, что афганка - это конопля.

Вот такие детки в клетке...