Краткое содержание

  • Официальная программа мероприятия 2018 года называла Tim Martiushev из MTik.pro докладчиком с обзором сомнительных конфигураций RouterOS, реальных схем операторов, их компромиссов и альтернатив. Прилагаемая презентация приписывает ему конкретные рекомендации, оставляя неназванные сети из примеров анонимными. [1] [2]
  • Его рекомендации связывают обычную работу с конфигурацией и непрерывность: использовать интерфейс как шлюз только там, где тип канала это допускает, ограничивать управляющий доступ, отключать неиспользуемые службы и интерфейсы, защищать IPv4 и IPv6, а также поддерживать актуальность программного обеспечения и исправлений безопасности. [2] [5]
  • Презентация также рассматривает имена, комментарии, границы виртуальных локальных сетей, уровни туннелей и расчёты максимального размера передаваемого блока как элементы операционного контроля. Эти детали помогают следующему оператору понять систему и не допустить, чтобы скрытые накладные расходы или неоднозначные пути превратились в предотвратимые сбои. [2] [6]
  • Независимый отчёт NAG назвал Мартюшева сертифицированным инструктором завершённого трёхдневного курса по RouterOS в декабре 2018 года. Он подтверждает конкретный факт обучения настройке и устранению неисправностей, но не позднейшие результаты участников в промышленных сетях. [3]
  • Обоснованный вывод не в том, что один инструктор гарантировал надёжность сетей. Он в том, что непрерывность работы оператора зависит от проверяемых действующих конфигураций, явных границ и записей, которыми другой человек может воспользоваться в стрессовой ситуации. Документированный анализ и обучение Мартюшева служат персональной основой этого вывода.

Вклад начинается с выбора конфигурации, а не с должности

Наиболее ясные сведения о Мартюшеве связаны с конкретной деятельностью. Официальная программа встречи пользователей MikroTik в сентябре 2018 года называет Tim Martiushev из MTik.pro и описывает презентацию, в которой рассматривались сомнительные конфигурации RouterOS. Её предметом были не общая биография и не рекламный доклад о лидерстве. В программе сказано, что презентация должна была рассмотреть реальные схемы, используемые операторами и сервисами, оценить их преимущества и недостатки и обсудить альтернативы. [1]

Официально размещённая презентация раскрывает техническое содержание этого описания. В ней назван Martiushev Timofei и приведены примеры и рекомендации, касающиеся шлюзов, доступа к маршрутизаторам, включённых служб, межсетевых экранов IPv4 и IPv6, обновлений программного обеспечения, имён интерфейсов, туннелей, виртуальных локальных сетей и максимального размера передаваемого блока. [2] Это на вид небольшие решения с последствиями для всей системы, потому что они определяют, как движется трафик, как администраторы получают доступ к оборудованию и как понимаются сбои.

Такие сведения о человеке надёжнее, чем одно лишь название должности. Должность говорит, где человек находится в организации. Датированная техническая презентация показывает, что именно этот человек решил проанализировать и какие рекомендации он представил аудитории операторов. У этих сведений есть и пределы. Презентация не называет все сети, стоящие за примерами, и не доказывает, что Мартюшев лично проектировал, внедрял или сопровождал эти сети.

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

Эта граница улучшает и техническое обсуждение. Когда цель — непрерывность, важный вопрос не в том, можно ли назвать докладчика влиятельным, а в том, может ли оператор проверить действующую конфигурацию, понять путь и внести контролируемое изменение. Запись о презентации даёт документальную основу для такого вопроса.

Шлюз — это решение о пути, а не декоративное поле

Для неспециалиста шлюз — это следующее место, куда устройство отправляет трафик, предназначенный для другой сети. Часто он задаётся адресом. Презентация Мартюшева предостерегает от того, чтобы считать имя интерфейса общей заменой адреса следующего перехода. В ней сказано, что интерфейс годится как шлюз только на каналах «точка — точка», и в качестве примеров приведены PPPoE и IPIP. [2]

Это различие важно, потому что у канала «точка — точка» есть только один другой конец. В общей сети интерфейс может достигать нескольких соседей. Если указать только интерфейс, маршрутизатору может потребоваться дополнительное разрешение адресов, или его поведение начнёт зависеть от деталей, которые оператор не задал. Конфигурация может выглядеть краткой, но скрывать фактическую связь со следующим переходом.

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

Вывод не в том, что любой шлюз на основе интерфейса неверен. Важно указанное Мартюшевым исключение: каналы «точка — точка» позволяют назвать интерфейс достаточным описанием следующего перехода. [2] Более общий операционный принцип — приводить форму конфигурации в соответствие с реальной топологией канала, а не использовать более короткое выражение без размышлений о его значении.

Для делового читателя это вопрос контроля. Решение о маршрутизации, которое нельзя быстро объяснить, увеличивает время восстановления и зависимость от первоначального автора. Точный шлюз делает путь проще для проверки, передачи и тестирования. Он превращает строку конфигурации в подотчётное операционное решение.

Управляющий доступ — часть границы услуги

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

Презентация Мартюшева рекомендует ограничивать доступ к маршрутизатору, отключать неиспользуемые службы, выбирать более строгие параметры Secure Shell и рассматривать обновления программного обеспечения и исправления безопасности как постоянную операционную работу. Она также рекомендует отключать неиспользуемые интерфейсы. [2] Действующая документация по безопасности RouterOS отдельно описывает многие из тех же мер: межсетевой экран для доступа из глобальной сети, ограничение служб управления, поддержание системы в актуальном состоянии и отключение неиспользуемых функций. [5]

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

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

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

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

Двухстековая работа требует двух решений по безопасности

Сети, поддерживающие одновременно Internet Protocol version 4 и Internet Protocol version 6, называют двухстековыми. Два семейства адресов могут сосуществовать на одном оборудовании, но их трафик обрабатывается разными правилами и состояниями. Межсетевой экран, применённый только к IPv4, не защищает IPv6 автоматически.

Презентация Мартюшева прямо требует защиты межсетевым экраном и маршрутизатора, и подключённых клиентов как в IPv4, так и в IPv6. [2] Действующая документация по безопасности также разделяет соответствующие меры защиты и предупреждает операторов о необходимости контролировать доступ из ненадёжных сетей. [5] Практический вывод прост: включение второго семейства адресов создаёт второй путь, который нужно проверить.

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

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

Статья не может утверждать, что Мартюшев внедрил двухстековые межсетевые экраны у какого-либо названного оператора. Доказательства подтверждают рекомендацию в его публичной презентации. [2] Это различие не снижает её операционной значимости. Если научить операторов задавать вопрос о втором стеке, можно не допустить, чтобы проверка конфигурации объявила успех, изучив лишь половину достижимой системы.

Для руководителей такой контроль должен выражаться в доказательствах, а не в галочке. Зафиксируйте ожидаемые службы IPv4 и IPv6, проверьте обе из доверенных и недоверенных расположений и сохраните результат с датой. «Двухстековый режим включён» описывает возможность. Отдельные данные о маршрутах и межсетевых экранах показывают, работает ли эта возможность безопасно.

Имена и комментарии — инфраструктура непрерывности

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

Эта рекомендация отвечает на распространённый риск непрерывности: знание, хранящееся только в памяти человека, который построил систему. Метка «uplink2» может быть ясна автору и бессмысленна для коллеги полгода спустя. Комментарий может быть столь же слабым, если фиксирует намерение без контекста о канале, узле, службе или изменении, необходимого для проверки.

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

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

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

Поэтому задокументированная рекомендация Мартюшева — больше, чем вопрос аккуратности. [2] Она помещает человеческую читаемость внутрь операционного проектирования. Непрерывность зависит от оборудования, но также от того, могут ли люди понять это оборудование достаточно быстро, чтобы действовать.

Уровни туннелей могут умножать скрытые зависимости

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

Примеры в презентации Мартюшева включают сочетания с PPTP, Ethernet over IP, Layer 2 Tunneling Protocol, мобильными каналами и частной адресацией. [2] Презентация использует такие схемы для обсуждения сомнительных решений и альтернатив. Доказательства не называют операторов, стоящих за примерами, поэтому они должны оставаться анонимными техническими иллюстрациями, а не приписанными внедрениями.

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

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

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

Вклад Мартюшева здесь — сам факт того, что компромиссы стали обсуждаемыми. [1] [2] Решение может быть технически возможным и всё же трудным в эксплуатации. Альтернативу следует оценивать не только по тому, движутся ли пакеты в день внедрения, но и по тому, сможет ли другой оператор диагностировать её при сбое.

Разделение VLAN делает границу наблюдаемой

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

Главная мысль — разделение назначений. Клиентские данные и управление оборудованием могут проходить через одни и те же коммутаторы или каналы, но не должны становиться неразличимыми. Управляющий VLAN даёт операторам определённое место для применения правил доступа, контроля достижимости и рассуждений о сбоях, не рассматривая весь трафик как один недифференцированный поток.

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

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

И здесь статья не должна преувеличивать сведения о человеке. Презентация подтверждает рекомендацию Мартюшева. [2] Она не показывает, что он внедрил управляющий VLAN в какой-либо названной промышленной сети или что это изменение улучшило доступность. Более широкий вывод в том, что явные границы трафика упрощают поиск сбоев и зон ответственности.

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

MTU — это обещание услуги, выраженное в байтах

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

В презентации Мартюшева сказано, что накладные расходы туннеля нужно рассчитывать, а значение MTU, предоставляемое клиенту, — указывать. [2] Действующая документация RouterOS отдельно объясняет соотношения между Internet Protocol, вторым уровнем, Multiprotocol Label Switching, VLAN и размерами туннелируемых кадров, включая ограничения оборудования, которые могут вызывать фрагментацию или потери. [6]

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

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

Слово «рассчитать» важно. Угадывание привычного числа или копирование значения с другого канала может скрыть заголовки, добавляемые фактическим стеком туннелей. Расчёт должен следовать реальному пути, а тест — подтверждать результат. Если служба меняется, обещанный MTU и его доказательства нужно пересматривать заново.

Источники не связывают Мартюшева с каким-либо измеренным клиентским результатом. [2] [6] Они подтверждают рекомендацию и техническую причину за ней. Этого достаточно, чтобы показать, почему дисциплина конфигурации — часть операционной честности: провайдер должен описывать службу, которую действующий путь действительно может предоставить, а не размер, который он хотел бы поддерживать.

Обучение — задокументированное действие, но не показатель надёжности

В декабре 2018 года NAG опубликовал независимый отчёт о трёхдневном курсе MikroTik Certified Network Associate. В нём Timofey Martiushev назван сертифицированным инструктором и описано обучение настройке RouterOS и операционному устранению неисправностей. В отчёте сказано, что все участники завершили курс и получили сертификаты, и приведены слова Мартюшева о группе с разным уровнем подготовки и использовании практических лабораторных работ. [3]

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

Заявленный результат завершения должен оставаться в своих рамках. Завершение курса — это образовательный результат. Он не показывает, что каждый участник позже правильно настроил промышленную сеть, сократил простой или улучшил доступность. Сертификаты не заменяют операционных доказательств из сетей, в которых участники впоследствии работали.

Это различие сохраняет полезность сведений об обучении. Отчёт может подтвердить утверждение, что Мартюшев обучал настройке и устранению неисправностей и что курс завершился так, как описано. [3] Он не может подтвердить утверждение, что он вызвал последующие улучшения надёжности, которые не измерялись.

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

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

Действующая конфигурация — это уровень реальности

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

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

Презентация Мартюшева ценна как датированный пример изучения этого уровня реальности. [2] В ней спрашивается, соответствуют ли распространённые схемы своему операционному назначению, и предлагаются альтернативы. Статья не должна превращать этот анализ в утверждение, что он управлял неназванными сетями. Его значимость в методе: проверить конфигурацию, показать компромисс и сделать задуманную границу явной.

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

Такой подход меняет и то, как руководители оценивают надёжность. Обещания устойчивости недостаточно. Нужно спрашивать доказательства обычного пути, пути отказа, пути административного доступа и теста восстановления. Нужно также спрашивать, кто сможет объяснить конфигурацию, если её первоначальный автор отсутствует.

Вытекающий принцип скромен: непрерывность строится дисциплинированными, передаваемыми операционными решениями. Её не дают должность, сертификат или имя в реестре. Документированный анализ и обучение Мартюшева служат доказательством вклада в эту дисциплину, тогда как фактический результат в любой сети остаётся ответственностью её операторов и текущего состояния.

Что операторам следует проверить дальше

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

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

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

Составьте карту стеков туннелей от внутренней службы до внешнего транспорта. Зафиксируйте конечные точки, ответственных, базовые каналы, мониторинг и запасной вариант. Рассчитайте накладные расходы на каждом уровне инкапсуляции и укажите фактически предоставляемый через службу MTU. Тестируйте с размерами трафика, которые выявляют фрагментацию или поведение «чёрной дыры».

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

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

Наконец, проверьте передачу знаний. Попросите второго оператора объяснить путь и восстановить контролируемый сбой, используя текущие записи. Результат покажет, распределено ли знание или остаётся сосредоточенным у одного человека. Это и есть вопрос непрерывности, стоящий за многими задокументированными рекомендациями Мартюшева по конфигурации.

Источники

  1. Программа MikroTik User Meeting, называющая Tim Martiushev и презентацию по RouterOS
  2. Официально размещённая презентация Мартюшева о конфигурационных решениях RouterOS
  3. Отчёт NAG о декабрьском курсе по RouterOS 2018 года
  4. Запись участника RIPE для ru.mtikpro
  5. Действующие рекомендации RouterOS по защите маршрутизатора
  6. Действующая документация RouterOS о максимальном размере передаваемого блока