Tdi драйвер что это
The TDI_CONNECTION_INFO structure defines the structure of the information returned for a TDI_QUERY_INFORMATION request in which IrpSp->Parameters is cast to a pointer to a TDI_REQUEST_KERNEL_QUERY_INFORMATION structure. The request sets the QueryType member of TDI_REQUEST_KERNEL_QUERY_INFORMATION to the TDI_QUERY_CONNECTION_INFO query type.
Syntax
Members
State
Specifies the current state of the connection on the network.
Event
Specifies the type of event the TDI driver most recently indicated to the client. The value is expressed as a TDI_EVENT_XXX code.
TransmittedTsdus
Specifies the number of TSDUs transmitted on the connection endpoint.
ReceivedTsdus
Specifies the number of TSDUs received on the connection endpoint.
TransmissionErrors
Specifies the number of TSDUs that have had an error during transmission on the connection endpoint.
ReceiveErrors
Specifies the number of TSDUs that have had an error during reception on the connection endpoint.
Throughput
Specifies the estimated throughput on the connection, expressed in bytes per second, for sends and receives. Zero indicates that the driver cannot calculate the throughput.
Delay
Specifies the estimated delay on the connection, expressed as a negative value. Delay, which is essentially constant regardless of packet size, affects the transmission time of each TSDU sent to the remote node.
SendBufferSize
If the transport buffers sends internally, specifies the size in bytes of its send buffer. Otherwise, this member is zero.
ReceiveBufferSize
If the transport buffers receives internally, specifies the size in bytes of its receive buffer. Otherwise, this member is zero.
Unreliable
Specifies TRUE if the transport determines that the connection has become unreliable. The transport is likely to send a disconnection event to its client if this member is TRUE, and sends or receives on this connection are likely to fail.
Remarks
A kernel-mode client that has opened a file object representing a connection with ZwCreateFile can make a query to determine the current state of its local connection. Such a client sets up an IRP with TdiBuildQueryInformation, passing in the QType TDI_QUERY_CONNECTION_INFO, and submits the IRP to the underlying transport to get this information.
TDI_CONNECTION_INFO defines the format in which the transport returns the requested information for such a query.
Until a client has established an endpoint-to-endpoint connection with a remote-node peer, only a subset of this information is potentially useful to the client, such as the SendBufferSize and ReceiveBufferSize of an underlying transport that supports internal buffering. A TDI transport can simply return its default or initialization values for members that are not yet relevant or even fail the query-information request if an endpoint-to-endpoint connection is not yet established.
Consequently, kernel-mode clients usually submit this request to their transports after making an endpoint-to-endpoint connection with a remote-node peer. For example, the client can estimate the transmission time for sends over the network using the Delay and Throughput values returned for this query, assuming the underlying transport does not return a zero for either. The estimated time to transmit a TSDU of size n bytes can be calculated as SendTime = Delay+ ( n * Throughput).
Note The TDI feature is deprecated and will be removed in future versions of Microsoft Windows. Depending on how you use TDI, use either the Winsock Kernel (WSK) or Windows Filtering Platform (WFP). For more information about WFP and WSK, see Windows Filtering Platform and Winsock Kernel. For a Windows Core Networking blog entry about WSK and TDI, see Introduction to Winsock Kernel (WSK).
Сетевые драйверы можно разделить на 2 категории: TDI-драйверы (Transport Driver Interface) и NDIS-драйверы (Network Driver Interface Specification). TDI-драйверы — это высокоуровневые драйверы, например, SMB-клиент, SMB-сервер, обертки SMB (NFFS, MSFS) и т.п. Мы с Вами рассмотрим NDIS-драйвера. NDIS — это специальный драйвер (ему соответствует файл ndis.sys), который содержит функции, используемые низкоуровневыми сетевыми драйверами. NDIS как бы обволакивает низкоуровневые сетевые драйверы и является посредником в их общении между собой и с железом. По сути NDIS можно считать третьим ядром Windows. Чтобы более четко уяснить себе что из себя представляет NDIS можно посмтореть на следующую картинку:
- Минипорт-драйверы (драйверы адаптера)
- Промежуточные драйверы (например, psched.sys)
- Драйверы протокола (например, tcpip.sys)
Минипорт-драйверы
- производит инициализацию своего устройства (адаптера)
- создание /включение/выключение/удаление сетевых подключений
- выдача клиенту или изменение параметров адаптера
- отправка пакетов
- получение пакетов
- оповещение ОС о состоянии адаптера
- перезагрузка и остановка адаптера
Минипорт-драйверы бывают «Connectionless» (например, драйвер Ethernet-адаптера) и «Сonnection-oriented» (например, драйвер модема). У Сonnection-oriented драйверов система коллбэков чуть сложнее, в нее входят обработчики событий, связанных с подключением к каналу связи, отключением от канала, выбором канала (для беспроводных адаптеров) и т.п. Для некоторых операций Сonnection-oriented драйверы вызывают специальные функции NDIS, отличающиеся префиксом «Со» в имени (например, вместо NdisMIndicateReceivePacket Сonnection-oriented драйвер должен вызывать NdisMColndicateReceivePacket).
Каждый коллбэк выполняет свою задачу: выдача информации, отправка данных, прием данных и т.п. Подробнее можно посмотреть в хелпе к WDK (DDK). Там можно получить полную информацию о коллбэках.
Драйверы протоколов могут передоверять минипорт-драйверу (при условии, что минипорт-драйвер это умеет — либо сам, либо адаптер умеет это делать на аппаратном уровне) некоторые свои функции (например, разграничить контрольную сумму или цифровую подпись IP-пакета или принять решение, как фрагментировать большой ТСP-пакет). Это значительно повышает производитель сети.
- LBFO (Load Balancing and Fail Over) — позволяет понимающим его адаптерам распределять между собой исходящий трафик и исправлять ошибки друг друга. Впрочем, что имеет смысл только на backbone routers (центральных маршрутизаторах больших сетей), на которые редко ставят Windows
- FFP (Fast Forwarding Path) — позволяет понимающим его адаптерам маршрутизировать/фильтровать пакеты чисто аппаратно, вообще без участия ОС и не нагружая основные процессоры компьютера
Промежуточные драйверы
Промежуточный драйвер сверху виден как минипорт-драйвер (смотрим на картинку), т.е. как бы виртуальный адаптер, а снизу — как драйвер протокола (снова смотрим на картинку), как бы виртуальный протокол. Как частный случай, возможна ситуация, когда промежуточный драйвер виден только сверху.
- организуют «справедливый» доступ разных клиентских программ к адаптерам дабы программы не мешали друг другу
- фильтруют и перехватывают трафик
- маршрутизируют пакеты из одной сети в другую, если эти сети различаются (например, Ethernet и WI-FI)
Драйверы протоколов
Драйверы протокола — это самый верхний уровень спецификации NDIS. Эти драйверы занимаются тем, что выделяют ресурсы для соответствующих пакетов, копируют данные приложений в пакеты и передают их драйверам нижнего уровня. Также драйверы протоколов обеспечивают интерфейс для получения пакетов от нижележащих драйверов.
К драйверам протоколов относятся и драйверы транспорта, реализующие стек сетевых протоколов, такой как например TCP/IP (tspip.sys).
Если пост будет интересен читателям, то в следующих постах можно конкретно на примере написать свой сниферо-подобный промежуточный драйвер или также описать как написать каждый из типов драйверов (минипорта, промежуточный или протокола).
Как уважаемый хабрапользователь наверняка знает, «драйвер устройства» — это компьютерная программа управляющая строго определенным типом устройства, подключенным к или входящим в состав любого настольного или переносного компьютера.
Основная задача любого драйвера – это предоставление софтового интерфейса для управления устройством, с помощью которого операционная система и другие компьютерные программы получают доступ к функциям данного устройства, «не зная» как конкретно оно используется и работает.
Обычно драйвер общается с устройством через шину или коммуникационную подсистему, к которой подключено непосредственное устройство. Когда программа вызывает процедуру (очередность операций) драйвера – он направляет команды на само устройство. Как только устройство выполнило процедуру («рутину»), данные посылаются обратно в драйвер и уже оттуда в ОС.
Любой драйвер является зависимым от самого устройства и специфичен для каждой операционной системы. Обычно драйверы предоставляют схему прерывания для обработки асинхронных процедур в интерфейсе, зависимом от времени ее исполнения.
Любая операционная система обладает «картой устройств» (которую мы видим в диспетчере устройств), для каждого из которых необходим специфический драйвер. Исключения составляют лишь центральный процессор и оперативная память, которой управляет непосредственно ОС. Для всего остального нужен драйвер, который переводит команды операционной системы в последовательность прерываний – пресловутый «двоичный код».
Как работает драйвер и для чего он нужен?
Основное назначение драйвера – это упрощение процесса программирования работы с устройством.
Он служит «переводчиком» между хардовым (железным) интерфейсом и приложениями или операционными системами, которые их используют. Разработчики могут писать, с помощью драйверов, высокоуровневые приложения и программы не вдаваясь в подробности низкоуровневого функционала каждого из необходимых устройств в отдельности.
Как уже упоминалось, драйвер специфичен для каждого устройства. Он «понимает» все операции, которые устройство может выполнять, а также протокол, с помощью которого происходит взаимодействие между софтовой и железной частью. И, естественно, управляется операционной системой, в которой выполняет конкретной приложение либо отдельная функция самой ОС («печать с помощью принтера»).
Если вы хотите отформатировать жесткий диск, то, упрощенно, этот процесс выглядит следующим образом и имеет определенную последовательность: (1) сначала ОС отправляет команду в драйвер устройства используя команду, которую понимает и драйвер, и операционная система. (2) После этого драйвер конкретного устройства переводит команду в формат, который понимает уже только устройство. (3) Жесткий диск форматирует себя, возвращает результат драйверу, который уже впоследствии переводит эту команду на «язык» операционной системы и выдает результат её пользователю (4).
Как создается драйвер устройства
Для каждого устройства существует свой строгий порядок выполнения команд, называемой «инструкцией». Не зная инструкцию к устройству, невозможно написать для него драйвер, так как низкоуровневые машинные команды являются двоичным кодом (прерываниями) которые на выходе отправляют в драйвер результат, полученный в ходе выполнения этой самой инструкции.
При создании драйвера для Линукса, вам необходимо знать не только тип шины и ее адрес, но и схематику самого устройства, а также весь набор электрических прерываний, в ходе исполнения которых устройство отдает результат драйверу.
Написание любого драйвера начинается с его «скелета» — то есть самых основных команд вроде «включения/выключения» и заканчивая специфическими для данного устройства параметрами.
И чем драйвер не является
Часто драйвер устройства сравнивается с другими программами, выполняющими роль «посредника» между софтом и/или железом. Для того, чтобы расставить точки над «i», уточняем:
- Драйвер не является интерпретатором, так как не исполняется напрямую в софтовом слое приложения или операционной системы.
- Драйвер не является компилятором, так как не переводит команды из одного софтового слоя в другой, такой же.
Ну и на правах рекламы – вы всегда знаете, где скачать новейшие драйвера для любых устройств под ОС Windows.
Описание ситуации с ошибкой AFD ID 16001
Как я и писал выше, у меня есть гипервизор VMware ESXI 6.5, на котором есть виртуальная машина с установленной Windows Server 2012 R2. На данной виртуальной машине развернута роль RDSH, являющийся членом RDS фермы. Ранее данная виртуальная машина приходила в такое состояние, что пользователи не могли выйти из системы, через кнопку пуск, их сессии просто зависали, в результате чего они не могли подключиться заново. Я вам там приводил ряд мер, которые давали некоторые улучшения в данном вопросе, но сегодня данная виртуальная машина опять попала в такое состояние. После принудительной перезагрузки, я обнаружил уже новое предупреждение, которое косвенно может влиять на работу сервиса, а именно было предупреждение:
Источник AFD, Код события ID 16001: Обнаружен фильтр TDI (\Driver\vnetflt). Он не сертифицирован корпорацией Майкрософт и может привести к нестабильной работе системы
Что такое драйвер vnetflt
Мне стало интересно, что это за драйвер, который может приводить мою операционную систему к нерабочему состоянию. Я прекрасно помнил, что Windows все свои драйвера хранит в одной папке C:\Windows\System32\Drivers. Если зайти в свойства vnetflt.sys и открыть вкладку "Подробно", то можно обнаружить, что его разработчик Vmware и описание у драйвера vnetflt.sys показывает "VMware Guest Introspection Network Fit".
Оказывается драйвер vnetflt.sys входит в состав драйверов интеграции VMware Tools и поддерживает функцию мониторинга активности NSX для vSphere. Однако он не используется никакими функциональными возможностями конечной точки vShield.
VMware NSX - это семейство программных продуктов для виртуальных сетей и безопасности, созданное на основе интеллектуальной собственности VMware vCloud Networking and Security (vCNS) и платформы сетевой виртуализации (NVP) Nicira.
Программно-определяемые сети ( SDN ) NSX являются частью концепции программно-определяемых центров обработки данных (SDDC) VMware, которая предлагает облачные вычисления на основе технологий виртуализации VMware. Заявленная цель VMware с NSX - предоставить виртуальные сетевые среды без интерфейса командной строки (CLI) или другого прямого вмешательства администратора. Виртуализация сети абстрагирует сетевые операции от базового оборудования на уровень распределенной виртуализации, так же как виртуализация серверов делает для вычислительной мощности и операционных систем (ОС). VMware vCNS виртуализирует уровень 4-7 ( L4-L7 ) сети. NVP от Nicira виртуализирует сетевую структуру, уровень 2 (L2) и уровень 3 (L3).
NSX предоставляет логические брандмауэры, коммутаторы, маршрутизаторы, порты и другие сетевые элементы для обеспечения виртуальных сетей среди независимых от поставщиков, гипервизоров, систем управления облаком и связанного сетевого оборудования. Он также поддерживает внешние сети и экосистемные услуги безопасности.
Важные особенности NSX
- Коммутация: логические коммутаторы NSX используют уникальные сетевые идентификаторы Virtual Extensible LAN (VXLAN) для создания логического расширения наложения для сети L2, к которому затем могут быть логически подключены приложения и виртуальные машины-арендаторы (VM). Эти логические широковещательные домены обеспечивают большую гибкость и ускоряют развертывание, обеспечивая при этом характеристики виртуальной ЛВС (VLAN) без риска разрастания.
- Маршрутизация: NSX выполняет маршрутизацию как с логическими распределенными маршрутизаторами, которые создают маршруты между виртуальными сетями в ядре гипервизора и физическими маршрутизаторами для масштабной маршрутизации с режимом активный-активным и переключением при сбое.
- Распределенный межсетевой экран: распределенный межсетевой экран NSX представляет собой встроенный в ядро гипервизор межсетевой экран, который распространяется по узлу ESXi. Сетевой администратор может создавать настраиваемые политики брандмауэра, которые применяются на уровне виртуальной сетевой карты (vNIC), для обеспечения служб брандмауэра с отслеживанием состояния для виртуальных машин и улучшения видимости и контроля для виртуализированных сетей и рабочих нагрузок.
- Балансировка нагрузки : NSX предлагает балансировщик нагрузки L4-L7, который перехватывает, транслирует и манипулирует сетевым трафиком для повышения доступности и масштабируемости корпоративных приложений. Балансировщик нагрузки NSX включает поддержку разгрузки Secure Sockets Layer (SSL) для сквозной проверки и проверки работоспособности сервера. Балансировщик нагрузки L4 предлагает балансировку нагрузки на основе пакетов, которая отправляет пакет на определенный сервер после его манипулирования; Балансировщик нагрузки L7 предлагает балансировку нагрузки на основе сокетов, которая устанавливает клиентские и серверные соединения для одного запроса.
- Виртуальная частная сеть (VPN): NSX включает в себя возможности VPN для межсетевого взаимодействия и удаленного доступа, а также неуправляемую VPN для служб облачных шлюзов.
- Шлюз NSX Edge: Шлюз NSX Edge представляет собой виртуальную машину, которая ведет себя как устройство для выполнения маршрутизации L3, межсетевого экрана, виртуальных частных сетей «сайт-сайт», балансировки нагрузки и многого другого. Эта функция также предлагает поддержку мостов VXLAN к VLAN для беспрепятственного подключения к физическим нагрузкам.
- Интерфейс прикладного программирования (API): NSX использует API на основе представления о состоянии (REST API), чтобы упростить интеграцию сторонних продуктов и услуг и интегрировать NSX с облачным управлением для дополнительных возможностей автоматизации.
- Операции: Собственные возможности операций включают в себя центральный интерфейс командной строки, анализатор портов коммутатора (SPAN), экспорт информации о потоках IP (IPFIX), диспетчер правил приложений (ARM), мониторинг конечных точек и интеграцию с VMware vRealize Suite для упреждающего мониторинга, аналитики и устранения неполадок.
- Динамическая политика безопасности: NSX Service Composer позволяет сетевому администратору предоставлять и назначать приложениям сетевые службы и службы безопасности. Администратор также может использовать Service Composer для создания динамических групп безопасности с настраиваемыми фильтрами, такими как объекты и теги VMware vCenter, тип ОС и роли Active Directory (AD).
- Управление облаком: NSX изначально интегрируется с vRealize Automation и OpenStack для управления облаком.
- Кросс-vCenter Networking and Security (Cross-VC NSX): эта возможность масштабирует NSX vSphere через границы vCenter и центров обработки данных. Это позволяет сетевому администратору обращаться к пулу емкости между vCenters, упрощать миграцию центра обработки данных, выполнять vMotions на большие расстояния и выполнять аварийное восстановление (DR).
- Управление журналом : NSX интегрируется с vRealize Log Insight, который получает записи журналов от хостов ESXi, использует пакеты контента для обработки информации, содержащейся в каждой записи журнала, и выявляет проблемы в развертывании NSX.
NSX варианты использования
Согласно VMware, три основных варианта использования, стимулирующих внедрение NSX, - это микросегментация, автоматизация IT и DR. Эти варианты использования направлены на решение проблем, обычно связанных с виртуализацией сети, таких как низкая производительность трафика и недостаточная безопасность.
Первый из этих вариантов использования, микросегментация, касается безопасности сети. Микросегментация использует общую сетевую практику сегментации и применяет ее на детальном уровне. Это позволяет сетевому администратору установить периметр безопасности с нулевым доверием вокруг определенного набора ресурсов - обычно рабочих нагрузок или сегментов сети - и добавить функциональность брандмауэра east-west в центр обработки данных. NSX также позволяет администратору создавать дополнительные политики безопасности для определенных рабочих нагрузок, независимо от того, где они находятся в топологии сети.
NSX использует автоматизацию центра обработки данных для быстрой и гибкой настройки сети. Сетевой администратор может быстро обеспечить новую сеть или сетевой сегмент рабочими нагрузками, ресурсами и политиками безопасности, уже привязанными к нему. Это устраняет узкие места и делает NSX идеальным для тестирования приложений и работы с неустойчивыми рабочими нагрузками, которые NSX может логически изолировать в одной и той же физической сети.
Автоматизация также важна для DR. NSX интегрируется с инструментами оркестровки, такими как vSphere Site Recovery Manager (SRM) , который автоматизирует аварийное переключение и DR. В сочетании с NSX SRM можно использовать для репликации хранилища, а также для управления и тестирования планов восстановления. SRM также интегрируется с Cross-VC NSX. Представленный в NSX 6.2, Cross-VC NSX обеспечивает логическую сеть и безопасность для нескольких vCenters, что упрощает применение согласованных политик безопасности без необходимости ручного вмешательства. При использовании в сочетании с Cross-VC NSX SRM автоматически сопоставляет универсальные сети через защищенные сайты и сайты восстановления.
Как отключить или удалить vnetflt.sys
Чтобы отключить TDI vShield Endpoint в Windows, вам необходимо открыть редактор реестра Windows и перейти по пути:
Находим тут ключ Start и меняем его значение с 2 на 4. После чего сохраняем настройки и перезагружаем компьютер или сервер. После этого в логах Windows у вас не будет предупреждения ID 16001.
Я же больше придерживаюсь мнения, что если вы что-то не используете, значит это лучше отключить, а если можно, то удалить. Я предлагаю вам удалить компонент TDI vShield Endpoint. Для этого вы можете либо в момент обновления VMware Tools его не выбирать или же можете изменить установленные драйвера, для этого откройте панель управления, раздел "Программы и компоненты"
Этот драйвер можно удалить только в том случае, если на виртуальной машине установлена версия VMware не менее 10.x (Где скачать последнюю версию VMTools читайте по ссылке)
Выбираем VMware Tools и нажимаем кнопку "Изменить".
В разделе "VMCI Drever" снимите галки "NSX File Introspection Driver" и "NSX Network Introspection Driver", после чего нажимаем "Next". В результате чего у вас будет переустановлен Vmware Tools, но уже без данных компонентов. Перезагружаем вашу систему и проверяем отсутствие предупреждений ID 16001.
Так же хочу отметить, чтобы вы проверили в настройках своей виртуальной машины, что у вас в качестве сетевого адаптера используется тип VMXNET3. (Про типы сетевых адаптеров VMware ESXI читайте по ссылке)
Windows NT предоставляет для взаимосвязи между транспортными драйверами и TDI-клиентами уровня ядра, такими как эмуляторы сетевых интерфейсов, редиректоры, серверы, единый программный интерфейс, называемый интерфейсом транспортных драйверов (Transport Driver Interface, TDI).
Изначально этот интерфейс планировалось использовать в пользовательском режиме работы ОС. В окончательном варианте интерфейс стал работать в режиме ядра, однако все еще может быть использован напрямую из пользовательского уровня. TDI предоставляется верхней частью любого транспортного стека протоколов Windows NT. TDI обеспечивает независимость TDI-клиентов от используемых ими транспортов. TDI поддерживает передачу как с установлением постоянного сеанса (виртуальная цепь), так и без него (датаграммы).
Требование, чтобы все драйверы транспорта предоставляли единый общий интерфейс TDI, облегчает задачу их разработки, а также разработки TDI-клиентов, потому что только этот интерфейс необходимо запрограммировать.
Так как TDI является относительно новым сетевым интерфейсом, и большинство приложений разработаны для использования других существующих стандартных интерфейсов, таких как NetBIOS и WinSockets, то Windows NT включает эмуляторы для этих двух популярных интерфейсов. Части уровня ядра этих эмуляторов, являющиеся драйверами файловых систем, отображают родные функции с соответствующими параметрами в одну или несколько TDI-функций, а затем вызывают соответствующие драйверы транспортов через TDI.
Интерфейс TDI включает следующее:
- Множество стандартных диспетчерских точек входа, обеспечиваемых транспортным драйвером, к которому TDI-клиент может обратиться с запросом ввода/вывода.
- Множество процедур обратного вызова, экспортируемых любым TDI-клиентом и регистрируемых транспортным драйвером, для получения TDI-клиентом уведомления о произошедшем сетевом событии.
- Параметры, структуры, lOCTLs и правила, ассоциированные с процедурами транспорта и его клиента.
- Множество функций вида TdiXxx, которые транспорт и его клиент могут вызывать для взаимодействия друг с другом.
- Множество макросов и функций вида TdiBuildXxx, которые TDI-клиент может использовать, чтобы обеспечить принятие запросов нижележащим транспортом.
Программная модель TDI очень похожа на модель Winsocket. TDI-клиенты реализуют следующие шаги для установления соединения с удаленным сервером:
Читайте также: