По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В первой статье серии EIGRP мы познакомились с функциями EIGRP, рассмотрели пример базовой конфигурации и набор команд проверки. Сегодня, в этой статье, мы углубимся в понимание того, как EIGRP устанавливает соседство, изучает маршрут к сети, определяет оптимальный маршрут к этой сети, и пытается ввести этот маршрут в таблицу IP-маршрутизации маршрутизатора.
Предыдущие статьи из цикла про EIGRP:
Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка
Следующие статьи из цикла:
Часть 2.2. Установка K-значений в EIGRP
Часть 3. Конвергенция EIGRP – настройка таймеров
Часть 4. Пассивные интерфейсы в EIGRP
Часть 5. Настройка статического соседства в EIGRP
Часть 6. EIGRP: идентификатор роутера и требования к соседству
Операции EIGRP могут быть концептуально упрощены в три основных этапа:
Этап 1. Обнаружение соседей: посредством обмена приветственными сообщениями EIGRP-спикер маршрутизаторы обнаруживают друг друга, сравнивают параметры (например, номера автономной системы, K-значения и сетевые адреса) и определяют, должны ли они образовывать соседство.
Этап 2. Обмен топологиями: если соседние EIGRP маршрутизаторы решают сформировать соседство, они обмениваются своими полными таблицами топологии друг с другом. Однако после установления соседства между маршрутизаторами передаются только изменения существующей топологии. Этот подход делает EIGRP намного более эффективным, чем протокол маршрутизации, такой как RIP, который объявляет весь свой список известных сетей через определенные интервалы времени.
Этап 3. Выбор маршрутов: как только таблица топологии EIGRP маршрутизатора заполнена, процесс EIGRP проверяет все изученные сетевые маршруты и выбирает лучший маршрут к каждой сети. EIGRP считает, что сетевой маршрут с самой низкой метрикой является лучшим маршрутом к этой сети.
Очень важно, что в когда вы читаете вышеописанные этапы, подробно описывающее обнаружение соседей EIGRP, обмен топологией и выбор маршрута, должны понимать, что в EIGRP, в отличие от OSPF, нет понятия назначенного маршрутизатора (DR) или резервного назначенного маршрутизатора (BDR).
Обнаружение соседей и обмен топологиями
Чтобы лучше понять, как маршрутизатор EIGRP обнаруживает своих соседей и обменивается информацией о топологии с этими соседями, рассмотрим рисунок ниже.
Шесть шагов, изображенных на рисунке выше, выполняются следующим образом:
Шаг 1. Маршрутизатор OFF1 хочет видеть, есть ли какие-либо EIGRP-спикер маршрутизаторы вне его интерфейса Gig 0/1, с которым он мог бы, возможно, сформировать соседство. Таким образом, он осуществляет многоадресную рассылку приветственного сообщения EIGRP (EIGRP Hello) на хорошо известный EIGRP multicast-адрес 224.0.0.10 с просьбой к любым EIGRP-спикер маршрутизаторам, идентифицировать себя.
Шаг 2. После получения приветственного сообщения маршрутизатора OFF1 маршрутизатор OFF2 отправляет одноадресное сообщение обновления (unicast Update message)обратно на IP-адрес маршрутизатора OFF1 10.1.1.1. Это сообщение обновления содержит полную таблицу топологии EIGRP маршрутизатора OFF2.
Шаг 3. Маршрутизатор OFF1 получает обновление маршрутизатора OFF2 и отвечает одноадресным сообщением подтверждения (Acknowledgement (ACK), отправленным на IP-адрес маршрутизатора OFF2 10.1.1.2.
Шаг 4. Затем процесс повторяется, и роли меняются местами. В частности, маршрутизатор OFF2 отправляет приветственное сообщение на адрес многоадресной рассылки EIGRP 224.0.0.10.
Шаг 5. Маршрутизатор OFF1 отвечает на приветственное сообщение маршрутизатора OFF2 одноадресным обновлением (unicast Update), содержащим полную таблицу топологии EIGRP маршрутизатора OFF1. Это unicast Update достигается IP-адрес маршрутизатора OFF2 10.1.1.2.
Шаг 6. Маршрутизатор OFF2 получает информацию о маршрутизации маршрутизатора OFF1 и отвечает одноадресным сообщением ACK, отправленным на IP-адрес маршрутизатора OFF1 10.1.1.1.
На этом этапе было установлено соседство EIGRP между маршрутизаторами OFF1 и OFF2. Маршрутизаторы будут периодически обмениваться приветственными сообщениями, чтобы подтвердить, что сосед каждого маршрутизатора все еще присутствует. Однако это последний раз, когда маршрутизаторы обмениваются своей полной информацией о маршрутизации. Последующие изменения топологии объявляются через частичные обновления, а не полные обновления, используемые во время создания соседства. Кроме того, обратите внимание, что сообщения обновления во время установления соседа были отправлены как одноадресные сообщения. Однако будущие сообщения обновления отправляются как многоадресные сообщения, предназначенные для 224.0.0.10. Это гарантирует, что все EIGRP-спикер маршрутизаторы на сегменте получают сообщения об обновлении.
EIGRP имеет преимущество перед OSPF в том, как он отправляет свои сообщения об обновлении. В частности, сообщения об обновлении EIGRP отправляются с использованием надежного транспортного протокола ( Reliable Transport Protocol (RTP). Это означает, что, в отличие от OSPF, если сообщение обновления будет потеряно при передаче, он будет повторно отправлено.
Примечание: аббревиатура RTP также относится к Real-time Transport Protocol (RTP), который используется для передачи голосовых и видеопакетов.
Выбор маршрута
Маршруты, показанные в таблице топологии EIGRP, содержат метрическую информацию, указывающую, насколько "далеко" она находится от конкретной целевой сети. Но как именно рассчитывается эта метрика? Расчет метрики EIGRP немного сложнее, чем с RIP или OSPF. В частности, метрика EIGRP по умолчанию является целочисленным значением, основанным на пропускной способности и задержке. Также, вычисление метрики может включать и другие компоненты. Рассмотрим формулу вычисления метрики EIGRP:
Обратите внимание, что расчет метрики включает в себя набор K-значений, которые являются константами, принимающие нулевые значения или некоторые положительные целые числа. Расчет также учитывает пропускную способность, задержку, нагрузку и надежность (bandwidth, delay, load, reliability). Интересно, что большая часть литературы по EIGRP утверждает, что метрика также основана на Maximum Transmission Unit (MTU). Однако, как видно из формулы расчета метрики, MTU отсутствует. Так в чем же дело? Учитывает ли EIGRP MTU интерфейса или нет?
В самом начале разработки EIGRP, MTU был обозначен как Тай-брейкер, если два маршрута имели одинаковую метрику, но разные значения MTU. В такой ситуации был бы выбран маршрут с более высоким MTU. Таким образом, хотя сообщение об обновлении EIGRP действительно содержит информацию MTU, эта информация непосредственно не используется в расчетах метрик.
Далее, давайте рассмотрим каждый компонент расчета метрики EIGRP и tiebreaking MTU:
Bandwidth (Пропускная способность): значение пропускной способности, используемое в расчете метрики EIGRP, определяется путем деления 10 000 000 на пропускную способность (в Кбит / с) самого медленного канала вдоль пути к целевой сети.
Delay (Задержка): в отличие от полосы пропускания, которая представляет собой "самое слабое звено", значение задержки является кумулятивным. В частности, это сумма всех задержек, связанных со всеми интерфейсами, которые используются чтобы добраться до целевой сети. Выходные данные команды show interfaces показывают задержку интерфейса в микросекундах. Однако значение, используемое в расчете метрики EIGRP, выражается в десятках микросекунд. Это означает, что вы суммируете все задержки выходного интерфейса, как показано в выводе show interfaces для каждого выходного интерфейса, а затем делите на 10, чтобы получить единицу измерения в десятки микросекунд.
Reliability (Надежность): надежность-это значение, используемое в числителе дроби, с 255 в качестве ее знаменателя. Значение дроби указывает на надежность связи. Например, значение надежности 255 указывает на то, что связь надежна на 100 процентов (то есть 255/255 = 1 = 100 процентов).
Load (Нагрузка): как и надежность, нагрузка-это значение, используемое в числителе дроби, с 255 в качестве ее знаменателя. Значение дроби указывает, насколько занята линия. Например, значение нагрузки 1 указывает на то, что линия загружена минимально (то есть 1/255 = 0,004 1%)
MTU: хотя он не отображается в Формуле вычисления метрики EIGRP, значение MTU интерфейса (которое по умолчанию составляет 1500 байт) переносится в сообщение обновления EIGRP, которое будет использоваться в случае привязки (например, два маршрута к целевой сети имеют одну и ту же метрику, но разные значения MTU), где предпочтительно более высокое значение MTU.
Для улучшения запоминания используйте следующий алгоритм Big Dogs Really Like Me. Где B в слове Big ассоциируется с первой буквой в слове Bandwidth. Буква D в слове Dogs соответствует первой букве D в слове Delay, и так далее.
Однако по умолчанию EIGRP имеет большинство своих K-значений равными нулю, что значительно упрощает расчет метрики, учитывая только пропускную способность и задержку. В частности, значения K по умолчанию являются:
K1 = 1
K2 = 0
K3 = 1
K4 = 0
K5 = 0
Если мы подставим эти дефолтные значения K в расчет метрики EIGRP, то значение каждой дроби будет равно нулю, что сводит формулу к следующему:
Чтобы закрепить знания по вычислению метрики, давайте проведем расчет метрики и посмотрим, соответствует ли она нашей таблице топологии EIGRP. Рассмотрим топологию, показанную на рисунке ниже.
Предположим, что мы хотим вычислить метрику для сети 198.51.100.0/24 от роутера OFF1 для маршрута, который идет от OFF1 до OFF2, а затем выходит в целевую сеть. Из топологии мы можем определить, что нам нужно будет выйти с двух интерфейсов маршрутизатора, чтобы добраться от маршрутизатора OFF1 до сети 198.51.100.0 /24 через маршрутизатор OFF2. Эти два выходных интерфейса являются интерфейсами Gig0/1 на маршрутизаторе OFF1 и интерфейсом Gig0/3 на маршрутизаторе OFF2. Мы можем определить пропускную способность и задержку, связанные с каждым интерфейсом, изучив выходные данные команд show interfaces, приведенных в следующем примере.
Определение значений пропускной способности и задержки интерфейса на маршрутизаторах OFF1 и OFF2
Из приведенного выше примера мы видим, что оба выходных интерфейса имеют пропускную способность 1 000 000 Кбит/с (то есть 1 Гбит/с). Кроме того, мы видим, что каждый выходной интерфейс имеет задержку в 10 микросекунд. Значение пропускной способности, которое мы вводим в нашу формулу вычисления метрики EIGRP, - это пропускная способность самого медленного канала на пути к целевой сети, измеряемая в Кбит/с. В нашем случае оба выходных интерфейса имеют одинаковую скорость соединения, то есть мы говорим, что наша "самая медленная" связь составляет 1 000 000 Кбит/с.
Для примера ниже показаны общие значения по умолчанию для пропускной способности и задержки на различных типах интерфейсов маршрутизатора Cisco.
Общие значения по умолчанию для пропускной способности и задержки интерфейса:
Наше значение задержки может быть вычислено путем сложения задержек выходного интерфейса (измеренных в микросекундах) и деления на 10 (чтобы дать нам значение, измеренное в десятках микросекунд). Каждый из наших двух выходных интерфейсов имеет задержку в 10 микросекунд, что дает нам суммарную задержку в 20 микросекунд. Однако мы хотим, чтобы наша единица измерения была в десятках микросекунд. Поэтому мы делим 20 микросекунд на 10, что дает нам 2 десятка микросекунд. Теперь у нас есть два необходимых значения для нашей формулы: пропускная способность = 1 000 000 Кбит/с и задержка = 2 десятка микросекунд. Теперь давайте добавим эти значения в нашу формулу:
Вычисленное значение показателя EIGRP составляет 3072. Теперь давайте посмотрим, является ли это фактической метрикой, появляющейся в таблице топологии EIGRP маршрутизатора OFF1. Выходные данные команды show ip eigrp topology, выведенные на маршрутизаторе OFF1, показаны в следующем примере.
Проверка метрики EIGRP для сети 198.51.100.0/24 на маршрутизаторе OFF1
Как и предполагалось, метрика (также известная как допустимое расстояние) от маршрутизатора OFF1 до Сети 198.51.100.0 /24 через маршрутизатор OFF2 составляет 3072. Напомним, что в этом примере мы использовали значения K по умолчанию, что также является обычной практикой в реальном мире. Однако для целей проектирования мы можем манипулировать K-значениями. Например, если мы обеспокоены надежностью каналом связи или нагрузкой, которую мы могли бы испытать на линии, мы можем манипулировать нашими K-значениями таким образом, чтобы EIGRP начал бы рассматривать надежность и/или нагрузку в своем метрическом расчете. В следующей статье мы рассмотрим, как мы можем изменить эти K - значения в EIGRP по умолчанию.
В связи с проблемами безопасности в протоколе 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
(Ожидающий)
(Ожидающий)
(Ожидающий)
Почитайте предыдущую статью про криптографический обмен ключами.
Предположим, вы хотите отправить большой текстовый файл или даже изображение, и позволить получателям подтвердить, что он исходит именно от вас. Что делать, если рассматриваемые данные очень большие? Или что, если данные нужно сжать для эффективной передачи? Существует естественный конфликт между криптографическими алгоритмами и сжатием. Криптографические алгоритмы пытаются произвести максимально случайный вывод, а алгоритмы сжатия пытаются воспользоваться преимуществом неслучайности данных для сжатия данных до меньшего размера. Или, возможно, вы хотите, чтобы информация была прочитана кем-либо, кто хочет ее прочитать, что означает, что не нужно ее шифровать, но вы хотите, чтобы получатели могли проверить, что вы ее передали.
Криптографические хэши предназначены для решения этих проблем. Возможно, вы уже заметили по крайней мере одно сходство между идеей хеширования и криптографического алгоритма. В частности, хэш предназначен для получения очень большого фрагмента данных и создания представления фиксированной длины, поэтому на выходе для широкого диапазона входных данных очень мало конфликтов. Это очень похоже на концепцию максимально близкого к случайному выходу для любого ввода, необходимого для криптографического алгоритма. Еще одно сходство, о котором стоит упомянуть, заключается в том, что хэш-алгоритмы и криптографические алгоритмы работают лучше с очень редко заполненным входным пространством.
Криптографический хеш просто заменяет обычную хеш-функцию криптографической функцией. В этом случае хэш может быть вычислен и отправлен вместе с данными.
Криптографические хэши могут использоваться либо с системами с симметричными ключами, либо с системами с открытым ключом, но обычно они используются с системами с открытым ключом.
Сокрытие информации о пользователе
Возвращаясь к начальным статьям, еще одна проблема безопасности - это исчерпание данных. В случае отдельных пользователей исчерпание данных можно использовать для отслеживания того, что пользователи делают, пока они находятся в сети (а не только для процессов). Например:
Если вы всегда носите с собой сотовый телефон, можно отслеживать перемещение Media Access Control (MAC), когда он перемещается между точками беспроводного подключения, чтобы отслеживать ваши физические перемещения.
Поскольку большинство потоков данных не симметричны - данные проходят через большие пакеты, а подтверждения передаются через небольшие пакеты, наблюдатель может обнаружить, когда вы выгружаете и скачиваете данные, и, возможно, даже когда вы выполняете небольшие транзакции. В сочетании с целевым сервером эта информация может дать хорошую информацию о вашем поведении как пользователя в конкретной ситуации или с течением времени. Этот и многие другие виды анализа трафика могут выполняться даже для зашифрованного трафика.
Когда вы переходите с веб-сайта на веб-сайт, наблюдатель может отслеживать, сколько времени вы тратите на каждый из них, что вы нажимаете, как вы перешли на следующий сайт, что вы искали, какие сайты вы открываете в любое время и т. д. информация может многое рассказать о вас как о личности, о том, чего вы пытаетесь достичь, и о других личных факторах.
Рандомизация MAC-адресов
Institute of Electrical and Electronic Engineers (IEEE) первоначально разработал адресное пространство MAC-48 для назначения производителями сетевых интерфейсов. Эти адреса затем будут использоваться "как есть" производителями сетевого оборудования, поэтому каждая часть оборудования будет иметь фиксированный, неизменный аппаратный адрес. Этот процесс был разработан задолго до того, как сотовые телефоны появились на горизонте, и до того, как конфиденциальность стала проблемой.
В современном мире это означает, что за одним устройством можно следить независимо от того, где оно подключено к сети. Многие пользователи считают это неприемлемым, особенно потому, что не только провайдер может отслеживать эту информацию, но и любой, кто имеет возможность прослушивать беспроводной сигнал. Один из способов решить эту проблему-позволить устройству регулярно менять свой MAC-адрес, даже, возможно, используя другой MAC-адрес в каждом пакете. Поскольку сторонний пользователь (прослушиватель) вне сети провайдера не может "угадать" следующий MAC-адрес, который будет использоваться любым устройством, он не может отслеживать конкретное устройство. Устройство, использующее рандомизацию MAC-адресов, также будет использовать другой MAC-адрес в каждой сети, к которой оно присоединяется, поэтому оно не будет отслеживаться в нескольких сетях.
Существуют атаки на рандомизацию MAC-адресов, в основном сосредоточенные вокруг аутентификации пользователя для использования сети. Большинство систем аутентификации полагаются на MAC-адрес, поскольку он запрограммирован в устройстве, чтобы идентифицировать устройство и, в свою очередь, пользователя. Как только MAC-адрес больше не является неизменным идентификатором, должно быть какое-то другое решение. Места, где рандомизация MAC-адресов может быть атакована, - это
Время (timing): если устройство собирается изменить свой MAC-адрес, оно должно каким-то образом сообщить другому абоненту беспроводного соединения об этих изменениях, чтобы канал между подключенным устройством и базовой станцией мог оставаться жизнеспособным. Должна быть какая-то согласованная система синхронизации, чтобы изменяющийся MAC-адрес мог продолжать обмен данными при изменении. Если злоумышленник может определить, когда произойдет это изменение, он сможет посмотреть в нужное время и обнаружить новый MAC-адрес, который принимает устройство.
Порядковые номера (Sequence numbers): как и во всех транспортных системах, должен быть какой-то способ определить, все ли пакеты были получены или отброшены. Злоумышленник может отслеживать порядковые номера, используемые для отслеживания доставки и подтверждения пакетов. В сочетании с только что отмеченной атакой по времени это может обеспечить довольно точную идентификацию конкретного устройства при изменении MAC-адреса.
Отпечатки информационных элементов (Information element fingerprints): каждое мобильное устройство имеет набор поддерживаемых функций, таких как установленные браузеры, расширения, приложения и дополнительное оборудование. Поскольку каждый пользователь уникален, набор приложений, которые он использует, также, вероятно, будет довольно уникальным, создавая "отпечаток" возможностей, которые будут сообщаться через информационный элемент в ответ на зонды от базовой станции.
Отпечатки идентификатора набора услуг (SSID): каждое устройство хранит список сетей, к которым оно может подключиться в настоящее время, и (потенциально) сетей, которые оно могло достичь в какой-то момент в прошлом. Этот список, вероятно, будет довольно уникальным и, следовательно, может выступать в качестве идентификатора устройства.
Хотя каждый из этих элементов может обеспечить определенный уровень уникальности на уровне устройства, комбинация этих элементов может быть очень близка к идентификации конкретного устройства достаточно часто, чтобы быть практически полезной при отслеживании любого конкретного пользователя, подключающегося к беспроводной сети.
Это не означает, что рандомизация MAC-адресов бесполезна, это скорее один шаг в сохранении конфиденциальности пользователя при подключении к беспроводной сети.
Луковая маршрутизация
Луковая маршрутизация - это механизм, используемый для маскировки пути, а также шифрования пользовательского трафика, проходящего через сеть. Рисунок 1 используется для демонстрации.
На рисунке 1 хост А хочет безопасно отправить некоторый трафик на K, чтобы ни один другой узел в сети не мог видеть соединение между хостом и сервером, и чтобы ни один злоумышленник не мог видеть открытый текст. Чтобы выполнить это с помощью луковой маршрутизации, A выполняет следующие действия:
Он использует службу для поиска набора узлов, которые могут соединяться между собой, и предоставления пути к серверу K. Предположим, что этот набор узлов включает [B, D, G], хотя на рисунке они показаны как маршрутизаторы, скорее всего, это программные маршрутизаторы, работающие на хостах, а не выделенные сетевые устройства. Хост A сначала найдет открытый ключ B и использует эту информацию для создания сеанса с шифрованием с симметричным ключом B.
Как только этот сеанс установлен, A затем найдет открытый ключ D и использует эту информацию для обмена набором симметричных ключей с D, наконец, построит сеанс с D, используя этот симметричный секретный ключ для шифрования защищенного канала. Важно отметить, что с точки зрения D, это сеанс с B, а не с A. Хост A просто инструктирует B выполнить эти действия от его имени, а не выполнять их напрямую. Это означает, что D не знает, что A является отправителем трафика, он знает только, что трафик исходит от B и передается оттуда по зашифрованному каналу.
Как только этот сеанс будет установлен, A затем проинструктирует D настроить сеанс с G таким же образом, как он проинструктировал B настроить сеанс с D. D теперь знает, что пункт назначения-G, но не знает, куда будет направлен трафик G.
У хоста A теперь есть безопасный путь к K со следующими свойствами:
Трафик между каждой парой узлов на пути шифруется с помощью другого симметричного закрытого ключа. Злоумышленник, который разрывает соединение между одной парой узлов на пути, по-прежнему не может наблюдать трафик, передаваемый между узлами в другом месте на пути.
Выходной узел, которым является G, знает пункт назначения, но не знает источник трафика.
Входной узел, которым является B, знает источник трафика, но не пункт назначения.
В такой сети только А знает полный путь между собой и местом назначения. Промежуточные узлы даже не знают, сколько узлов находится в пути-они знают о предыдущем и следующем узлах. Основная форма атаки на такую систему состоит в том, чтобы захватить как можно больше выходных узлов, чтобы вы могли наблюдать трафик, выходящий из всей сети, и соотносить его обратно в полный поток информации.
Атака "Человек посередине" (Man-in-the-Middle)
Любой вид безопасности должен не только изучать, как вы можете защитить информацию, но также учитывать различные способы, которыми вы можете вызвать сбой защиты данных. Поскольку ни одна система не является идеальной, всегда найдется способ успешно атаковать систему. Если вам известны виды атак, которые могут быть успешно запущены против системы безопасной передачи данных, вы можете попытаться спроектировать сеть и среду таким образом, чтобы предотвратить использование этих атак. Атаки "человек посередине" (MitM) достаточно распространены, и их стоит рассмотреть более подробно. Рисунок 2 демонстрирует это.
Рисунок 2-б аналогичен рисунку 2-а с одним дополнением: между хостом A и сервером C расположен хост B, который хочет начать зашифрованный сеанс. Некоторыми способами, либо подменяя IP-адрес C, либо изменяя записи службы доменных имен (DNS), чтобы имя C преобразовывалось в адрес B, или, возможно, даже изменяя систему маршрутизации, чтобы трафик, который должен быть доставлен в C, вместо этого доставлялся в B, злоумышленник заставил B принять трафик, исходящий из A и предназначенный для C. На рисунке 2-б:
Хост A отправляет полуслучайное число, называемое одноразовым номером, в C. Эту информацию получает B.
Хост B, который злоумышленник использует в качестве MitM, передает этот одноразовый номер на узел C таким образом, что создается впечатление, что пакет действительно исходит от узла A. В этот момент злоумышленник знает одноразовый идентификатор, зашифрованный A. Злоумышленник не знает закрытый ключ A, но имеет доступ ко всему, что A отправляет зашифрованным с помощью закрытого ключа A.
Сервер C также отправляет ответ с зашифрованным одноразовым случайным числом. B получает это и записывает.
Хост B передает одноразовое случайное число, полученное от C, на A. Хост A по-прежнему будет считать, что этот пакет пришел непосредственно от C.
Хост B вычисляет закрытый ключ с помощью A, как если бы это был C.
Хост B вычисляет закрытый ключ с помощью C, как если бы это был A.
Любой трафик, который A отправляет в C, будет получен B, что:
Расшифруйте данные, которые A передал, используя закрытый ключ, вычисленный на шаге 5 на рисунке 2-б.
Зашифруйте данные, которые A передал, используя закрытый ключ, вычисленный на шаге 6 на рисунке 2-б, и передайте их C.
Во время этого процесса злоумышленник на B имеет доступ ко всему потоку в виде открытого текста между A и C. Ни A, ни C не осознают, что они оба построили зашифрованный сеанс с B, а не друг с другом. Такого рода атаки MitM очень сложно предотвратить и обнаружить.