По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Почитайте предыдущую статью из цикла про установление и прекращение соединения в TCP.
UDP предоставляет приложениям сервис для обмена сообщениями. В отличие от TCP, UDP не требует установления соединения и не обеспечивает надежности, работы с окнами, переупорядочивания полученных данных и сегментации больших фрагментов данных на нужный размер для передачи. Однако UDP предоставляет некоторые функции TCP, такие как передача данных и мультиплексирование с использованием номеров портов, и делает это с меньшим объемом служебных данных и меньшими затратами на обработку, чем TCP.
Передача данных UDP отличается от передачи данных TCP тем, что не выполняется переупорядочевание или восстановление. Приложения, использующие UDP, толерантны к потерянным данным, или у них есть какой-то прикладной механизм для восстановления потерянных данных. Например, VoIP использует UDP, потому что, если голосовой пакет потерян, к тому времени, когда потеря может быть замечена и пакет будет повторно передан, произойдет слишком большая задержка, и голос будет неразборчивым. Кроме того, запросы DNS используют UDP, потому что пользователь будет повторять операцию, если разрешение DNS не удается. В качестве другого примера, сетевая файловая система (NFS), приложение удаленной файловой системы, выполняет восстановление с помощью кода уровня приложения, поэтому функции UDP приемлемы для NFS.
На рисунке 10 показан формат заголовка UDP. Самое главное, обратите внимание, что заголовок включает поля порта источника и назначения для той же цели, что и TCP. Однако UDP имеет только 8 байтов по сравнению с 20-байтовым заголовком TCP, показанным на рисунке 1-1. UDP требует более короткого заголовка, чем TCP, просто потому, что у UDP меньше работы.
Приложения TCP / IP
Вся цель построения корпоративной сети или подключения небольшой домашней или офисной сети к Интернету состоит в использовании таких приложений, как просмотр веб-страниц, обмен текстовыми сообщениями, электронная почта, загрузка файлов, голос и видео. В этом подразделе исследуется одно конкретное приложение - просмотр веб-страниц с использованием протокола передачи гипертекста (HTTP).
Всемирная паутина (WWW) состоит из всех подключенных к Интернету веб-серверов в мире, а также всех подключенных к Интернету хостов с веб-браузерами. Веб-серверы, которые состоят из программного обеспечения веб-сервера, запущенного на компьютере, хранят информацию (в виде веб-страниц), которая может быть полезна для разных людей. Веб-браузер, представляющий собой программное обеспечение, установленное на компьютере конечного пользователя, предоставляет средства для подключения к веб-серверу и отображения веб-страниц, хранящихся на веб-сервере. Хотя большинство людей используют термин "веб-браузер" или просто "браузер", веб-браузеры также называются веб-клиентами, потому что они получают услугу с веб-сервера.
Чтобы этот процесс работал, необходимо выполнить несколько определенных функций прикладного уровня. Пользователь должен каким-то образом идентифицировать сервер, конкретную веб-страницу и протокол, используемый для получения данных с сервера. Клиент должен найти IP-адрес сервера на основе имени сервера, обычно используя DNS. Клиент должен запросить веб-страницу, которая на самом деле состоит из нескольких отдельных файлов, а сервер должен отправить файлы в веб-браузер. Наконец, для приложений электронной коммерции (электронной коммерции) передача данных, особенно конфиденциальных финансовых данных, должна быть безопасной. В следующих подразделах рассматривается каждая из этих функций.
Унифицированные идентификаторы ресурсов
Чтобы браузер отображал веб-страницу, он должен идентифицировать сервер, на котором находится эта веб-страница, а также другую информацию, которая идентифицирует конкретную веб-страницу. Большинство веб-серверов имеют множество веб-страниц. Например, если вы используете веб-браузер для просмотра www.cisco.com и щелкаете по этой веб-странице, вы увидите другую веб-страницу. Щелкните еще раз, и вы увидите другую веб-страницу. В каждом случае щелчок идентифицирует IP-адрес сервера, а также конкретную веб-страницу, при этом детали в основном скрыты от вас. (Эти интерактивные элементы на веб-странице, которые, в свою очередь, переводят вас на другую веб-страницу, называются ссылками.)
Пользователь браузера может идентифицировать веб-страницу, когда вы щелкаете что-либо на веб-странице или когда вы вводите унифицированный идентификатор ресурса (URI) в адресную область браузера. Оба варианта - щелчок по ссылке и ввод URI - относятся к URI, потому что, когда вы щелкаете ссылку на веб-странице, эта ссылка фактически ссылается на URI.
Большинство браузеров поддерживают какой-либо способ просмотра скрытого URI, на который ссылается ссылка. В некоторых браузерах наведите указатель мыши на ссылку, щелкните правой кнопкой мыши и выберите "Свойства". Во всплывающем окне должен отображаться URI, на который будет направлен браузер, если вы нажмете эту ссылку.
В просторечии многие люди используют термины веб-адрес или аналогичные связанные термины Universal Resource Locator (или Uniform Resource Locator [URL]) вместо URI, но URI действительно является правильным формальным термином. Фактически, URL-адрес используется чаще, чем URI, уже много лет. Однако IETF (группа, определяющая TCP / IP) вместе с консорциумом W3C (W3.org, консорциум, разрабатывающий веб-стандарты) предприняли согласованные усилия по стандартизации использования URI в качестве общего термина.
С практической точки зрения, URI, используемые для подключения к веб-серверу, включают три ключевых компонента, как показано на рисунке 11. На рисунке показаны формальные имена полей URI. Что еще более важно для понимания, обратите внимание, что текст перед :// определяет протокол, используемый для подключения к серверу, текст между // и / идентифицирует сервер по имени, а текст после / идентифицирует веб-страницу.
В этом случае используется протокол передачи гипертекста (HTTP), имя хоста - www.certskills.com, а имя веб-страницы - blog.
Поиск веб-сервера с помощью DNS
Хост может использовать DNS для обнаружения IP-адреса, соответствующего определенному имени хоста. В URI обычно указывается имя сервера - имя, которое можно использовать для динамического изучения IP-адреса, используемого этим же сервером. Веб-браузер не может отправить IP-пакет на имя назначения, но он может отправить пакет на IP-адрес назначения. Итак, прежде чем браузер сможет отправить пакет на веб-сервер, браузеру обычно необходимо преобразовать имя внутри URI в соответствующий IP-адрес этого имени.
Чтобы собрать воедино несколько концепций, на рисунке 12 показан процесс DNS, инициированный веб-браузером, а также некоторая другая связанная информация. С базовой точки зрения пользователь вводит URI (в данном случае http://www.exempel.com/go/learningnetwork), преобразует имя www.exempel.com в правильный IP-адрес и начинает отправлять пакеты на веб сервер.
Шаги, показанные на рисунке, следующие:
Пользователь вводит URI http://www.exempel.com/go/learningnetwork в адресную область браузера.
Клиент отправляет DNS-запрос на DNS-сервер. Обычно клиент узнает IP-адрес DNS-сервера через DHCP. Обратите внимание, что запрос DNS использует заголовок UDP с портом назначения 53-го известного порта DNS (см. таблицу 2 ранее в этой лекции, где приведен список популярных хорошо известных портов).
DNS-сервер отправляет ответ, в котором IP-адрес 198.133.219.25 указан как IP-адрес www.exemple.com. Также обратите внимание, что ответ показывает IP-адрес назначения 64.100.1.1, IP-адрес клиента. Он также показывает заголовок UDP с портом источника 53; исходный порт - 53, потому что данные получены или отправлены DNS-сервером.
Клиент начинает процесс установления нового TCP-соединения с веб-сервером. Обратите внимание, что IP-адрес назначения - это только что изученный IP-адрес веб-сервера. Пакет включает заголовок TCP, потому что HTTP использует TCP. Также обратите внимание, что TCP-порт назначения - 80, хорошо известный порт для HTTP. Наконец, отображается бит SYN, как напоминание о том, что процесс установления TCP-соединения начинается с сегмента TCP с включенным битом SYN (двоичная 1).
Пример на рисунке 12 показывает, что происходит, когда клиентский хост не знает IP-адрес, связанный с именем хоста, но предприятие знает адрес. Однако хосты могут кэшировать результаты DNS-запросов, так что какое-то время клиенту не нужно запрашивать DNS для разрешения имени. Также DNS-сервер может кэшировать результаты предыдущих DNS-запросов; например, корпоративный DNS-сервер на рисунке 12 обычно не имеет настроенной информации об именах хостов в доменах за пределами этого предприятия, поэтому в этом примере DNS-сервер кэшировал адрес, связанный с именем хоста www.example.com.
Когда локальный DNS не знает адрес, связанный с именем хоста, ему необходимо обратиться за помощью. На рисунке 13 показан пример с тем же клиентом, что и на рисунке 12. В этом случае корпоративный DNS действует как рекурсивный DNS-сервер, отправляя повторяющиеся DNS-сообщения, чтобы идентифицировать авторитетный DNS-сервер.
Шаги, показанные на рисунке, следующие:
Клиент отправляет DNS-запрос для www.exemple.com на известный ему DNS-сервер, который является корпоративным DNS-сервером.
(Рекурсивный) корпоративный DNS-сервер еще не знает ответа, но он не отклоняет DNS-запрос клиента. Вместо этого он следует повторяющемуся (рекурсивному) процессу (показанному как шаги 2, 3 и 4), начиная с DNS-запроса, отправленного на корневой DNS-сервер. Корень также не предоставляет адрес, но он предоставляет IP-адрес другого DNS-сервера, ответственного за домен верхнего уровня .com.
Рекурсивный корпоративный DNS-сервер отправляет следующий DNS-запрос DNS-серверу, полученному на предыдущем шаге, - на этот раз DNS-серверу TLD для домена .com. Этот DNS также не знает адреса, но знает DNS-сервер, который должен быть официальным DNS-сервером для домена exemple.com, поэтому он предоставляет адрес этого DNS-сервера.
Корпоративный DNS отправляет другой DNS-запрос DNS-серверу, адрес которого был получен на предыдущем шаге, снова запрашивая разрешение имени www.exeple.com. Этот DNS-сервер, официальный сервер exemple.com, предоставляет адрес.
Корпоративный DNS-сервер возвращает DNS-ответ клиенту, предоставляя IP-адрес, запрошенный на шаге 1.
Передача файлов по HTTP
После того, как веб-клиент (браузер) создал TCP-соединение с веб-сервером, клиент может начать запрашивать веб-страницу с сервера. Чаще всего для передачи веб-страницы используется протокол HTTP. Протокол прикладного уровня HTTP, определенный в RFC 7230, определяет, как файлы могут передаваться между двумя компьютерами. HTTP был специально создан для передачи файлов между веб-серверами и веб-клиентами.
HTTP определяет несколько команд и ответов, из которых наиболее часто используется запрос HTTP GET. Чтобы получить файл с веб-сервера, клиент отправляет на сервер HTTP-запрос GET с указанием имени файла. Если сервер решает отправить файл, он отправляет ответ HTTP GET с кодом возврата 200 (что означает ОК) вместе с содержимым файла.
Для HTTP-запросов существует множество кодов возврата. Например, если на сервере нет запрошенного файла, он выдает код возврата 404, что означает "файл не найден". Большинство веб-браузеров не показывают конкретные числовые коды возврата HTTP, вместо этого отображая ответ, такой как "страница не найдена", в ответ на получение кода возврата 404.
Веб-страницы обычно состоят из нескольких файлов, называемых объектами. Большинство веб-страниц содержат текст, а также несколько графических изображений, анимированную рекламу и, возможно, видео и звук. Каждый из этих компонентов хранится как отдельный объект (файл) на веб-сервере. Чтобы получить их все, веб-браузер получает первый файл. Этот файл может (и обычно делает) включать ссылки на другие URI, поэтому браузер затем также запрашивает другие объекты. На рисунке 14 показана общая идея, когда браузер получает первый файл, а затем два других.
В этом случае, после того, как веб-браузер получает первый файл - тот, который в URI называется "/go/ccna", браузер читает и интерпретирует этот файл. Помимо частей веб-страницы, файл ссылается на два других файла, поэтому браузер выдает два дополнительных запроса HTTP GET. Обратите внимание, что, даже если это не показано на рисунке, все эти команды проходят через одно (или, возможно, несколько) TCP-соединение между клиентом и сервером. Это означает, что TCP обеспечит исправление ошибок, гарантируя доставку данных.
Как принимающий хост определяет правильное принимающее приложение
Эта лекция завершается обсуждением процесса, с помощью которого хост при получении любого сообщения по любой сети может решить, какая из множества своих прикладных программ должна обрабатывать полученные данные.
В качестве примера рассмотрим хост A, показанный слева на рисунке 15. На хосте открыто три разных окна веб-браузера, каждое из которых использует уникальный TCP-порт. На хосте A также открыт почтовый клиент и окно чата, оба из которых используют TCP. И электронная почта, и чат-приложения используют уникальный номер TCP-порта на хосте A, как показано на рисунке.
В этой части лекции показано несколько примеров того, как протоколы транспортного уровня используют поле номера порта назначения в заголовке TCP или UDP для идентификации принимающего приложения. Например, если значение TCP-порта назначения на рисунке 15 равно 49124, хост A будет знать, что данные предназначены для первого из трех окон веб-браузера.
Прежде чем принимающий хост сможет проверить заголовок TCP или UDP и найти поле порта назначения, он должен сначала обработать внешние заголовки в сообщении. Если входящее сообщение представляет собой кадр Ethernet, который инкапсулирует пакет IPv4, заголовки выглядят так, как показано на рисунке 16.
Принимающему узлу необходимо просмотреть несколько полей, по одному на заголовок, чтобы идентифицировать следующий заголовок или поле в полученном сообщении. Например, хост A использует сетевой адаптер Ethernet для подключения к сети, поэтому полученное сообщение представляет собой кадр Ethernet. Поле типа Ethernet определяет тип заголовка, который следует за заголовком Ethernet - в данном случае со значением шестнадцатеричного значения 0800, заголовком IPv4.
Заголовок IPv4 имеет аналогичное поле, называемое полем протокола IP. Поле протокола IPv4 имеет стандартный список значений, которые идентифицируют следующий заголовок, с десятичным числом 6, используемым для TCP, и десятичным числом 17, используемым для UDP. В этом случае значение 6 определяет заголовок TCP, следующий за заголовком IPv4. Как только принимающий хост понимает, что заголовок TCP существует, он может обработать поле порта назначения, чтобы определить, какой процесс локального приложения должен получить данные.
Теперь вас ждет материал про списки управления доступом IPv4
В связи с проблемами безопасности в протоколе TLSv1.0 организации PCI (индустрия платежных карт) и BSI предложили внедрить и включить протоколы TLSv1.1 или TLSv1.2, а, также, как можно скорее отойти от использования TLSv1.0. В этой статье мы представляем текущее состояние этой реализации в соответствующих продуктах VMware.
Отказ от ответственности
1.Некоторые продукты или более старые версии некоторых продуктов могут отсутствовать в этом списке, поскольку, либо нет планов реализации более новых протоколов TLS, либо изменения TLS не применимы. Возможно, эти продукты уже достигли или приближаются к истечению срока действия (EOA) или концу срока службы (EOS).
Резолюция
С точки зрения реализации, включение протоколов TLSv1.1/1.2 всегда выполняется по умолчанию, в то время как отключение TLSv1.0 могло быть либо по умолчанию (отключено по умолчанию), либо через параметр (может быть отключено через параметр).
По умолчанию компания VMware стремится к взаимодействию всех продуктов по самым высокоуровневым стандартам, доступным в программах и между ними.
Замечание: Для обратного рассмотрения обеспечения совместимости и интероперабельности в некоторых продуктах, хотя отключение TLSv1.0 и реализовано по умолчанию, есть возможность вернуть это изменение. По мере необходимости, ознакомьтесь с прилагаемой документацией, чтобы узнать подробности.
Программы и их статус перечислены в 3-х таблицах ниже.
Программы, в которых обе реализации, включение TLSv1.1/1.2 и отключение TLSv1.0 - реализованы.
Программы, для которых завершена только реализация TLSv1.1/1.2, но ожидается отключение TLSv1.0.
Программы, в которых обе реализации, включение TLSv1.1/1.2 и отключение TLSv1.0, ожидают разработки.
Примечания
Версия с отключением протокола TLSv.1.0 является его первым релизом, во всех последующих релизах эта функция будет отключена по умолчанию.
Версия с включенным по умолчанию протоколом TLSv1.1/1.2 является его первым релизом, во всех последующих релизах эта опция будет отключена по умолчанию.
Программы, в которых обе реализации, включение TLSv1.1/1.2 и отключение TLSv1.0, завершены
Продукт
Включение (всегда по умолчанию) TLSv1.1/1.2 Версия
Отключение TLSv1.0 - версия
Отключение TLSv1.0 - тип реализации
Документация
VMware Platform Services Controller (External) 6.xVMware Platform Services Controller Appliance (External) 6.x
6.7
6.7
По умолчанию
Managing TLS Protocol Configuration with the TLS Configurator UtilityRelease Notes for Platform Services Controller 6.7
6.5
6.5
Через параметр
Managing TLS protocol configuration for vSphere 6.5 (2147469)Release Notes for Platform Services Controller 6.5
6.0 Update 3
6.0 Update 3
Через параметр
Managing TLS protocol configuration for vSphere 6.0 Update 3 (2148819)
Release Notes for vCenter Server 6.0 U3
VMware Identity Manager 2.x
2.6
2.6
По умолчанию
Enabling TLS 1.0 protocol in VMware Identity Manager 2.6 (2144805)Release Notes for VMware Identity Manager 2.6
VMware Integrated OpenStack 3.x
3.0
3.0
Через параметр
Release Notes for VMware Integrated OpenStack 3.0
VMware vCloud Director for Service Providers 8.x
8.10
8.10
Через параметр
Managing the List of Allowed SSL Protocols in the vCloud Director Administrator's GuideRelease Notes for VMware vCloud Director for Service Providers 8.10
VMware vCloud Availability for vCloud Director 1.x
1.0.1
1.0.1
Через параметр
Configuring vCloud Director for Installation in the vvCloud Availability for vCloud Director Installation and Configuration GuideRelease Notes for vCloud Availability for vCloud Director 1.0.1
VMware vCloud Usage Meter 3.5
3.5
3.5
По умолчанию
Release Notes for VMware vCloud Usage Meter 3.5
VMware vCloud Usage Meter 3.6
3.6
3.6
По умолчанию
Release Notes for VMware vCloud Usage Meter 3.6
VMware vCloud Air Hybrid Cloud Manager 2.x
2.0
2.0
Через параметр
Hybrid Cloud Manager Security Protocol (2146900)Release Notes for VMware vCloud Air Hybrid Cloud Manager 2.0
VMware vRealize Business Advanced and Enterprise 8.x
8.2.4
8.2.4
По умолчанию
Release Notes for vRealize Business Advanced and Enterprise 8.2.4
VMware vRealize Business Standard for Cloud 7.x
7.1.0
7.1.0
По умолчанию
Enable or Disable TLS in the vRealize Business for Cloud Install GuideRelease Notes for vRealize Business Standard for Cloud 7.1.0
VMware vRealize Configuration Manager 5.x
5.8.2
5.8.3
По умолчанию
Release Notes for VMware vRealize Configuration Manager 5.8.3Release Notes for VMware vRealize Configuration Manager 5.8.2
VMware NSX for vSphere 6.xIncludes: Manager, Controller, Endpoint, Edge.
6.2.4
6.2.4
Через параметр
Disabling Transport Layer Security (TLS) 1.0 on NSX (2145749)Release Notes for VMware NSX for vSphere 6.2.4
VMware vCenter Server 6.xVMware vCenter Server Appliance 6.x
6.7
6.7
По умолчанию
Managing TLS Protocol Configuration with the TLS Configurator UtilityRelease Notes for vCenter Server 6.7
6.5
6.5
Через параметр
Managing TLS protocol configuration for vSphere 6.5 (2147469)Release Notes for vCenter Server 6.5
6.0 Update 3
6.0 Update 3
Через параметр
Managing TLS protocol configuration for vSphere 6.0 Update 3 (2148819)
Release Notes for vCenter Server 6.0 U3
vCenter Server Heartbeat 6.6.x
6.6 Update 2
6.6 Update 2
Через параметр
Configuring VMware vCenter Server Heartbeat to use only TLS2v1.1 and TLSv1.2 (2146352)Release Notes for vCenter Server Heartbeat 6.6 Update 2
VMware vRealize Automation 7.x
7.0.1
7.1.0
Через параметр
Disabling TLS 1.0 in vRealize Automation (2146570)Release Notes for VMware vRealize Automation 7.1.0Release Notes for VMware vRealize Automation 7.0.1
VMware vRealize Orchestrator 7.x
7.0.0
7.0.1
По умолчанию
Enable SSLv3 and TLSv1 for outgoing HTTPS connections in vRealize Orchestrator 6.0.4 and 7.0.x manually (2144318)Release Notes for vRealize Orchestrator 7.0.0Release Notes for vRealize Orchestrator 7.0.1
VMware vSphere Update Manager 6.x
6.5
6.5
Через параметр
Managing TLS protocol configuration for vSphere 6.5 (2147469)Release Notes for vSphere Update Manager 6.5
6.0 Update 3
6.0 Update 3
Через параметр
Configuring the TLS protocol for Update Manager 6.0 Update 3 (2149136)
Release Notes for vSphere Update manager 6.0 U3
VMware vRealize Infrastructure Navigator 5.8.x
5.8.5
5.8.5
Через параметр
Disabling TLSv1 Support in vRealize Infrastructure Navigator (2139941)Release Notes for vRealize Infrastructure Navigator 5.8.5
VMware vCenter Support Assistant 6.x
6.0.2
6.0.2
По умолчанию
TLS protocol configuration options for vCenter Support Assistant (2146079)Release Notes for vCenter Support Assistant 6.0.2
VMware vRealize Operations 6.2.x
6.2.0
6.2.x
Через параметр
Disable TLS 1.0 in vRealize Operations Manager 6.2 (2138007)Release Notes for vRealize Operations Manager 6.2.0
VMware vRealize Operations Management pack for MEDITECH 1.0
6.2.0
6.2.x
Через параметр
Disable TLS 1.0 in vRealize Operations Manager 6.2 (2138007)Release Notes for vRealize Operations Manager 6.2.0
VMware vRealize Operations Management pack for Epic 1.0
6.2.0
6.2.x
Через параметр
Disable TLS 1.0 in vRealize Operations Manager 6.2 (2138007)Release Notes for vRealize Operations Manager 6.2.0
VMware vRealize Operations Management pack for Published Applications 6.x
6.1.1
6.1.1
По умолчанию
Release Notes for VMware vRealize Operations for Published Applications 6.1.1
VMware vRealize Hyperic 5.x
5.8.6
5.8.6
По умолчанию
Release Notes for vRealize Hyperic 5.8.6
VMware vRealize Log Insight 4.x
4.0
4.0
Через параметр
How to disable TLS 1.0 in vRealize Log Insight (2146305)Release Note for vRealize Log Insight 4.0
VMware vRealize Log Insight 3.x
3.0
3.0
Через параметр
Log Insight 2.5 and 3.0 cannot establish connection to remote TLSv1.1 or TLSv1.2 servers (2144162)How to disable TLS 1.0 in vRealize Log Insight (2146305)Release Note for vRealize Log Insight 3.6Release Note for vRealize Log Insight 3.3Release Note for vRealize Log Insight 3.0
VMware Site Recovery Manager 6.x
6.5
6.5
По умолчанию
Release Notes for Site Recovery Manager 6.5
6.1
6.1.1
Через параметр
TLS Configuration Options For Site Recovery Manager 6.1.1 (2145910)Release Notes for Site Recovery Manager 6.1Release Notes for Site Recovery Manager 6.1.1
VMware vSphere Replication 6.x
6.5
6.5
По умолчанию
Release Notes for vSphere Replication 6.5
6.1.1
6.1.1
Через параметр
TLS protocol configuration options for vSphere Replication 6.1.1 (2145893)Release Notes for vSphere Replication 6.1.1
VMware ESXi 6.x
6.7
6.7
Через параметр
Managing TLS Protocol Configuration with the TLS Configurator UtilityRelease Notes for vSphere ESXi 6.7
6.5
6.5
Через параметр
Managing TLS protocol configuration for vSphere 6.5 (2147469)Release Notes for vSphere ESXi 6.5
6.0 Update 3
6.0 Update 3
Через параметр
Managing TLS protocol configuration for vSphere 6.0 Update 3 (2148819)
Release Notes for vSphere ESXi 6.0 U3
VMware Tools 10.x
10.0.0
10.1.0
По умолчанию
Release Note for VMware Tools 10.1.0Release Note for VMware Tools 10.0.12Note: TLSv1.2 is leveraged for internal communications only as VMware Tools does not use SSL based communication to other components.
VMware vSAN 6.x
6.7
6.7
Через параметр
Release Notes for VMware vSAN 6.7
6.6
6.6
Через параметр
Release Notes for VMware vSAN 6.6
6.5
6.5
Через параметр
Managing TLS protocol configuration for vSphere 6.5 (2147469)Release Notes for VMware vSAN 6.5
6.2
6.2
Через параметр
Release Notes for VMware vSAN 6.2
VMware AppVolumes 2.x
2.11.0
2.11.0
Через параметр
Release Notes for VMware App Volumes 2.11.0Patch required
VMware AppVolumes 3.x
3.0
3.0
По умолчанию
VMware AppVolumes 3.0 Installation and Administration GuideRelease Notes for VMware App Volumes 3.0
VMware vRealize Code Stream 2.x
2.1.0
2.1.0
Через параметр
Disabling TLS 1.0 in vRealize Automation (2146570)Release Notes for VMware vRealize Code Stream 2.1
VMware Remote Console 8.x
8.0
8.0
По умолчанию
Release Notes for VMware Remote Console 8.0
VMware vFabric tc Server 2.9.x
2.9.13
2.9.13
Через параметр
Release Notes for vFabric tc Server 2.9
VMware Horizon for Linux 6.2.x
6.2.1
6.2.1
По умолчанию
Setting Options in Configuration Files on Linux Desktop in the Horizon 6 Version 6.2 GuideRelease Notes for VMware Horizon 6 version 6.2.1
VMware Horizon Client 4.x
4.0.1
4.0.1
Через параметр
Configure Advanced TLS/SSL Options in the VMware Horizon Client Admin Guide for iOSConfigure Advanced TLS/SSL Options in the VMware Horizon Client Admin Guide for AndroidConfigure Advanced TLS/SSL Options in the VMware Horizon Client Admin Guide for Mac OS XConfigure Advanced TLS/SSL Options in the VMware Horizon Client Admin Guide for LinuxConfigure Advanced TLS/SSL Options in the VMware Horizon Client Admin Guide for WindowsRelease Notes for VMware Horizon Client 4.1 for iOSRelease Notes for VMware Horizon Client 4.1 for AndroidRelease Notes for VMware Horizon Client 4.1 for Mac OS XRelease Notes for VMware Horizon Client 4.1 for LinuxRelease Notes for VMware Horizon Client 4.1 for Windows
VMware Horizon View 7.x
7.0
7.0
По умолчанию
Configuring security protocols on components to connect the View Client with desktops (2130798)Release Notes for VMware Horizon View 7.0
VMware Horizon View 6.x
6.2.1
6.2.1
По умолчанию
Configuring security protocols on components to connect the View Client with desktops (2130798)Release Notes for VMware Horizon View 6.2.1
VMware Horizon Air 16.x
16.6.0
16.6.0
Через параметр
Disabling TLS 1.0 in Horizon Air Appliances (2146781)Release Notes for VMware Horizon Air 16.6
Horizon Daas 7.0
7.0.0
7.0.0
По умолчанию
Release Notes for VMware Horizon DaaS 7.0
VMware Mirage
5.7
5.7
Через параметр
Disabling TLS 1.0 on Windows systems (2145606)Release Notes for VMware Mirage 5.7
VMware Horizon Air Hybrid-mode 1.x
1.0
1.0
По умолчанию
Change the Security Protocols and Cipher Suites Used for TLS or SSL Communication in VMware Horizon Air Hybrid-Mode 1.0 Administration GuideConfiguration Settings for System Settings and Server Certificates in VMware Horizon Air Hybrid-Mode 1.0 Administration GuideRelease Notes for VMware Horizon Air Hybrid-mode 1.0
VMware Software Manager - Download Server
1.3
1.3
По умолчанию
Enable SSLv3 or TLSv1 in the VMware Software Manager - Download Service User Guide.Release Notes for VMware Software Manager 1.3
VMware Photon OS
1.0
1.0
Через параметр
Disabling TLS 1.0 to Improve Transport Layer Security in the Photon OS Administration Guide
VMware Continuent 5.xIncludes: Analytics and Big Data, Cluster, Disaster Recovery, Replication
5.0
5.0
По умолчанию
Release Notes for VMware Software Manager 5.0
VMware vSphere Big Data Extension 2.3.x
2.3.2
2.3.2
Через параметр
Release Notes for vSphere Big Data Extension 2.3
NSX-T
1.1
1.1
По умолчанию
Release Notes for NSX-T 1.1
vCenter Chargeback Manager
2.7.2
2.7.1
По умолчанию
Release Notes for Chargeback Manager 2.7.2
VMware Network Insight 3.x
3.3
3.3
По умолчанию
Release Notes for VMware Network Insight 3.3
Продукты, для которых завершена только реализация TLSv1.1/1.2, но ожидается отключение TLSv1.0
По мере выпуска софта с обеими реализациями они будут перемещаться из этого раздела в верхнюю таблицу; однако, программы и их доступность могут изменяться и оставаться в этой таблице.
Продукт
Включение (всегда по умолчанию) TLSv 1.1/1.2 Версия
Отключение TLSv1.0 Плановая версия
Документация
VMware vCenter Converter Standalone 6.x
6.1.1
(Ожидающий)
VMware vCenter Converter Standalone User's Guide (Страница 40)Release Notes for VMware vCenter Converter Standalone 6.1.1
VMware Fusion 8.x
8.0.0
(Ожидающий)
Release Notes for VMware Fusion 8
VMware Workstation Pro/Player 12.x
12.0.0
(Ожидающий)
Release Notes for VMware Workstation 12 ProRelease Notes for VMware Workstation 12 Player
VMware vSphere Data Protection 6.1.x
6.14
(Ожидающий)
Release Notes for Data Protection 6.1.4
Продукты, в которых обе реализации, включение TLSv1.1/1.2 и отключение TLSv1.0, ожидают обработки
По мере выпуска софта с обеими реализациями они будут перемещаться из этого раздела в верхнюю таблицу; однако, программы и их доступность могут изменяться и оставаться в этой таблице.
Продукт
Включение (всегда по умолчанию) TLSv 1.1/1.2 Плановая версия
Отключение TLSv1.0 Плановая версия
Документация
VMware Photon Controller 1.x
(Ожидающий)
(Ожидающий)
(Ожидающий)
Управление компьютерными сетями - дело непростое. В последние годы всеобщая компьютеризация вызвала огромный скачок в расширении компьютерных сетей. Это добавило работы системному администратору. Ведь если ранее были распространены небольшие сети, то добавление и настройка новых устройств, либо обновление ПО на уже находящихся требовали ручной настройки операционной системы, а то и установки на каждом из них. Это требовало времени и нервов администратора. Сейчас же, когда сети насчитывают сотни, а то и тысячи машин, ручная настройка требует либо участия многих специалистов (а это порождает проблему плохой совместимости согласно человеческому фактору, каждый админ мыслит по-своему), либо очень долгого времени, если этим будет заниматься один специалист.
Такая проблема, с учетом технического прогресса, породила решение об автоматизации. На сегодняшний день существует специализированное программное обеспечение, которое позволяет присоединиться к удаленным машинам, и в автоматическом режиме произвести настройки операционной системы для корректной работы сети. Однако, как быть, если на нужных компьютерах в рамках одной сети установлены разные операционные системы? Ведь сейчас компьютеры под Linux, FreeBSD и Windows, объединенные в одну сеть - далеко не редкость. Поэтому одним из требований к управляющей программе стала кроссплатформенность. В этом случае одним из самых эффективных решений является такая программа, как Puppet.
Puppet это один из самых нужных инструментов сетевого администратора. Это приложение создано специально для управления конфигурацией операционных систем внутри одной сети. Оно имеет клиент-серверную архитектуру, то есть администратор, находящийся за сервером, может отправлять данные конфигурации на периферийные машины, на которых установлена клиентская часть. На этих рабочих станциях система в автоматическом режиме сконфигурирует себя в соответствии с присланными с сервера настройками.
Важным моментом является кроссплатформенность. Простота настройки и управления самыми распространенными операционными системами делает Puppet одним из самых актуальных решений по управлению компьютерными сетями на сегодняшний день.
Как же работает Puppet? Разберем подробнее. Для начала, на сервер нужно установить серверную часть программы. Поскольку приложение написано на Ruby, на серверной рабочей станции обязательно должна быть установлена нужная программная среда.
Серверная часть программы создана для хранения манифестов так в программной терминологии Puppet называются файлы с настройками конфигурации. В процессе работы сервер принимает обращения с клиентских машин и автоматически отсылает им обновленные файлы конфигурирования ОС для работы в сети.
На клиентских компьютерах также должно быть установлено программное обеспечение Puppet, уже в виде клиентской части. Как правило, данные установочные пакеты включаются в саму операционную систему, что позволяет быстро развертывать компьютерную сеть, однако, в случае их отсутствия, придется скачивать необходимую сборку с сайта разработчика.
Дополнительное удобство данного решения в том, что один администратор с помощью сервера может осуществить настройку и управление сотен и тысяч машин, объединенных в сеть. Если возникнут какие-то проблемы, то отклик с мест позволит админу быстро поправить код и устранить их. Хотя в данном случае возрастают требования к внимательности админа - одна неверно написанная строка кода конфигурации может привести к неполадкам по всей сети. Хотя, если разобраться, в данном случае можно запустить работающий манифест предыдущей сборки и восстановить все достаточно оперативно.