Tdi драйвер что это
Краткий обзор драйверов спецификации NDIS
Сетевые драйверы
Сетевые драйверы можно разделить на 2 категории: TDI-драйверы (Transport Driver Interface) и NDIS-драйверы (Network Driver Interface Specification). TDI-драйверы — это высокоуровневые драйверы, например, SMB-клиент, SMB-сервер, обертки SMB (NFFS, MSFS) и т.п. Мы с Вами рассмотрим NDIS-драйвера. NDIS — это специальный драйвер (ему соответствует файл ndis.sys), который содержит функции, используемые низкоуровневыми сетевыми драйверами. NDIS как бы обволакивает низкоуровневые сетевые драйверы и является посредником в их общении между собой и с железом. По сути NDIS можно считать третьим ядром Windows. Чтобы более четко уяснить себе что из себя представляет NDIS можно посмтореть на следующую картинку:
Минипорт-драйверы
Минипорт-драйверы бывают «Connectionless» (например, драйвер Ethernet-адаптера) и «Сonnection-oriented» (например, драйвер модема). У Сonnection-oriented драйверов система коллбэков чуть сложнее, в нее входят обработчики событий, связанных с подключением к каналу связи, отключением от канала, выбором канала (для беспроводных адаптеров) и т.п. Для некоторых операций Сonnection-oriented драйверы вызывают специальные функции NDIS, отличающиеся префиксом «Со» в имени (например, вместо NdisMIndicateReceivePacket Сonnection-oriented драйвер должен вызывать NdisMColndicateReceivePacket).
Каждый коллбэк выполняет свою задачу: выдача информации, отправка данных, прием данных и т.п. Подробнее можно посмотреть в хелпе к WDK (DDK). Там можно получить полную информацию о коллбэках.
Драйверы протоколов могут передоверять минипорт-драйверу (при условии, что минипорт-драйвер это умеет — либо сам, либо адаптер умеет это делать на аппаратном уровне) некоторые свои функции (например, разграничить контрольную сумму или цифровую подпись IP-пакета или принять решение, как фрагментировать большой ТСP-пакет). Это значительно повышает производитель сети.
Промежуточные драйверы
Промежуточный драйвер сверху виден как минипорт-драйвер (смотрим на картинку), т.е. как бы виртуальный адаптер, а снизу — как драйвер протокола (снова смотрим на картинку), как бы виртуальный протокол. Как частный случай, возможна ситуация, когда промежуточный драйвер виден только сверху.
Драйверы протоколов
Драйверы протокола — это самый верхний уровень спецификации NDIS. Эти драйверы занимаются тем, что выделяют ресурсы для соответствующих пакетов, копируют данные приложений в пакеты и передают их драйверам нижнего уровня. Также драйверы протоколов обеспечивают интерфейс для получения пакетов от нижележащих драйверов.
К драйверам протоколов относятся и драйверы транспорта, реализующие стек сетевых протоколов, такой как например TCP/IP (tspip.sys).
Если пост будет интересен читателям, то в следующих постах можно конкретно на примере написать свой сниферо-подобный промежуточный драйвер или также описать как написать каждый из типов драйверов (минипорта, промежуточный или протокола).
Tdi driver что это
Windows NT предоставляет для взаимосвязи между транспортными драйверами и TDI-клиентами уровня ядра, такими как эмуляторы сетевых интерфейсов, редиректоры, серверы, единый программный интерфейс, называемый интерфейсом транспортных драйверов (Transport Driver Interface, TDI).
Изначально этот интерфейс планировалось использовать в пользовательском режиме работы ОС. В окончательном варианте интерфейс стал работать в режиме ядра, однако все еще может быть использован напрямую из пользовательского уровня. TDI предоставляется верхней частью любого транспортного стека протоколов Windows NT. TDI обеспечивает независимость TDI-клиентов от используемых ими транспортов. TDI поддерживает передачу как с установлением постоянного сеанса (виртуальная цепь), так и без него (датаграммы).
Требование, чтобы все драйверы транспорта предоставляли единый общий интерфейс TDI, облегчает задачу их разработки, а также разработки TDI-клиентов, потому что только этот интерфейс необходимо запрограммировать.
Так как TDI является относительно новым сетевым интерфейсом, и большинство приложений разработаны для использования других существующих стандартных интерфейсов, таких как NetBIOS и WinSockets, то Windows NT включает эмуляторы для этих двух популярных интерфейсов. Части уровня ядра этих эмуляторов, являющиеся драйверами файловых систем, отображают родные функции с соответствующими параметрами в одну или несколько TDI-функций, а затем вызывают соответствующие драйверы транспортов через TDI.
Интерфейс TDI включает следующее:
Программная модель TDI очень похожа на модель Winsocket. TDI-клиенты реализуют следующие шаги для установления соединения с удаленным сервером:
Краткий обзор драйверов спецификации NDIS
Сетевые драйверы можно разделить на 2 категории: TDI-драйверы (Transport Driver Interface) и NDIS-драйверы (Network Driver Interface Specification). TDI-драйверы — это высокоуровневые драйверы, например, SMB-клиент, SMB-сервер, обертки SMB (NFFS, MSFS) и т.п. Мы с Вами рассмотрим NDIS-драйвера. NDIS — это специальный драйвер (ему соответствует файл ndis.sys), который содержит функции, используемые низкоуровневыми сетевыми драйверами. NDIS как бы обволакивает низкоуровневые сетевые драйверы и является посредником в их общении между собой и с железом. По сути NDIS можно считать третьим ядром Windows. Чтобы более четко уяснить себе что из себя представляет NDIS можно посмтореть на следующую картинку:
Минипорт-драйверы
Минипорт-драйверы бывают «Connectionless» (например, драйвер Ethernet-адаптера) и «Сonnection-oriented» (например, драйвер модема). У Сonnection-oriented драйверов система коллбэков чуть сложнее, в нее входят обработчики событий, связанных с подключением к каналу связи, отключением от канала, выбором канала (для беспроводных адаптеров) и т.п. Для некоторых операций Сonnection-oriented драйверы вызывают специальные функции NDIS, отличающиеся префиксом «Со» в имени (например, вместо NdisMIndicateReceivePacket Сonnection-oriented драйвер должен вызывать NdisMColndicateReceivePacket).
Каждый коллбэк выполняет свою задачу: выдача информации, отправка данных, прием данных и т.п. Подробнее можно посмотреть в хелпе к WDK (DDK). Там можно получить полную информацию о коллбэках.
Драйверы протоколов могут передоверять минипорт-драйверу (при условии, что минипорт-драйвер это умеет — либо сам, либо адаптер умеет это делать на аппаратном уровне) некоторые свои функции (например, разграничить контрольную сумму или цифровую подпись IP-пакета или принять решение, как фрагментировать большой ТСP-пакет). Это значительно повышает производитель сети.
Промежуточные драйверы
Промежуточный драйвер сверху виден как минипорт-драйвер (смотрим на картинку), т.е. как бы виртуальный адаптер, а снизу — как драйвер протокола (снова смотрим на картинку), как бы виртуальный протокол. Как частный случай, возможна ситуация, когда промежуточный драйвер виден только сверху.
Драйверы протоколов
Драйверы протокола — это самый верхний уровень спецификации NDIS. Эти драйверы занимаются тем, что выделяют ресурсы для соответствующих пакетов, копируют данные приложений в пакеты и передают их драйверам нижнего уровня. Также драйверы протоколов обеспечивают интерфейс для получения пакетов от нижележащих драйверов.
К драйверам протоколов относятся и драйверы транспорта, реализующие стек сетевых протоколов, такой как например TCP/IP (tspip.sys).
Если пост будет интересен читателям, то в следующих постах можно конкретно на примере написать свой сниферо-подобный промежуточный драйвер или также описать как написать каждый из типов драйверов (минипорта, промежуточный или протокола).
ОС Windows: сетевая подсистема
Где располагается код для создания и работы с сокетами;
Какой механизм используется для фильтрации;
Как имплементированы протоколы.
Сетевая подсистема, согласно документации построена по принципу модели OSI. И также приводится описание того, за счет каких технологий и типов файлов реализуется работа отдельных уровней модели.
Имплементация модели OSI в операционной системе начинается со строго определенных уровней. В данном случае всё начинается на уровне «Канальном» и заканчивается на уровне «Транспортном». Имплементация на каждом уровне своя:
На экране ниже приведен снимок директории с основными драйверами для сетевой подсистемы:
Попробуем найти такие же файлы в реальной ОС. Заглянем в директорию «%Windows%». В качестве исследуемой системы возьмем Windows 7.
Часть файлов действительно имеет названия файлов, которые присутствуют в реальной ОС.
Похоже, что данные по работе с сетевой подсистемой можно обнаружить именно в этом драйвере. Поищем функции, которые позволяют фильтровать трафик. Как их идентифицировать?
Но в них все равно нет функций, которые бы могли фильтровать трафик. Почему так? Дело в том, что до Windows 7 фильтрация трафика как такового была имплементирована в отдельных драйверах, которые настраивались за счет интерфейса Windows. Начиная с Windows 7 была реализована так называемая Windows Filtering Platform, которая определила часть драйверов в специальную категорию, которая и призвана фильтровать трафик.
Часть этих фильтров можно найти по обычному поиску в директориях ОС:
Используем утилиту strings.exe на файлы FWPKCLNT.SYS и wfplwf.sys :
Имплементируются через отдельные одноименные файлы, например: tcpip.sys
В ОС Linux мы не задумывались о том как приложения получают доступ к структурам ядра и работают с сетью. Там более-менее всё очевидно и только один шаг до функций, но для Windows всё работает по принципу Callback`ов. Поэтому скорее всего будет несколько оберток для взаимодействия. Попробуем найти эти файлы.
Для поиска файлов, которые используются в качестве обертки-библиотеки, можно использовать следующий метод. Для этого создадим мини приложение, которое будет работать с сокетами, принимать и отправлять данные. Исходный код приложения:
Запускаем файл в ОС, если не возникло никаких ошибок, то необходимо параллельно запустить инструмент Process Explorer. С помощью этого инструмента мы подсмотрим, чем занимается поток, пока ждет соединения. На картинке ниже отображены все описанные действия:
Стоит отметить, что последовательность функций, которые вызываются для работы сокета в ОС, не виден в Process Explorer`е. Если нужно восстановить и эти данные, то нужно использовать отладчик ядра.
Таким образом, проводить исследование подсистем любых ОС и их механизмов можно с исходным кодом и без — достаточно выбрать необходимый набор инструментов, а также доступные методы, источники знаний.
Сетевая подсистема Linux
Начнем наше исследование с вот такой интересной картинки:
Картинка представляет собой структуру директорий исходного кода ядра ОС Linux. На ней видно, что сетевая подсистема вовсе не самая большая часть операционной системы. По правде говоря, можно собрать ядро и без этой части. Сегодня это вариант только для embeded систем, в общем случае без сети представить Linux сложно.
Код, который относится к сетевой подсистеме, находится в директории «net». Посмотрим, из чего он состоит.
Оставшиеся файлы в директории «net» описывают работу ядра с различными протоколами. Интересным моментом здесь является то, что фильтрующая подсистема имеет какие-то файлы только в некоторых протоколах и подсистемах:
Что в итоге? Всего по 4м картинкам структуры исходных кодов ядра мы уже обладаем информацией о том, какие поддерживаются протоколы в ядре Linux, какие механизмы интегрированы в протоколы для контроля и фильтрации и где найти базовые элементы, которые позволяют использовать сеть. Попробуем найти эту информацию и в ОС Windows.
Сетевая подсистема в ОС
Для будущих студентов курса «Сетевой инженер» и всех интересующихся подготовили полезную статью.
Disclamer: Статья описывает данные, которые с точки зрения автора помогут понять, как работают операционные системы с моделью TCP/IP, и не претендует на полноту.
Инструментарий и метод исследования
Для исследования операционной системы будем использовать следующие инструменты:
Операционная система Linux:
Visual Studio Code;
Операционная система Windows:
В нашем исследовании будем руководствоваться двумя правилами:
Используем всю информацию из документации операционных систем;
Проверяем правдивость описанных данных. Для структур данных:
В ОС Windows исследуем соответствующие функционалу dll, sys файлы;
В ОС Linux исследуем исходные коды и отдельные ветки ядра;
Теперь определимся с проблемами, которые вероятно будут нас преследовать на протяжении всего исследования.
Проблемы при исследовании ОС Linux
Основной функционал подсистемы целиком находится в ядре. К счастью, исходный код доступен в сети. Исследование исходного кода таких больших проектов всегда довольно сложная задача. На её сложность может влиять несколько факторов:
у каждого исследователя разный уровень экспертизы в области языка программирования, который используется в исходном коде;
у каждого исследователя есть свой собственных подход на интерпретацию полученной информации.
ограниченности исследования по времени;
объем исходного кода;
принятые правила кодирования проекта.
Как минимизировать количество действий исследователя, чтобы получить как можно больше полезной и интересной информации? Огромную роль играет правильно настроенное рабочее место. В нашем случае верную настройку определяет набор инструментов, который мы описали в разделе «Инструментарий и метод исследования». Также можно применить небольшой лайфхак и не рассматривать каждую строку исходников ядра, а рассматривать только высокоуровневые элементы. Это сэкономит время на изучение языка программирования и даст возможность разобраться, что к чему. Попробуем применить эту тактику на практике.
Описание ситуации с ошибкой 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.
NSX предоставляет логические брандмауэры, коммутаторы, маршрутизаторы, порты и другие сетевые элементы для обеспечения виртуальных сетей среди независимых от поставщиков, гипервизоров, систем управления облаком и связанного сетевого оборудования. Он также поддерживает внешние сети и экосистемные услуги безопасности.
Важные особенности NSX
NSX варианты использования
NSX использует автоматизацию центра обработки данных для быстрой и гибкой настройки сети. Сетевой администратор может быстро обеспечить новую сеть или сетевой сегмент рабочими нагрузками, ресурсами и политиками безопасности, уже привязанными к нему. Это устраняет узкие места и делает NSX идеальным для тестирования приложений и работы с неустойчивыми рабочими нагрузками, которые NSX может логически изолировать в одной и той же физической сети.
Как отключить или удалить 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 читайте по ссылке)
Сетевая подсистема в ОС
Для будущих студентов курса «Сетевой инженер» и всех интересующихся подготовили полезную статью.
Disclamer: Статья описывает данные, которые с точки зрения автора помогут понять, как работают операционные системы с моделью TCP/IP, и не претендует на полноту.
Инструментарий и метод исследования
Для исследования операционной системы будем использовать следующие инструменты:
Операционная система Linux:
Visual Studio Code;
Операционная система Windows:
В нашем исследовании будем руководствоваться двумя правилами:
Используем всю информацию из документации операционных систем;
Проверяем правдивость описанных данных. Для структур данных:
В ОС Windows исследуем соответствующие функционалу dll, sys файлы;
В ОС Linux исследуем исходные коды и отдельные ветки ядра;
Теперь определимся с проблемами, которые вероятно будут нас преследовать на протяжении всего исследования.
Проблемы при исследовании ОС Linux
Основной функционал подсистемы целиком находится в ядре. К счастью, исходный код доступен в сети. Исследование исходного кода таких больших проектов всегда довольно сложная задача. На её сложность может влиять несколько факторов:
у каждого исследователя разный уровень экспертизы в области языка программирования, который используется в исходном коде;
у каждого исследователя есть свой собственных подход на интерпретацию полученной информации.
ограниченности исследования по времени;
объем исходного кода;
принятые правила кодирования проекта.
Как минимизировать количество действий исследователя, чтобы получить как можно больше полезной и интересной информации? Огромную роль играет правильно настроенное рабочее место. В нашем случае верную настройку определяет набор инструментов, который мы описали в разделе «Инструментарий и метод исследования». Также можно применить небольшой лайфхак и не рассматривать каждую строку исходников ядра, а рассматривать только высокоуровневые элементы. Это сэкономит время на изучение языка программирования и даст возможность разобраться, что к чему. Попробуем применить эту тактику на практике.
Сетевая подсистема Linux
Начнем наше исследование с вот такой интересной картинки:
Картинка представляет собой структуру директорий исходного кода ядра ОС Linux. На ней видно, что сетевая подсистема вовсе не самая большая часть операционной системы. По правде говоря, можно собрать ядро и без этой части. Сегодня это вариант только для embeded систем, в общем случае без сети представить Linux сложно.
Код, который относится к сетевой подсистеме, находится в директории «net». Посмотрим, из чего он состоит.
Исходный код собран по выполняемым задачам. За базовыми элементами можно обратиться в директорию core:
Оставшиеся файлы в директории «net» описывают работу ядра с различными протоколами. Интересным моментом здесь является то, что фильтрующая подсистема имеет какие-то файлы только в некоторых протоколах и подсистемах:
Что в итоге? Всего по 4м картинкам структуры исходных кодов ядра мы уже обладаем информацией о том, какие поддерживаются протоколы в ядре Linux, какие механизмы интегрированы в протоколы для контроля и фильтрации и где найти базовые элементы, которые позволяют использовать сеть. Попробуем найти эту информацию и в ОС Windows.
ОС Windows: сетевая подсистема
Где располагается код для создания и работы с сокетами;
Какой механизм используется для фильтрации;
Как имплементированы протоколы.
Сетевая подсистема, согласно документации построена по принципу модели OSI. И также приводится описание того, за счет каких технологий и типов файлов реализуется работа отдельных уровней модели.
Имплементация модели OSI в операционной системе начинается со строго определенных уровней. В данном случае всё начинается на уровне «Канальном» и заканчивается на уровне «Транспортном». Имплементация на каждом уровне своя:
На экране ниже приведен снимок директории с основными драйверами для сетевой подсистемы:
Попробуем найти такие же файлы в реальной ОС. Заглянем в директорию «%Windows%». В качестве исследуемой системы возьмем Windows 7.
Часть файлов действительно имеет названия файлов, которые присутствуют в реальной ОС.
Похоже, что данные по работе с сетевой подсистемой можно обнаружить именно в этом драйвере. Поищем функции, которые позволяют фильтровать трафик. Как их идентифицировать?
Но в них все равно нет функций, которые бы могли фильтровать трафик. Почему так? Дело в том, что до Windows 7 фильтрация трафика как такового была имплементирована в отдельных драйверах, которые настраивались за счет интерфейса Windows. Начиная с Windows 7 была реализована так называемая Windows Filtering Platform, которая определила часть драйверов в специальную категорию, которая и призвана фильтровать трафик.
Часть этих фильтров можно найти по обычному поиску в директориях ОС:
Используем утилиту strings.exe на файлы FWPKCLNT.SYS и wfplwf.sys :
Имплементируются через отдельные одноименные файлы, например: tcpip.sys
В ОС Linux мы не задумывались о том как приложения получают доступ к структурам ядра и работают с сетью. Там более-менее всё очевидно и только один шаг до функций, но для Windows всё работает по принципу Callback`ов. Поэтому скорее всего будет несколько оберток для взаимодействия. Попробуем найти эти файлы.
Для поиска файлов, которые используются в качестве обертки-библиотеки, можно использовать следующий метод. Для этого создадим мини приложение, которое будет работать с сокетами, принимать и отправлять данные. Исходный код приложения:
Запускаем файл в ОС, если не возникло никаких ошибок, то необходимо параллельно запустить инструмент Process Explorer. С помощью этого инструмента мы подсмотрим, чем занимается поток, пока ждет соединения. На картинке ниже отображены все описанные действия:
Стоит отметить, что последовательность функций, которые вызываются для работы сокета в ОС, не виден в Process Explorer`е. Если нужно восстановить и эти данные, то нужно использовать отладчик ядра.
Таким образом, проводить исследование подсистем любых ОС и их механизмов можно с исходным кодом и без — достаточно выбрать необходимый набор инструментов, а также доступные методы, источники знаний.