Перейти к содержанию

Рекомендуемые сообщения

Опубликовано

Добрый день!

Подскажите, можно ли сделать связность от ксц до кесов только по tcp? В обратную сторону не интересует.

В документации не нашел информации, но мало ли...

Опубликовано

Здравствуйте, а какой кейс вы тем самым пытаетесь решить? 

Опубликовано

 

15 часов назад, mike 1 сказал:

Здравствуйте, а какой кейс вы тем самым пытаетесь решить? 

По требованиям проекта получается так, что от ксц к кесам должен идти только тсп трафик.

Опубликовано (изменено)
6 часов назад, Nova Blossom сказал:

По требованиям проекта получается так, что от ксц к кесам должен идти только тсп трафик.

тут вам наверное нужно сначала разобраться во взаимодействии KSC и KES

 

1. По умолчанию - всегда организуется канал общение по TCP 13000 с использованием сертификата (возможно UDP 14000 но только если вы это сами укажите вручную)

2. Инициатором соединения выступает агент администрирования установленный на клиентском устройстве с KES, который как раз обращается к серверу по TCP, и делает это по расписанию раз в 15 минут по умолчанию

3. Если серверу нужно связаться с агентами срочно (например вы обновили политику, или есть новые базы для скачивания) он отправляет специальный пакет на UDP 15000 (который слушает агент) только с одним сообщением "Все кто меня услышал ... подключитесь ко мне, есть новости", а далее срабатывает пункт 2 и агент который услышал послание подключается к серверу.

 

то есть по UDP сервер только просит подключится и не передает ни какой другой информации, связь клиента с сервером проходит по шифрованному TCP

 

Спойлер

1115339702_.thumb.png.276874284b98281ba0fc42d6a36b518f.png

 

 

 

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

Изменено пользователем ElvinE5
Опубликовано
02.02.2024 в 15:46, ElvinE5 сказал:

(возможно UDP 14000 но только если вы это сами укажите вручную)

Поправка - TCP 14000

  • Like (+1) 1
Опубликовано
7 часов назад, mike 1 сказал:

Поправка - TCP 14000

да, простите ошибся ... все верно TCP

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • Ivan.A.S.
      Автор Ivan.A.S.
      Всем доброго дня!
      Форумчане, пользователи Kaspersky VPN, не могли бы вы проверить,, устойчиво ли работает Google Meet: качество видео и звука. Есть идеи как нормализовать именно этот конференц-сервис?
       
      Заранее благодарю,
      Иван
    • zhenius123
      Автор zhenius123
      У нас ksc 15.1 стоит на debian. Пытаюсь состыковать его с Active Directory на Windows server 2019.
      Добавил  в "Обнаружение устройств и развертывание / Обнаружение устройств / Контроллеры доменов / Параметры опроса" ip адрес контроллера домена и учетную запись. 
      Жму "Начать опрос", пробегает зеленая полоска на 100 %, пропадает и никакой информации не появляется. 
      Нет никаких ошибок или сообщений. Как понять что происходит? Если ошибка, то где взять хотя бы информацию о том какая это ошибка?
      Контроллер домена пингуется и порты доступны.

    • Ufolog
      Автор Ufolog
      Нет связи агента с KSC , при установке не проходит проверка
      Всем привет, столкнулся с проблемой в установке KES.
      Разворачиваю при помощи автономного пакета установки (проверенный сотни раз) на одном из серверов под управлением ОС Windows Server 2008 R2 Enterprise (x64) доходит до шага проверки соединения с сервером KSC, не может с ним соединиться и всё на этом. При этом с данного сервера, сервер KSC отлично пингуется, в обратном направлении так же всё хорошо пингуется.
      Но при ручном запуске утилиты проверки klnagchk
       Она просто завершается, скорее всего это происходит и на этапе установки.
      Пробовал с другим агентом 14.2 такая же история.
       

       
      Может кто сталкивался или просто подскажет что то дельное...
    • infobez_bez
      Автор infobez_bez
      Здравствуйте!

      Я настраиваю политику карантина для устройств под управлением Windows в KSC. При переносе устройства в эту политику у него должна блокироваться вся сетевая активность, кроме связи с сервером администрирования.

      Проблема:
      -В политике для Linux есть опция «Всегда добавлять разрешающее правило для портов агента администрирования», но в политике для Windows такой настройки нет.
      -Я пробовал добавлять сервер администрирования в доверенные узлы, но при этом разрешались и другие локальные службы, а нужно, чтобы работала только связь с KSC.
      -Также пытался вручную прописать правила в сетевом экране для портов агента (например, 13000, 14000 TCP/UDP), но это не сработало — устройство теряло связь с сервером.

      Вопрос:
      Как правильно настроить политику карантина для Windows, чтобы:
      -Устройство имело доступ только к серверу администрирования KSC.
      -Все остальные сетевые соединения (включая локальные службы) блокировались.
      -Устройство могло получать обновления политик (например, при выходе из карантина).
      -Нужна ли дополнительная настройка сетевого экрана или есть скрытые параметры, аналогичные функционалу для Linux?

      KSC 14.2
    • KL FC Bot
      Автор KL FC Bot
      Постоянный доступ в Интернет и мобильная связь привычны, как электричество, и мы уже плохо представляем, как жили без них раньше. Но представьте себе ситуацию, когда мобильного Интернета или сотовой связи нет, а вам нужно оставаться на связи с друзьями поблизости. Например, в самолете вашу компанию рассадили по разным концам салона, а вы собирались во время полета обсудить дальнейшие планы поездки. Или на музыкальном фестивале Интернет еле дышит, вокруг громко, но договориться, когда идти на мейн, все-таки нужно.
      Тут на помощь могут прийти децентрализованные p2p- (peer-to-peer) или mesh-мессенджеры, позволяющие связать множество устройств в единую mesh-сеть через Bluetooth или Wi-Fi Direct.
      В 2010-е годы с появлением Wi-Fi Direct подобные мессенджеры, с одной стороны, наделали много шума, а с другой, — не получили особого распространения: непонятно было, для чего и где их использовать. Странная замена рации, менее дальнобойной и более энергозависимой, не стала популярной среди пользователей смартфонов. Тем не менее по сей день подобные мессенджеры живы, поддерживаются разработчиками и даже появляются новые разработки.
      Меж тем, у этих мессенджеров есть важная ниша: они позволяют оставаться на связи в ситуациях природных катаклизмов, координировать работу поисковых групп или просто общаться с соседями по дому или даче при сбоях мобильной связи или Интернета. Для этих и других подобных случаев не идеально, но подойдут децентрализованные мессенджеры, которые не требуют подключения к Интернету.
      Так что, если перед задуманным походом вам не доставят заказанные рации, вы можете попробовать воспользоваться mesh-мессенджерами как запасным вариантом.
      Как работают p2p-мессенджеры?
      Принцип работы подобных мессенджеров основан на децентрализованных mesh-сетях, где каждое устройство одновременно является и клиентом, и ретранслятором. Из множества клиентских устройств строится распределенная сеть, каждый участник которой может служить мостом для передачи сообщений дальше.
      Представьте, что ваш смартфон превращается в мини-рацию, которая может передавать сообщения другим таким же устройствам с нужным приложением поблизости. Если вы хотите отправить сообщение, оно будет «прыгать» через смартфоны других пользователей приложения, пока не дойдет до адресата. При этом промежуточные устройства не смогут прочитать сообщение — для связующих узлов оно будет зашифровано.
      Устройства связываются между собой напрямую с использованием либо Bluetooth, либо Wi-Fi Direct.
       
      View the full article
×
×
  • Создать...