Комментарии 50
Извините, но на мой взгляд статья вообще не соответствует названию.
Из неё я не увидел ни одного преимущества перед продуктами Cisco кроме сомнительной «системы централизованного управления политикой ИТ-безопасности», которая к слову есть и у тойже Сisco
Из неё я не увидел ни одного преимущества перед продуктами Cisco кроме сомнительной «системы централизованного управления политикой ИТ-безопасности», которая к слову есть и у тойже Сisco
Верю, что по скриншотам силу централизованной системы управления не оценить — но сравните хотя бы легкость множественной настройки (и подстройки, если понадобится) VPN-туннелей с филиалами (например, если их 50-100 штук).
Ну а чтобы убедиться окончательно, тут только живое тестирование подойдет.
Ну а чтобы убедиться окончательно, тут только живое тестирование подойдет.
Я верю в силу централизованной системы управления, верю.
Но я не могу считать это преимуществом продуктов CheckPoint пере cisco\juniper.
Наверное и надо было статью так назвать — «Обзор централизованной системы управления CheckPoint»
Но я не могу считать это преимуществом продуктов CheckPoint пере cisco\juniper.
Наверное и надо было статью так назвать — «Обзор централизованной системы управления CheckPoint»
сравните хотя бы легкость множественной настройки (и подстройки, если понадобится) VPN-туннелей с филиалами (например, если их 50-100 штук).
50-100 штук — это еще мало. А когда много сотен? Или много тысяч? Динамический роутинг гоняет? В многоуровневую иерархию выстраивается? Динамические туннели строит? А резервирование либо размазывание нагрузки по нескольким каналам? А MPLS (кому-то надо)?
В маленьких филиалах stateful файрвол не требуется. Зато нужен чертовски гибкий VPN, плюс куча других мелких сервисов вроде той же телефонии на случай аварии на всех каналах.
Как писал выше, есть реально работающий коммерческий проект на 3000 шлюзов с VPN, большего числа шлюзов Check Point пока не встречал. По моим данным, производительные системы также используются во всех телекомах Украины, но тут, увы, без технических подробностей.
Поддержка динамической маршрутизации, route-based VPN, конечно же, имеется. Отказоустойчивость по схеме Active-Standby или Load Sharing на выбор.
Ни в коем случае не хотел приуменьшить сильных сторон той же Cisco — а у нее все компоненты в единую красивую схему выстраиваются, дополняя друг друга. В этом плане Check Point лишь периметральный шлюз с достойными возможностями, но никак не замена всей сетевой инфраструктуры.
Поддержка динамической маршрутизации, route-based VPN, конечно же, имеется. Отказоустойчивость по схеме Active-Standby или Load Sharing на выбор.
Ни в коем случае не хотел приуменьшить сильных сторон той же Cisco — а у нее все компоненты в единую красивую схему выстраиваются, дополняя друг друга. В этом плане Check Point лишь периметральный шлюз с достойными возможностями, но никак не замена всей сетевой инфраструктуры.
есть реально работающий коммерческий проект на 3000 шлюзов с VPN
Банкоматы. Это никакой не site-to-site, скорее remote access. Там легко обойтись и софтовым клиентом.
Поддержка динамической маршрутизации, route-based VPN, конечно же, имеется.
Какие протоколы?
В этом плане Check Point лишь периметральный шлюз с достойными возможностями, но никак не замена всей сетевой инфраструктуры.
Конечно не замена :) Но я хочу понять, каковы его преимущества в качестве периметрового шлюза.
В банкоматах можно использовать Remote Access (софтовые клиенты или железо в этом режиме), но у нас 2 крупных банка решили именно по схеме site-to-site строить на железе.
Поддерживаются динамические протоколы маршрутизации BGP4, OSPF, RIPv1, RIPv2.
Для настройки Routing-based VPN используются VTI (VPN Tunnel Interfaces).
Поддерживаются динамические протоколы маршрутизации BGP4, OSPF, RIPv1, RIPv2.
Для настройки Routing-based VPN используются VTI (VPN Tunnel Interfaces).
у нас 2 крупных банка решили именно по схеме site-to-site строить на железе.
Только это все равно не имеет ничего общего с подключением филиала.
Поддерживаются динамические протоколы маршрутизации BGP4, OSPF, RIPv1, RIPv2.
Для настройки Routing-based VPN используются VTI (VPN Tunnel Interfaces).
Вот, уже другое дело.
QoS? Динамические туннели между филиалами по мере надобности без предварительной настройки (есть у Juniper, Cisco, HP и кучи других вендоров)? Крупная современная филиальная сеть на сотни/тысячи узлов немыслима без возможности прямой передачи данных между двумя удаленными узлами.
Ну и: есть ли заказчики, разворачивающие хотя бы средних размеров (от 100 хостов) филиальную сеть (не банкоматы) на решениях Check Point? Можно без имен, полагаюсь на вашу честность :)
QoS присутствует. Можно указывать гарантированную полосу под правило, максимальный лимит, количество подключений. А кроме того, есть относительный «вес» — трафик по конкретному правилу не получит более чем Вес/сумма_всех_весов.
Возможно ограничение полосы пропускания в правилах по конкретным приложениям, типам приложений (YouTube, streaming, torrents и прочее). Кстати, полноту базы Application Control можно оценить онлайн appwiki.checkpoint.com/appwikisdb/public.htm
Про динамические туннели точно ответить не могу, не имел опыта настройки. Но если речь о возможности передачи трафика из Филиала_А в Филиал_Б минуя центр — такая возможность в руках админа: если VPN-community настроено как Star Topology и в его свойствах прописана возможность соединения филиалов напрямую (на четвертом скриншоте справа последний пункт).
Касательно крупных заказчиков: практически все крупные проекты автоматом строятся на сетеобразующем оборудовании (читай Cisco в нашей стране), вопросы безопасности поднимаются позже архитектурных и интегратор прицепом к основному проекту предлагает и безопасность на том же вендоре.
Из конкретики Check Point могу упомянуть сеть магазинов бытовой техники MegaMax — там 40 филиалов использовали UTM-1 Edge, а в центре использовался кластер старших устройств.
Возможно ограничение полосы пропускания в правилах по конкретным приложениям, типам приложений (YouTube, streaming, torrents и прочее). Кстати, полноту базы Application Control можно оценить онлайн appwiki.checkpoint.com/appwikisdb/public.htm
Про динамические туннели точно ответить не могу, не имел опыта настройки. Но если речь о возможности передачи трафика из Филиала_А в Филиал_Б минуя центр — такая возможность в руках админа: если VPN-community настроено как Star Topology и в его свойствах прописана возможность соединения филиалов напрямую (на четвертом скриншоте справа последний пункт).
Касательно крупных заказчиков: практически все крупные проекты автоматом строятся на сетеобразующем оборудовании (читай Cisco в нашей стране), вопросы безопасности поднимаются позже архитектурных и интегратор прицепом к основному проекту предлагает и безопасность на том же вендоре.
Из конкретики Check Point могу упомянуть сеть магазинов бытовой техники MegaMax — там 40 филиалов использовали UTM-1 Edge, а в центре использовался кластер старших устройств.
Админю сейчас сетку, во всех филиалах Чекпойнты.
Суммарно около 70 объектов (пополам эджи и сплаты).
Так что заказчики есть. :)
Суммарно около 70 объектов (пополам эджи и сплаты).
Так что заказчики есть. :)
НЛО прилетело и опубликовало эту надпись здесь
Пожалуй, продублирую еще раз полезные ссылки — если необходима будет более подробная техническая информация, в том числе и для траблшутинга:
1. Официальные сайты checkpoint.com, rus.checkpoint.com (ну и само собой, внутренний портал supportcenter.checkpoint.com)
2. Официальный форум www.cpshared.com
3. Неофициальный форум www.cpug.org
4. Блоги умных людей blog.lachmann.org, checkpoint-master-architect.blogspot.com, fireverse.org, chkp.delai.biz, blog.nigmatullin.net, checkpointdblink.blogspot.com, expert-mode.blogspot.ca, blog.lachmann.org
А вот эта педантичный немецкий интегратор по полочкам разложил актуальные версии ПО и общую информацию www.fw-1.de/aerasec/
1. Официальные сайты checkpoint.com, rus.checkpoint.com (ну и само собой, внутренний портал supportcenter.checkpoint.com)
2. Официальный форум www.cpshared.com
3. Неофициальный форум www.cpug.org
4. Блоги умных людей blog.lachmann.org, checkpoint-master-architect.blogspot.com, fireverse.org, chkp.delai.biz, blog.nigmatullin.net, checkpointdblink.blogspot.com, expert-mode.blogspot.ca, blog.lachmann.org
А вот эта педантичный немецкий интегратор по полочкам разложил актуальные версии ПО и общую информацию www.fw-1.de/aerasec/
Настройка site-to-site VPN туннелей
А что за VPN? Есть куча реализаций. Надеюсь, не голый IPSec?
Здесь речь идет о site-to-site VPN по IPsec между шлюзами Check Point. Сервер управления содержит встроенный центр сертификатов и выдает сертификаты шлюзам при инициализации SIC-соединения. В дальнейшем он следит за валидностью этих сертификатов и обновляет их по истечению срока действия. Уточните, пожалуйста, что Вы имеете ввиду под «голым IPsec»?
Есть большой кусок функционала по удаленному доступу пользователей (Mobile Access Blade). Там возможны различные сценарии доступа пользователей:
1. Через предустановленный IPsec клиент.
2. Безклиентский доступ — трансляция в HTTPS портал интерфейсов почты, файл-шары, интранет портала и части приложений.
3. Скачивание и доступ к сети через легкий SSL-клиент.
4. Доступ к офисным ресурсам с криптозащищенной флешки Check Point GO (Global Office, производства SunDisk) и предустановленным VPN-клиентом в окружение.
5. Доступ с мобильных устройств Android, iOS.
Есть большой кусок функционала по удаленному доступу пользователей (Mobile Access Blade). Там возможны различные сценарии доступа пользователей:
1. Через предустановленный IPsec клиент.
2. Безклиентский доступ — трансляция в HTTPS портал интерфейсов почты, файл-шары, интранет портала и части приложений.
3. Скачивание и доступ к сети через легкий SSL-клиент.
4. Доступ к офисным ресурсам с криптозащищенной флешки Check Point GO (Global Office, производства SunDisk) и предустановленным VPN-клиентом в окружение.
5. Доступ с мобильных устройств Android, iOS.
Уточните, пожалуйста, что Вы имеете ввиду под «голым IPsec»?
Именно то, что у вас задействовано. Без инкапсуляции L2. В случае крупных внедрений противопоказано.
Там возможны различные сценарии доступа пользователей
Это уже remote access, другой разговор. И да, все давно поддерживают SSL VPN и много чего другого.
Если я правильно понял, под голым IPsec имеется в виду реализация согласно RFC, тот же IKE (rfc 2409), ESP (RFC 4303) и т.д. CheckPoint и та же Cisco в своих реализация VPN на основе IPsec не изменяет заголовки 2-го уровня, максимум, что может быть изменено так это IP заголовок, но и то, только в тунельном режиме (tunnel mode).
Касательно удаленного доступа (remote access) Вы правы, многие крупные вендоры поддерживают данный тип VPN (имеется в виду SSL VPN, как через клиента, так и без). Тут особых уникальностей нет, разве что уже упомянутые выше флешки GO с аппаратным шифрованием и предустановленным защищенным рабочим местом и VPN-клиентом, ну и управление всеми клиентами и политиками, опять-таки, с единой консоли централизованного управления.
Касательно удаленного доступа (remote access) Вы правы, многие крупные вендоры поддерживают данный тип VPN (имеется в виду SSL VPN, как через клиента, так и без). Тут особых уникальностей нет, разве что уже упомянутые выше флешки GO с аппаратным шифрованием и предустановленным защищенным рабочим местом и VPN-клиентом, ну и управление всеми клиентами и политиками, опять-таки, с единой консоли централизованного управления.
Под «голый VPN» я понимаю именно отсутствие туннелирования поверх него. И следующая из этого неработоспособность работающих поверх L2 протоколов.
Лучшая реализация client access VPN — это Direct Access. Но есть у нее один недостаток — чрезмерная костыльность настройки серверной стороны в IPv4 сети.
Лучшая реализация client access VPN — это Direct Access. Но есть у нее один недостаток — чрезмерная костыльность настройки серверной стороны в IPv4 сети.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Все на нем работает
Поверх него работают только две вещи: статическая маршрутизация (разумеется, это недопустимо) либо GRE/IPIP/какое-либо-еще туннелирование.
НЛО прилетело и опубликовало эту надпись здесь
под «все» я имел в виду что обычно site-to-site и ra так или инвче на ipsec.
Не изображайте из себя идиота. Я выше раз 5 объяснил, что имеется в виду. Причем очень даже понятно объяснил.
НЛО прилетело и опубликовало эту надпись здесь
Чесслово, задолбало одно и то же копипастить. Возникло ощущение, что вы надо мной просто издеваетесь. Если нет, то приношу свои извинения и поясняю.
L2TP традиционно используется либо для создания L2 транспорта внутри своей сети (без IPSec), либо для создания L2 транспорта поверх интернета (тогда он шифруется IPSec, ибо сам по себе L2TP никакой защиты не имеет).
Голый IPSec не инкапсулирует L2, потому по нему не может работать ни один протокол маршрутизации кроме разве что BGP. Делать статические маршруты и руками прописывать crypto ACL — вообще не вариант.
Все нормальные реализации site-to-site VPN задействуют GRE инкапсуляцию поверх IPSec — захватывая и L2 заголовки. При этом полноценно работает динамический роутинг, с массой дополнительных плюшек в виде удобства настройки (цискина реализация DMVPN позволяет копипастить вообще без изменений одну и ту же конфигурацию crypto на все узлы) и скорости перемаршрутизации при аварии.
L2TP традиционно используется либо для создания L2 транспорта внутри своей сети (без IPSec), либо для создания L2 транспорта поверх интернета (тогда он шифруется IPSec, ибо сам по себе L2TP никакой защиты не имеет).
Голый IPSec не инкапсулирует L2, потому по нему не может работать ни один протокол маршрутизации кроме разве что BGP. Делать статические маршруты и руками прописывать crypto ACL — вообще не вариант.
Все нормальные реализации site-to-site VPN задействуют GRE инкапсуляцию поверх IPSec — захватывая и L2 заголовки. При этом полноценно работает динамический роутинг, с массой дополнительных плюшек в виде удобства настройки (цискина реализация DMVPN позволяет копипастить вообще без изменений одну и ту же конфигурацию crypto на все узлы) и скорости перемаршрутизации при аварии.
НЛО прилетело и опубликовало эту надпись здесь
Мне же нативный ipsec кажется вполне общепринятым решением, с учетом разумеется упомянутых ограничений.
Невозможность мультикаста. Множество специфичных для каждого бранча телодвижений. Невозможность динамических туннелей.
Мне же нативный ipsec кажется вполне общепринятым решением
Все давно с него толпами валят.
L2 vpn думаю нужен бывает не так часто как L3
Внутри компании? Да, реже.
(если развернут MPLS — целесообразность L2TP близка к нулю, ибо есть ATOM/VPLS)
роутинг там еще круче становится, особенно когда dual hub — dual dmvpn, это может быть вешалка почище full mesh и crypto acl…
Почему? Он прекрасно скейлится до (десятков) тысяч споков.
mpls тут красивее всего, но это нужен оператор большой и правильный
Сливать внутренние маршруты оператору — то, чего лучше всеми силами избегать. Так что все равно по IPVPN сетям строят свои оверлеи, тот же DMVPN к примеру. Можно даже без шифрования. А GETVPN очень мало кто использует.
Насчет чекпоинта — он избавляет от необходимости спаривать сайты для full mesh, он делает это сам. На циско получившийся конфиг был бы слишком пугающим
DMVPN? Да ну? Вообще-то там на хабах размер конфигурации совершенно одинаков что с одним споком, что с тысячью. На каждом споке конфигурация крипто одинакова (под копирку, если получать туннельные адреса с хаба) и тоже не зависит от наличия/отсутствия других споков. Туннели между споками поднимаются сами по мере надобности — фактически, вот он, full mesh. С конфигом под 20 строк на каждом из узлов. Без необходимости что-либо менять в течение многих лет.
Вообще не в L2 проблема то динамических протоколов, а в отсутствии поддержки мультикаста в классическом ipsec
Любая динамика умеет стыковаться юникастом. Но — на расстоянии одного хопа. За исключением BGP. Это не проблема, а разумное поведение.
Вообще говоря, L2 через сайты таскать без острой необходимости то скорее плохо, чем хорошо
Конечно. Но L2 соединяет лишь два узла-маршрутизатора. Проблем не вижу, кроме оверхеда (несущественно). Понятно, что объединять по L2 VLANы — чертовски паршивая затея, но никто этого и не предлагает.
«Сливать внутренние маршруты оператору — то, чего лучше всеми силами избегать. Так что все равно по IPVPN сетям строят свои оверлеи, тот же DMVPN к примеру. Можно даже без шифрования. А GETVPN очень мало кто использует.»
Можете чуть развернутей? Жили одно время через операторский IP VPN со своим DMVPN, но большие люди навязали BGP с операторами. Аргументы не принимались. Сейчас стали все чаще проявляться траблы, когда BGP-сессия жива, нехт хоп доступен, анонсы получаем/отправляем но дальше на каналах затык. Как результат — нет переключения на резернвые каналы (другой оператор).
Можете чуть развернутей? Жили одно время через операторский IP VPN со своим DMVPN, но большие люди навязали BGP с операторами. Аргументы не принимались. Сейчас стали все чаще проявляться траблы, когда BGP-сессия жива, нехт хоп доступен, анонсы получаем/отправляем но дальше на каналах затык. Как результат — нет переключения на резернвые каналы (другой оператор).
Так IP VPN тоже вполне может подразумевать BGP с операторами. Например, единичные сети все-таки стоит анонсировать им — для прямого доступа к внешним физическим интерфейсам.
А на самом деле с DMVPN отслеживать живость каналов проще простого. EIGRP (или OSPF) нашел нейбора? Канал жив. NHRP видит пира? Канал жив.
И да, проблема «анонс есть, коннективити нема» встречается куда чаще, чем хотелось бы.
А на самом деле с DMVPN отслеживать живость каналов проще простого. EIGRP (или OSPF) нашел нейбора? Канал жив. NHRP видит пира? Канал жив.
И да, проблема «анонс есть, коннективити нема» встречается куда чаще, чем хотелось бы.
Да это понятно, что интерконнекты можно через какую-то динамику. Имел в виду, что полностью внутренняя адресация им отдается. Все резервирование на этом построено.
Ну тогда можно настроить IP SLA на центральных железках, и на него завязать статический маршрут. Но это не поможет обратному трафику, от спока к хабу.
«большие люди навязали BGP с операторами. Аргументы не принимались.» — ну так все-таки кто мешает продолжать обмениваться частью маршрутов по BGP, но при этом поверх IPVPN поднять DMVPN без шифрования? Можно извернуться и сделать так, что пока хоть один mGRE туннель до спока жив — общение с центром будет идти только по нему, иначе — прямой маршрутизацией.
«большие люди навязали BGP с операторами. Аргументы не принимались.» — ну так все-таки кто мешает продолжать обмениваться частью маршрутов по BGP, но при этом поверх IPVPN поднять DMVPN без шифрования? Можно извернуться и сделать так, что пока хоть один mGRE туннель до спока жив — общение с центром будет идти только по нему, иначе — прямой маршрутизацией.
Тут распределенная сеть филиальная. Всех я к этому не сподвигну (да и сам нарушу политику по большому счету). Если другие регионы все мои сети за счет BGP не увидят — я с ними потеряю связь. Можно замутить DMVPN с прочувствовавшими проблему — но как-то тогда это не красиво, не единое, лоскутное решение. А связь нужна со всеми.
DMVPN был крайне удобен еще тем, что ему без разницы — IP VPN или IPSEC/GRE через инет, запас прочности был больше.
Вопрос от человека с CP работающего:
А вот интересно, как у вас настроен и работает VPN от этих 3000 банкоматов, учитывая, что CheckPoint умеет обрабатывать VPN трафик только одним процессорным ядром, что дает очень жесткий потолок производительности, и кластеризация тут никак не помогает?
А вот интересно, как у вас настроен и работает VPN от этих 3000 банкоматов, учитывая, что CheckPoint умеет обрабатывать VPN трафик только одним процессорным ядром, что дает очень жесткий потолок производительности, и кластеризация тут никак не помогает?
Увы, подробностей не знаю. О проблемах с производительностью у данного заказчика не слышал, а вот о чем они реально переживают и планируют использовать — так это Multiple Entry Point, т.е. использование нескольких кластеров для возможности терминирования VPN-туннелей от банкоматов, если один из кластеров откажет или откажет канал(ы) связи с ним.
Включите CoreXL.
CoreXL leverages the power of Intel's multi-core CPU's to dramatically accelerate the traffic throughput rate of the VPN-1 Power.
Правда, тогда без Route-based VPN.
CoreXL leverages the power of Intel's multi-core CPU's to dramatically accelerate the traffic throughput rate of the VPN-1 Power.
Правда, тогда без Route-based VPN.
работаю в крупном провайдере. за несколько лет стооооооолько наелись этих чекпоинтов по всей европе, жуть просто. возвращаемся на циско. один апдейт чего стоит: процедура на 2 листа А4, в 70-80% случаев не идет и есть куча фиксов для этой процедуры, часто приходится восстанавливать с нуля…
еще из минусов:
1) гуи медленный, консоли нет почти
2) ВПН хитро суммаризует роуты, с циской дружит плохо. приходится лезть в глубокий файлик и там править
3) была проблема с одним приложением, решилось установкой ВЫКЛЮЧЕННОГО IPS. чекпоинт даже предоставил лицензию, признав баг
4). Дебаг неинформативен, часто приходится запускать кернел дебаг, который на загруженной машине часто ее роняет
5). на SC часто повисает основной процесс, приходится рестартовать файерволл
я могу долго продолжать…
еще из минусов:
1) гуи медленный, консоли нет почти
2) ВПН хитро суммаризует роуты, с циской дружит плохо. приходится лезть в глубокий файлик и там править
3) была проблема с одним приложением, решилось установкой ВЫКЛЮЧЕННОГО IPS. чекпоинт даже предоставил лицензию, признав баг
4). Дебаг неинформативен, часто приходится запускать кернел дебаг, который на загруженной машине часто ее роняет
5). на SC часто повисает основной процесс, приходится рестартовать файерволл
я могу долго продолжать…
Если уж переходить с CP, то на Stonesoft. На мой взгляд, лучшие на данный момент. Тот же апдейт выполняется на горячую в пару кликов без остановки сервисов, например. Вообще архитектурно хорошо продуманная штука.
А не приходилось ли с PaloAlto работать? Мощную рекламную кампанию устроили (даже в YouTube баннеры были), да и технологически purpose-built hardware и однопроходная фильтрация заманчиво звучат.
Приходилось, и курсы заканчивал по ним. Краткий вердикт — не фонтан. Начиная с интерфейса (адовый ад), заканчивая производительностью в реальном мире, а не на буклетах. Да что там говорить, даже заявленная функция Active-Active Cluster во-первых настраивается через часа два, так еще и суммарная производительность двух (а это максимум, что оно умеет) железок в Active-Active кластере меньше, чем одной такой же железки, если она стоит сама по себе отдельно. У них почти все функции сделаны «чтобы было что написать в рекламном буклете», а не для реальной жизни. Единственное преимущество — у них есть сигнатуры для специфичных протоколов SCADA-сетей. Но это уже довольно узкая ниша.
НЛО прилетело и опубликовало эту надпись здесь
Представителем вендора не являюсь, но закинуть им такой вопрос смогу. Уточните, в чем заключается проблема?
НЛО прилетело и опубликовало эту надпись здесь
В базе знаний SecureKnowledge есть SK32664:
Our gateways only support NAT-T when all of the following is true:
The gateway has to be a «dynamic» gateway without a fixed IP
Certificate-based authentication must be used for the VPN community
The remote end has to initiate the NAT-T request
Планируется ли изменение ситуации к лучшему — затрудняюсь сказать.
Our gateways only support NAT-T when all of the following is true:
The gateway has to be a «dynamic» gateway without a fixed IP
Certificate-based authentication must be used for the VPN community
The remote end has to initiate the NAT-T request
Планируется ли изменение ситуации к лучшему — затрудняюсь сказать.
Спасибо за отзывы и корректировки, название статьи решил сменить на более нейтральное, т.к. глубокого сравнения между существующими аналогами у конкурентов не проводилось, да и идея статьи родилась как расширенный комментарий, а не как целенаправленное исследование.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Преимущества централизованной безопасности Check Point перед сетевыми конкурентами