Порт smb windows – Server message block — Википедия

Боремся с вирусами и инфраструктурой, или отключение SMB v1 / Блог компании Сервер Молл / Хабр

В связи с недавной эпидемией шифровальщика WannaCry, эксплуатирующим уязвимость SMB v1, в сети снова появились советы по отключению этого протокола. Более того, Microsoft настоятельно рекомендовала отключить первую версию SMB еще в сентябре 2016 года. Но такое отключение может привести к неожиданным последствиям, вплоть до курьезов: лично сталкивался с компанией, где после борьбы с SMB перестали играть беспроводные колонки Sonos.

Специально для минимизации вероятности «выстрела в ногу» я хочу напомнить об особенностях SMB и подробно рассмотреть, чем грозит непродуманное отключение его старых версий.

SMB (Server Message Block) – сетевой протокол для удаленного доступа к файлам и принтерам. Именно он используется при подключении ресурсов через \servername\sharename. Протокол изначально работал поверх NetBIOS, используя порты UDP 137, 138 и TCP 137, 139. С выходом Windows 2000 стал работать напрямую, используя порт TCP 445. SMB используется также для входа в домен Active Directory и работы в нем.

Помимо удаленного доступа к ресурсам протокол используется еще и для межпроцессорного взаимодействия через «именованные потоки» – named pipes. Обращение к процессу производится по пути \.\pipe\name.

Первая версия протокола, также известная как CIFS (Common Internet File System), была создана еще в 1980-х годах, а вот вторая версия появилась только с Windows Vista, в 2006. Третья версия протокола вышла с Windows 8. Параллельно с Microsoft протокол создавался и обновлялся в его открытой имплементации Samba.

В каждой новой версии протокола добавлялись разного рода улучшения, направленные на увеличение быстродействия, безопасности и поддержки новых функций. Но при этом оставалась поддержка старых протоколов для совместимости. Разумеется, в старых версиях было и есть достаточно уязвимостей, одной из которых и пользуется WannaCry.

Посмотреть используемую в текущий момент версию протокола довольно просто, используем для этого командлет Get–SmbConnection:

Вывод командлета при открытых сетевых ресурсах на серверах с разной версией Windows.

Из вывода видно, что клиент, поддерживающий все версии протокола, использует для подключения максимально возможную версию из поддерживаемых сервером. Разумеется, если клиент поддерживает только старую версию протокола, а на сервере она будет отключена – соединение установлено не будет. Включить или выключить поддержку старых версий в современных системах Windows можно при помощи командлета

Get–SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

Выключаем SMBv1 на сервере с Windows 2012 R2.

Результат при подключении с Windows 2003.

Таким образом, при отключении старого, уязвимого протокола можно лишиться работоспособности сети со старыми клиентами. При этом помимо Windows XP и 2003 SMB v1 используется и в ряде программных и аппаратных решений (например NAS на GNU\Linux, использующий старую версию samba).

Список взят с сайта Microsoft, где он регулярно пополняется.

Перечень продуктов, использующих старую версию протокола, достаточно велик – перед отключением SMB v1 обязательно нужно подумать о последствиях.

Если программ и устройств, использующих SMB v1 в сети нет, то, конечно, старый протокол лучше отключить. При этом если выключение на SMB сервере Windows 8/2012 производится при помощи командлета Powershell, то для Windows 7/2008 понадобится правка реестра. Это можно сделать тоже при помощи Powershell:

Set–ItemProperty –Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 –Type DWORD –Value 0 –Force

Или любым другим удобным способом. При этом для применения изменений понадобится перезагрузка.

Для отключения поддержки SMB v1 на клиенте достаточно остановить отвечающую за его работу службу и поправить зависимости службы lanmanworkstation. Это можно сделать следующими командами:

sc.exe config lanmanworkstation depend=bowser/mrxsmb20/nsi 

sc.exe config mrxsmb10 start=disabled
 

Для удобства отключения протокола по всей сети удобно использовать групповые политики, в частности Group Policy Preferences. С помощью них можно удобно работать с реестром.

Создание элемента реестра через групповые политики.

Чтобы отключить протокол на сервере, достаточно создать следующий параметр:

Создание параметра реестра для отключения SMB v1 на сервере через групповые политики.

Для отключения поддержки SMB v1 на клиентах понадобится изменить значение двух параметров.

Сначала отключим службу протокола SMB v1:

Обновляем один из параметров.

Потом поправим зависимость службы LanmanWorkstation, чтоб она не зависела от SMB v1:

И заменяем другой.

После применения групповой политики необходимо перезагрузить компьютеры организации. После перезагрузки SMB v1 перестанет использоваться.

Как ни странно, эта старая заповедь не всегда полезна – в редко обновляемой инфраструктуре могут завестись шифровальщики и трояны. Тем не менее, неаккуратное отключение и обновление служб могут парализовать работу организации не хуже вирусов.

Расскажите, а вы уже отключили у себя SMB первой версии? Много было жертв?

habr.com

ITband.ru » Протокол SMB. Что же у него внутри?

Для обмена информации между пользователями, чаще всего используется локальная сеть или интернет. В локальных сетях большая часть информации передается через простую передачу файлов. Конечно есть системы документооборота, которые призваны упростить жизнь всем, включая сотрудников с их бумажной волокитой. Но данные решения требуют больших трудозатрат на внедрение, поэтому, на данный момент, чаще всего используется обычный файл-сервер. К тому же очень часты просто “файло-помойки” со всяким контентом. Обмен данными (в среде операционных систем Microsoft и не только) происходит по протоколу SMB.

В данном обзоре основной упор будет сделан на “новый” протокол SMB2, но так же будет встречаться упоминания об SMB1. Операционные системы использовались MS Windows 2008/2008R2.

Общие данные

Протокол SMB (Server Message Block) работает на 6-м и 7-м уровне модели OSI, т.е. на уровне представления и приложений. Используется для удаленного доступа к файлам, принтерам, Serial портам, а так же к другим сетевым взаимодействиям между узлами.

Модель OSI – абстрактная модель взаимодействия, состоит из 7-ми уровней, каждый из которых определяет сетевые функции. Все уровни независимы друг от друга. Эта независимость приводит к тому, что одному уровню не нужно знать как применяется второй уровень, необходимо только знать как с ним взаимодействовать. Это является одной из основных причин, почему данная модель стала так популярна.

Протокол SMB работает как клиент-серверное приложение, т.е. когда клиент посылает запрос, то сервер отвечает ему. Часть раздела SMB протокола предназначена для доступа к файловой системе, к примеру, когда пользователь делает запрос к файл-серверу для получения файла. Другая же часть нацелена на использования межпроцессного взаимодействия Inter-process communication (IPC).

Хотя главной целью является общий доступ к файлам, SMB протокол предоставляет и другие возможности. В основном это реализации самого протокола, которые и делают его таким универсальным.

1. Согласование диалектов
2. Определение SMB серверов в сети
3. Печать с использованием сети
4. Доступ к файлам и директориям с аутентификацией
5. Уведомление об изменении файлов и папок
6. Поддержка юникода
7. Оппортунистические блокировки

Немного об SMB2

Новая версия протокола SMB, SMB 2.0, была впервые внедрена на ОС MS Winodws Vista и Windows 2008 в 2006 году. Хотя протокол и проприетарный, но спецификация доступна на сайте MSDN, в отличие от SMB1, который долгое время был закрытым. В Windows 2008R2 и Windows 7 появилось небольшое обновление протокола до диалекта 2.10, в котором была увеличена общая сетевая производительность

Преимуществом SMB2 протокола можно считать снижение числа общения между узлами, что приводит к уменьшению зашумленности в сетях. Достигнуто было за счет значительного уменьшения числа команд. Уменьшение с более чем 100 до 19 штук.

1. Согласование и аутентификация (NEGOTIATE, SESSION_SETUP, LOGOFF, TREE_CONNECT, TREE_DISCONNECT)
2. Доступ к файлам и директориям (CANCEL, CHANGE_NOTIFY, CLOSE, CREATE, FLUSH, IOCTL, LOCK, QUERY_DIRECTORY, QUERY_INFO, READ, SET_INFO, WRITE)
3. Другое (ECHO, OPLOCK_BREAK)

Так же добавлена возможность конвейерной отправки сообщений, что дало возможность “склеивать” несколько запросов в один. Данная технология называется pipelining, который позволяет отправлять дополнительные запросы, не дожидаясь ответа от предыдущего запроса. Таким образом уменьшается очередь команд, которые необходимо отправить серверу. Данное решение позволило сократить количество ожидающих запросов/ответов, что приводит к повышению производительности.

Так же SMB2 теперь может управлять потоком данных (credit-based flow control). Начиная передачу с небольшого “окна данных” сервер увеличивает его и автоматически подстраивается под среду. Данное решение позволяет сохранять большое количество передаваемых данных и лучше использовать пропускную способность сети.

Компаундирование (смешивание). В отличие от первой версии протокола, в SMB2 все команды стали более простые. В реализации SMB1 были сложные команды и субкоманды (специальные для каждого случая), которые были набором различных вариацией простых команд (LOCK_AND_READ или WRITE_AND_UNLOCK). Повторюсь, теперь все команды стали простыми, а взамен появилась возможность соединить несколько команд в произвольном порядке, как бы эмулировав старые сложные команды. Это привело к значительному уменьшению команд в SMB2.

Кэширование свойств папок и файлов.

Отказоустойчивое подключение, позволяет прозрачно вернуться в сеть, при кратковременной потере сетевого подключения. Спасает от необходимости устанавливать заново согласование в новой сессии.

Цифровая подпись теперь HMAC SHA-256

Улучшена масштабируемость для совместного использования файлов. Возможное количество одновременно подключенных клиентов и открытых файлов значительно увеличено.

Лучшая работа через NAT.

Расширение механизма (например, создать контекст или переменной смещения).

Поддержка symbolic link.

Оппортунистические блокировки

Оппортунистическая блокировка (Oplock) это механизм, позволяющий клиентам динамически изменять стратегию буферизации для данного файла или потока данных с целью увеличения производительности и уменьшения нагрузки на сетевое подключение. Производительность удаленных операций может быть увеличена, если клиент сможет локально буферизовать данные. Это позволяет отказаться от передачи данных/пакетов SMB при изменении данных.

К примеру: клиент не должен производить мгновенную запись изменений в файл, открытый по сети, если он знает, что никакой другой процесс не получит доступ к этому файлу. Кроме того, клиент может использовать упреждающую буферизацию данных. Так же использование оппортунистической блокировки позволяет приложениям получать прозрачный доступ к файлам в фоновом режиме.

Файловая система NTFS поддерживает несколько потоков данных к одному файлу. OpLock ориентированы на потоки. Это означает, что операции применяемы к данному открытому потоку, в целом не влияют на OpLock в другом потоке. Так же есть исключения, которые будут явно указаны.

Различают несколько видов оппортунистических блокировок:

1. Level1 (исключающая): позволяет клиенту открыть поток для эксклюзивного доступа и позволяет клиентам выполнять буферизацию данных. Поддерживается кэширования записи и чтения.
2. Level2 (общедоступная): позволяет создавать многочисленные читающие потоки. Поддерживает кэширование чтения.
3. Пакетная (исключающая): дает возможность держать открытый поток на сервера, хотя локально был закрыт этот поток. Позволяет читать, писать и кэшировать дескрипторы.
4. Фильтрующая (исключающая): позволяет приложения открывать и читать поток данных

Подпись SMB трафика (SMB Signing)

Подпись SMB трафика (SMB Signing) – это специальный механизм, обеспечивающий безопасность протокола SMB. Предназначен для повышения защиты передаваемого трафика и от атак в Man-In-The-Middle. Впервые SMB Signing появился в Windows NT 4.0 SP3 и Windows 98.

SMB Signing предоставляет два улучшения для протокола SMB:

1. Взаимная аутентификация
2. Аутентификация сообщений

Эти преимущества достигаются путем добавления в SMB пакет цифровой подписи.

Включение ж приводит к увеличению нагрузку, что может привести к снижению производительности передачи сетевого трафика на 10-15%.

Принцип работы:

1. Клиент соединяется с сервером, делается запрос на использования SMB Signing
2. Сервер отвечает на соединение, что можно использовать SMB Signing
3. Клиент делает новый запрос, куда включает NTLM/NTLM v2 данные или билет от Kerberos и отправляет серверу. После данного этапа каждый последующий пакет имеет +1 к последовательности. Таким образом можно отслеживать, что нет вмешательства в пакеты отправляемые между клиентом и сервером
4. Устанавливается номер последовательности равный 1. Генерируется цифровая подпись, путем сложения сессионного ключа (например, взятого из билета kerberos`a) и SMB пакета, и от него берется MD5/SHA-256 хэш сумма и помещается в поле SecuritySignature. После этого последовательность увеличивается на единицу, т.е. теперь равно двум (2)
5. Клиент получает пакет и выполняет действия аналогичные п.4, только со своим сессионным ключом. Если значения совпадут, то пакет считается нормальным (иначе отбрасывается).
6. После этого общение происходит с цифровой подписью, т.е. теперь пакеты проверяются.

Т.к. сессионный ключ в открытом виде не пересылается, то становится довольно проблематично, а главное в короткие сроки, отгадать этот самой ключ и подменять его. Таким вот простым образом достигается безопасность передачи трафика.

Так же есть реализация IPSec, в котором защищаются сами пакеты IP. IPSec может работать с любым вышестоящим (в модели OSI) протоколом, в том числе и с SMB. Отличает SMB Signing от IPSec уровни на которых происходит защита. В бонус IPSec: может не только подписывать трафик, но и защищать его от свободного снифинга. Достигается путем шифрации сессионным ключом.

Аутентификация в SMB

Существует два вида уровня доступа:

1. User-Level – Этот уровень отвечает за аутентификации при подключении к серверу, т.е. когда клиент пытается подключиться к серверу он отсылается свои данные для аутентификации (возможно использование анонимного доступа, тогда любой имеет доступ к серверу). Если аутентификация прошла успешно, то клиента допускают до сервера (в обычной жизни это выглядит как отображение общедоступных папок в сетевом окружении, при заходе,например, \\FF-srv01.inadmin.local). Иначе он просто не сможет подключиться до сервера.
2. Share-level – Это уровень доступа, определяемые индивидуально для каждой общедоступной папки. Например, не все пользователи имеют доступ к “Папка1”, но при этом имеют доступ к папке “Общие Документы”.

Таким образом мы получаем, что сначала работает User-Level, а потом уже Share-Level, при условии, что клиент смог пройти аутентификацию на User-Level.

Inter-process communication

Inter-process communication (IPC) – набор способов обмена данными среди нескольких потоков в одном или нескольких процессах. IPC делятся на методы: обмена сообщений, синхронизации, разделяемой памяти и удаленных вызовов (RPC). Другими словами это механизм для облегчения связи и обмена данными между приложениями, которые могут быть запущены на одном или нескольких компьютерах, соединенных сетью, используются для обмена служебной информацией. Межпроцессорное взаимодействие можно разделить на наиболее крупные разделы:

1. Сообщения: Pipes (каналы) и message queues (очереди сообщений)
2. Shared Memory (Разделяемая память)
3. Remote procedure calls (RPC, удаленный вызов процедур)
4. Синхронизация: семафоры и блокирование
5. Сетевое взаимодействие (API сокеты)

Давайте рассмотрим простой пример работы IPC. У нас есть несколько приложений, запущенных на одном ПК. И вот мы хотим реализовать возможность “общения” между этими программами. Как такое сделать? Использовать IPC.

Самим простым способом общения, можно считать, сообщения. К примеру, можно использовать WinAPI SendMessage, SendMessageEx, PostMessage. Сообщения бывают именованными и широковещательными. В качестве идентификатора для именованных сообщений можно использовать любой набор букв, главное что-бы он был уникальным. При широковещательных сообщениях данные получают все приложения. Как можно понять, в данном примере обмен данными проходил в пределах одного ПК и сеть не использовалась. Обмен данными происходил между несколькими запущенными приложениям на одном ПК.

Зачем же нужен IPC? Ну допустим у вас есть два приложения, одно считает сумму. А вот второе эту сумму обрабатывает и делает сводные таблицы. Для передачи суммы из одной программы в другую и используем IPC.

Ярким представителем IPC в сетевой среде можно считать RPC (Remote Procedure Call). Данный протокол обеспечивает удаленное выполнение процедур.

Давайте рассмотрим состав RPC пакета:

Как видно, протокол MSRPC работает непосредственно с SMB2 (об версиях SMB чуть ниже). На данном примере нам будет интересен так же UUID (Universally Unique IDentifier — Универсальный Уникальный Идентификатор), который является идентификатором RPC сервиса, запущенного на удаленном сервере, к которому мы хотим подключиться.

MSRPC over SMB – это одна из первых реализаций межпроцессорного взаимодействия, позволяющая использовать аутентификационные данные пользователя, когда он подключается к общедоступной папке SMB. MSRPC работает непосредственно с SMB, т.е. нет никакой прослойки между RPC и SMB.

Такие подключения называют именноваными каналами (named pipes). Реализованы эти каналы через драйвер npfs.sys. При использовании MSRPC over SMB необходимо использование endpoint mapper и well-known mapper, так же в заголовке необходимо указать индетификатор транспортного протокола (0x0F)

Примером именованных каналов (named pipes):

• \pipe\samr – SAM (Security Account Manager)
• \pipe\lsarpc – LSA (Local Security Manager)
• \pipe\netlogon – Netlogon RPC server
• \pipe\svcctl – SCM (Service Control Manager)
• \pipe\eventlog – Eventlog Service
• \pipe\srvsvc – Server service
• \pipe\wkssvc – Workstation service

По RPC можно почитать книгу. Про RPC over SMB смотрите аппендикс I и L.

Для реализации данного функционала существует общедоступная, “расшаренная”, папка IPC$ у ОС Windows. Это не “настоящая” , в обычном понимании, общедоступная папка, а виртуальная. Используется как раз для взаимодействия между узлов через сеть.

Более подробней про IPC.

Транспорт протокола SMB

Протокол SMB был основан в 80-х годах, и за свое существование многое изменилось. Рассматривать “дикости” вроде SMB Over IPX/SPX или SMB Over NetBEUI не будем. Это такие пережитки прошлого, когда каждый изобретал свой собственный велосипед, не совместимые с велосипедами других компаний. Гораздо важнее сосредоточиться на текущем положении дел, а оно такого:

Сейчас для транспорта используется связка TCP/IP, которая отлично себя зарекомендовала не только при использование SMB протоколом. А вот на сеансовом уровне будут различия. Долгое время использовался NetBIOS Over TCP/IP (NBT), но в последних версиях ОС MS Windows был сделан отказ от него и переход на SMB Over TCP/IP. Совместимость новых операционных систем со старыми протоколами – есть. О реализации согласований протоколов чуть позже.

В нашем случае, т.е. по состоянию дел на текущий момент, есть два варианта транспорта:

NetBIOS Over TCP/IP:

NetBIOS протокол работает на сеансовом уровне модели OSI. Решает задачи:

1. Регистрация сетевых имен

2. Установление сессий

3. Установление надежных соединений для передачи данных (TCP)

4. Установление ненадежных соединений для передачи данных (UDP)

Вероятно вы заметили, что функционал дублирует задачи DNS. Это верно NetBIOS изначально был разработан, когда технологии DNS не было. Поэтому от данного протокола, NBT, и отказываются в использовании.

Используемые порты:

1. UDP 137 – Name managment.

2. UDP 138 – Datagram traffic.

3. TCP 139 – Session traffic

SMB Over TCP

1. TCP/UDP 445 – Session traffic. Сессионный трафик, передача файлов, использование принтеров и прочее.

Протокол специально разработан для выполнении одной задачи, а именно связки SMB и TCP/IP.

Довольно часто SMB винят в создании большого количества широковещательного (broadcast) трафика. Но на самом деле причина кроется не в SMB, а в NBT, который он использует. Протоколом по умолчанию NBT был в Windows NT, но к Windows 2000 был сделан отказ от реализации разрешения имен на основе WINS серверов. Стандартом стал DNS. Таким образом NBT стал особняком, который дублировал задачи. И в последних версиях ОС уже по умолчанию используется SMB over TCP/IP.

Есть так же еще одна неприятная особенность, точнее наследие прошлого. Операционная система довольно долго развивается, так же есть много других продуктов (Exchange, Sharepoint и прочих сервисов в самой ОС), которые могут использовать NetBIOS API для задач с разрешением имен. Таким образом полный отказ от NetBIOS может привести к неожиданным последствиям при разрешении сетевых имен.

К преимуществам использования протокола SMB Over TCP/IP можно отнести:

1. Упрощение транспорта трафика SMB

2. Отказа от использования WINS и широковещательного трафика NetBIOS в сети.

3. Стандартизация разрешения имен, все запросы разрешаются через DNS сервер.

Для отключения NBT:

1. Необходимо зайти в сетевое окружение
2. Выбрать сетевой адаптер “Подключение по локальной сети” , зайти в свойства
3. Выбрать Internet Protocol (TCP/IP) и зайти в свойства
4. Перейти на вкладку Advanced
5. Выбрать Disable NetBIOS over TCP/IP
   

Для просмотра интерфейсов, на которых есть NBT можно воспользоваться командой Net config redirector

Computer name                        \\FF-SRV01
Full Computer name                   FF-SRV01.InAdmin.Local
User name                            Administrator 

Workstation active on
 NetBT_Tcpip_{860BDBCB-FF6A-4AC7-B5BC-981A00AA8AE8} (00155DF83106) 

Software version                     Windows Server 2008 R2 Standard 

Workstation domain                   INADMIN
Workstation Domain DNS Name          InAdmin.Local
Logon domain                         FF-SRV01 

COM Open Timeout (sec)               0
COM Send Count (byte)                16
COM Send Timeout (msec)              250
The command completed successfully.

Согласование транспортных протоколов (NetBIOS Over TCP/IP vs SMB Over TCP/IP)

Одним из самых главных этапов при установлении соединения является согласование протоколов. Алгоритм следующий:

1. Попытка установить TCP сессию на 445 порту (порт, на котором работает SMB Over TCP/IP).
2. Если удалось поднять сессию, то поднимается SMB через SMB Over TCP/IP
3. Если сессия на 445 порту не установилась, то делается попытка установить связь через 139 порт (порт, на котором работает NetBIOS Over TCP/IP).
4. Если сессия установилась, то поднимается SMB через NetBIOS Over TCP/IP

Таким образом предпочтение при подключение имеет более новый протокол, т.е. SMB Over TCP/IP. Если же сессия не установилась, то делается попытка отступить на более старый протокол взаимодействия. В случае, когда п.1 и п.3 не завершатся установлением сессии, то попытки подключения прекращаются и выдается ошибка подключения.

Диалекты

По причине того, что SMB протокол старый и развивается достаточно долго,а следовательно и функциональность наращивается, то возможности взаимодействия сетевых узлов необходимо согласовать. Иначе будет ситуация когда узлы не понимают друг друга. Каждый этап развития характеризуется своим диалектом (или стандартным пакетом). Каждый диалект характеризуется строкой:

Процедура согласования диалектов

Итак, вторым этапом согласования является: согласование диалектов. Рассмотрим пример согласования диалектов между MS Windows 2008 R2 серверами (SMB 2.10):

1. Клиент (ОС, которой необходимо получить доступ до другого сервера) отсылает запрос, содержащий поддерживаемый им диалекты.

   Dialect: PC NETWORK PROGRAM 1.0

    Dialect: LANMAN1.0

    Dialect: Windows for Workgroups 3.1a

    Dialect: LM1.2X002

    Dialect: LANMAN2.1

    Dialect: NT LM 0.12

    Dialect: SMB 2.002

    Dialect: SMB 2.???

2. Сервер принимает пакет с запросом на согласование диалектов. Находит в нем строку “SMB 2.???” среди предложенных диалектов. И формирует ответ для клиента, где устанавливает значение:

   DialectRevision: 767 (0x2FF)

3. Клиент получает ответ от сервера и формирует новый запрос, в который включает поддерживаемые диалекты для SMB2

   Dialects: 514 (0x202)

   Dialects: 528 (0x210)

4. Сервер получает новый запрос. Находит в нем, что поддерживается 0×0210 и формирует ответ для клиента, установив

   DialectRevision: 528 (0x210)

Рассмотрим второй пример. На этот раз согласование диалектов между OC Windows 2008. В отличии от первого случая, тут согласование пройдет более просто, и будет выбран диалект SMB 2.002:

1. Клиент (ОС, которой необходимо получить доступ до другого сервера) отсылает запрос, содержащий поддерживаемый им диалекты.

   Dialect: PC NETWORK PROGRAM 1.0

    Dialect: LANMAN1.0

    Dialect: Windows for Workgroups 3.1a

    Dialect: LM1.2X002

    Dialect: LANMAN2.1

    Dialect: NT LM 0.12

    Dialect: SMB 2.002

2. Сервер получает запрос и формирует ответ для клиента, установив

   DialectRevision: 0x0202

Процедура установления сессии

Следующим этапом будет установление сессии. На данном этапе создается запрос SESSION_SETUP Request и отсылается от клиента к серверу для установления аутентификационной сессии.

1. Клиент запрашивает GSS (Generic Security Service) на выдачу аутентификационного токена и отправляет его в SESSION_SETUP Request:

   Command: SESSION SETUP

   SecurityMode: Signing Enabled

   SecurityBufferOffset: 88 (0x58)

   SecurityBufferLength: 74 (0x4A)

   Buffer: (74 bytes)

2. Сервер получает токен с GSS. Сервер формирует ответ установив Status=STATUS_MORE_PROCESSING_REQUIRED и помещает токен, полученный от GSS

   Status: STATUS_MORE_PROCESSING_REQUIRED

   Command: SESSION SETUP

   TreeId: 0 (0x0)

   SessionId: 4406368010297 (0x401F0000039)

   SessionFlags: Normal session

   SecurityBufferOffset: 72 (0x48)

   SecurityBufferLength: 219 (0xDB)

   Buffer: (219 bytes)

3. Клиент получает токен с GSS и отсылает SMB2 SESSION_SETUP Request, извлекая токен из GSS и SessionID из предыдущего ответа

   Status: STATUS_SUCCESS

   Command: SESSION SETUP

   SessionId: 4406368010297 (0x401F0000039)

   SecurityMode: Signing Enabled

   SecurityBufferOffset: 88 (0x58)

   SecurityBufferLength: 245 (0xF5)

   Buffer: (245 bytes)
   
   

4. Сервер принимает GSS и возвращает, что сессия установлена:

   Status: STATUS_SUCCESS

   Command: SESSION SETUP

   SessionId: 4406368010297 (0x401F0000039)

   SecurityBufferOffset: 72 (0x48)

   SecurityBufferLength: 29 (0x1D)

   Buffer: (29 bytes)

Получение доступа к папкам

1. Для завершения аутентификации, клиент посылает запрос, используя для этого SessionID.

   Status: STATUS_SUCCESS
   
   Command: TREE CONNECT
   МessageId: 3 (0x3)
   TreeId: 0 (0x0)
   
   SessionId: 4406368010297 (0x401F0000039)
   Share: \172.16.0.2IPC$

2. Сервер, при получении запроса, формирует ответ со следующими полями:

   Status: STATUS_SUCCESS

   MessageId: 3 (0x3)

   SessionId: 4406368010297 (0x401F0000039)

   TreeId: 1 (0x1)
   
   

Последующие операции (такие как CREATE, WRITE, READ) будут использовать SessionID и TreeID

Чтение файла

Т.к. сессия у нас уже установлена и параметры мы можем использовать, то давайте рассмотрим, к примеру открытие файлов по сети

1. Клиент отправляет SMB2 Create Request для файла TestSMB.txt

   Status: STATUS_SUCCESS

   Command: CREATE

   MessageId: 10 (0xA)

   ProcessId: 65279 (0xFEFF)

   TreeId: 1 (0x1)

   SessionId: 4406368010297 (0x401F0000039)

   RequestedOplockLevel: 9 (0x9)

   DesiredAccess: 0x00120089

   read:        (...............................1) Read Data

   readEA:      (............................1...) Read EA

   FileRead:    (........................1.......) File Read Attributes

   ShareAccess: Shared for Read/Write

   CreateDisposition: Open

   Name: TestSMB.txt

2. Сервер формирует ответ SMB2 Create Response

   Status: STATUS_SUCCESS

   Command: CREATE

   Flags: 1 (0x1)

   ServerToRedir: ...............................1 Server to Client

   MessageId: 10 (0xA)

   ProcessId: 65279 (0xFEFF)

   TreeId: 1 (0x1)

   SessionId: 4406368010297 (0x401F0000039)

   CreateAction: 1 (0x1)

   CreationTime: 127972992877715232 (0x1C6A6C24D51DF20)

   LastAccessTime: 127972992923579232 (0x1C6A6C2500DB360)

   LastWriteTime: 127972992923579232 (0x1C6A6C2500DB360)

   ChangeTime: 127972992923579232 (0x1C6A6C2500DB360)

   AllocationSize: 104 (0x68)

   EndOfFile: 98 (0x62)

   Volatile: -4294967287 (0xFFFFFFFF00000009)

3. Клиент отправляет запрос на чтение данных из файла SMB2 Read Request

   Smb2: C READ 0x62 bytes from offset 0 (0x0)

   Status: STATUS_SUCCESS

   Command: READ
   MessageId: 11 (0xB)

   ProcessId: 65279 (0xFEFF)TreeId: 1 (0x1)

   SessionId: 4406368010297 (0x401F0000039)

   CRead:

   Size: 49 (0x31)

   Padding: 80 (0x50)

   DataLength: 98 (0x62)

   Offset: 0 (0x0)

   Fid:

   Persistent: 17 (0x11)

   Volatile: -4294967287 (0xFFFFFFFF00000009)

4. Сервер отвечает ответом SMB2 READ Response c данными из файла

   Smb2: R READ 0x62 bytes read

   Status: STATUS_SUCCESS

   Command: READ

   Flags: 1 (0x1)

   ServerToRedir: ...............................1 Server to Client

   MessageId: 11 (0xB)

   ProcessId: 65279 (0xFEFF)

   TreeId: 1 (0x1)

   SessionId: 4406368010297 (0x401F0000039)

   RRead:

   Size: 17 (0x11)

   DataOffset: 80 (0x50)

   Reserved: 0 (0x0)

   DataLength: 98 (0x62)

   DataRemaining: 0 (0x0)

   Reserved2: 0 (0x0)

   Data: (98 bytes)

5. Клиент отправляет SMB2 CLOSE Request для закрытия файла

   Smb2: C CLOSE FID=

   SMB2Header:

   Status: STATUS_SUCCESS

   Command: CLOSE

   MessageId: 12 (0xC)

   ProcessId: 65279 (0xFEFF)

   TreeId: 1 (0x1)

   SessionId: 4406368010297 (0x401F0000039)

   CClose:

   Size: 24 (0x18)

   Flags: 1 (0x1) <- Post-query attributes

   Reserved: 0 (0x0)

   Fid:

   Persistent: 9 (0x9)

   Volatile: -4294967295 (0xFFFFFFFF00000001)

6. Сервер отвечает SMB2 Close Response сообщая об удачном закрытии файла

   Smb2: R CLOSE

   Status: STATUS_SUCCESS

   Command: CLOSE

   Flags: 1 (0x1)

   ServerToRedir: ...............................1 Server to Client

   MessageId: 12 (0xC)

   ProcessId: 65279 (0xFEFF)

   TreeId: 5 (0x5)

   SessionId: 4398046511121 (0x40000000011)

   RClose:

   Size: 60 (0x3C)

   Flags: 1 (0x1)

   Reserved: 0 (0x0)

   CreationTime: 127972990708847232 (0x1C6A6C1CC0B9280)

   LastAccessTime: 127972993090343232 (0x1C6A6C259FE5140)

   LastWriteTime: 127972992877715232 (0x1C6A6C24D51DF20)

   ChangeTime: 127972992877715232 (0x1C6A6C24D51DF20)

   AllocationSize: 0 (0x0)

   EndOfFile: 0 (0x0)

Сравнение производительности протоколов SMB и SMB2

А теперь давайте посмотри в жизни “действительную” разницу при использовании SMB2. Для этого был собран тестовый стенд, в котором приняли участия MS Windows 7, Windows 2008R2, Windows 2003.

Как уже упоминалось немного выше, что новый версия протокола SMB значительно лучше работает на большом количестве мелких файлов и на плохих соединениях, с летентностью, к примеру, 200 мс.

Первый случай, копирования по сети с Windows 2008 на Windows 2008 и Windows 2003.

Первый пик, это при копировании по протоколу SMB2, второй же пик, сплошная, это загрузка по SMB1. Как видно, при использовании нового протокола утилизация канала используется на всю мощность. По оси Х идет время. Сразу можно увидеть, какой из протоколов быстрей “переваривает” информацию.

Второй ж пример будет для канала с большой латентностью. Здесь раскрываются возможности технологии pipelining.

На данном примере видно, что время передачи и загрузка канала еще больше разнится. Позволяя SMB2 просто разрывать в клочья SMB1.

А теперь немного статистики. Для этого было взято порядка 7500 файлов, общим размером в 150 мб. Файлы были разного размера: от 1 кб до 10 мб. Так же эти файлы были сжаты в один архив, для проверки работы на одном файле. Тестовый стенд представлял в тот же набор операционных систем, но в этот раз в тесте принял участие еще и канал Wi-Fi. Латентность сети была порядка 1-2 мс.

Общая схема была такой:

Первый тест производился на большом количестве файлов. Копировалось с Windows 7 на сервера под управлением Windows 2008R2 и Windows 2003.

По оси X время в секундах.

Видно, что при использовании SMB2, скорость копирования выше. Преимущество практически не зависит от типа канала: Wi-Fi или Ethernet.

Второй тест производился на одном файле, полученным путем архивации этих же файлов без сжатия. Чем было достигнут тот же размер данных, но в одном файле.

В данном случае преимущество у протокола SMB2 теряется. Скорости копирования идентичны. Так же можно сравнить общие скорости копирования большого количества файлов и одного файла, при одном и том же размере, то скорость обработки одного файла будет больше, т.к. необходимо меньше согласующих команд пересылать между узлами. Тут даже не спасет технологичный SMB2 протокол.

Заключение

На этом завершим краткий обзор “нового” протокола SMB. Как вы уже поняли, его использование позволяет ускорить процесс передачи данных между узлами в сети. Так же к плюсам можно отнести отказ от использования NBT в качестве транспортного протокола. Уменьшена зашумленность сетевого канала.

Новые ОС Microsoft уже во всю используют его, что очень радует.

Баканов Денис

MCSE+S; MCITP EA

Оригинал статьи

itband.ru

windows — Самый простой способ реализовать перенаправление SMB для Windows?

Я хотел бы реализовать небольшой инструмент, который позволяет мне делать в Windows то, что я могу уже сделать легко на любой другой ОС — указать удаленный SMB-сервер как по IP-адресу , так и по порту. Естественно, Windows не будет делать SMB по любым портам, кроме 445 или 139 (по своему выбору), и мне не нравится играть whack-a-mole с обходными решениями для различных Bad Things, которые Microsoft продолжает добавлять в Windows, чтобы выполнить туннелирование SMB через пересылку портов SSH.

Что я имею в виду, это небольшое приложение командной строки, которое позволит мне сделать что-то вроде

netsubst servername -i IP -p PORT

Это будет работать рука об руку с драйвером? Dll? который перехватывает Windows как перенаправитель SMB, но просматривает таблицу имен серверов, созданных netsubst, вместо того, чтобы искать их в сети, чтобы узнать, к чему подключиться. Поэтому я мог бы сделать

net use X://имя_сервера/sharename/user: имя пользователя *

обычным способом, за исключением того, что вместо Windows, ищущего//имя_сервера на портах 445 или 139 любых машин, которые он мог найти, он перешел прямо к адресу IP, port PORT; и если IP оказался 127.0.0.1, и PORT оказался чем-то перенаправленным в другое место через ssh, все это бы просто работало, и мне больше не нужно было бы разбираться со стенами глупостей, которые Windows предоставляет доступ к локальным портам 139 и 445.

Я полагаю, что мне нужно что-то похожее на гостевое дополнение //vboxsvr, которое VirtualBox использует для совместного использования файлов хоста, но, вероятно, более простой, поскольку для моего идеального мира не нужен полный конец — только. Функциональность Windows, которую мне нужно заменить, — это часть, которая устанавливает начальное подключение к удаленному SMB-серверу. Но прежде чем я начну врываться в исходный код VirtualBox, может ли кто-нибудь предложить более простой способ сделать это, или, возможно, указать мне на документацию Microsoft по внедрению редиректоров SMB?

qaru.site

SMB 3.0 в файловом сервере нового поколения | Windows IT Pro/RE

Протокол Server message block (SMB) в той или иной форме используется в любой организации для доступа к хранилищам. Это может быть доступ к сценариям регистрации, установочным дискам с программным обеспечением, либо к пользовательским документам и коллекции музыки MP3. Где SMB не применяется, так это в протоколах доступа к файлу (здесь клиент вместо прямого доступа к блокам на диске получает доступ к файлам) при обращении корпоративных приложений к внешнему хранилищу. Что касается обмена данными с хранилищем в корпоративной рабочей среде, то в списке лидируют блочные технологии (где сервер напрямую взаимодействует с блоками на диске), такие как iSCSI и Fibre Channel (и, возможно, NFS для отличных от Windows рабочих приложений).

. Когда пользователь редактирует документ Microsoft PowerPoint, хранящийся на общем ресурсе SMB, части этого документа локально кэшируются, и время от времени пользователь нажимает кнопку «Сохранить». При возникновении проблемы на файловом сервере SMB, например связанной с перезагрузкой, либо с перемещением общей папки на другой узел кластера (если сервер является частью кластера), пользователь теряет дескриптор доступа к файлу, но без каких-либо последствий. При следующем нажатии кнопки «Сохранить» все восстанавливается, и ничего страшного не происходит. Теперь рассмотрим Hyper-V и виртуальную машину, хранящуюся на файловом ресурсе SMB общего доступа. При возникновении проблемы с хостом общий ресурс перемещается на другой узел кластера. Hyper-V ожидает наступления тайм-аута TCP, после чего констатирует ошибку первоначального соединения. Для виртуальной машины это может означать 30-секундную паузу. Однако Hyper-V уже утратил дескрипторы на виртуальном жестком диске VHD, а это более серьезная проблема. Если продолжительность работы с пользовательским документом может исчисляться несколькими часами, то корпоративные службы, виртуальные машины и базы данных требуют бесперебойной доступности файловых дескрипторов на протяжении многих месяцев.

К счастью, SMB 3.0 решает эту проблему (как и многие другие). При создании Windows Server 2012 было решено сделать SMB протоколом хранилища файлового уровня, способным обслуживать критически важные корпоративные рабочие нагрузки, такие как Microsoft Hyper-V и SQL Server. Эта перемена требовала крупных изменений в протоколе SMB.

Прозрачная отказоустойчивость

Применительно к обслуживанию корпоративных данных (например, виртуальных машин или баз данных SQL Server) SMB, как правило, используется не на отдельном файловом сервере, а на кластере, что должно обеспечить высокую доступность. При реализации службы файлов на кластере на одном из узлов обычно монтируется логический том с номером LUN, содержащий общую файловую систему и открывающий доступ клиентам SMB к ресурсу общего доступа. При отказе этого узла LUN монтируется на другом узле кластера. При этом клиент SMB теряет файловые дескрипторы.

Служба SMB Transparent Failover обеспечивает защиту от отказа узла. Перемещение общего ресурса между узлами совершается абсолютно прозрачно для клиентов SMB, что позволяет им сохранять все существующие файловые дескрипторы и иметь бесперебойное соединение SMB.

Соединение SMB поддерживается между тремя объектами: клиентом SMB, сервером SMB и диском, на котором содержатся данные. Прозрачная отказоустойчивость SMB гарантирует существование достаточных условий для передачи соединения SMB альтернативному узлу в случае отказа, что позволяет бесперебойно осуществлять процессы, зависящие от SMB.

Однако даже прозрачная отказоустойчивость SMB Transparent Failover не исключает паузы в операциях ввода/вывода, когда LUN монтируется на другом узле кластера. Группа разработчиков отказоустойчивой кластеризации проделала огромную работу по оптимизации демонтажа и монтажа LUN, сократив максимальную длительность этой процедуры до 25 секунд. Это время кажется долгим, но оно относится к наиболее неблагоприятному сценарию с участием большого числа логических устройств и десятков тысяч дескрипторов. Для наиболее распространенных сценариев эта процедура будет выполняться за пару секунд, а корпоративные службы, такие как Hyper-V и SQL Server, способны обрабатывать 25-секундную паузу в работе подсистемы ввода/вывода без ошибок.

Другая возможная причина перерыва в работе подсистемы ввода/вывода – неосведомленность клиента SMB о недоступности сервера SMB. В обычном сценарии (например, при перезагрузке узла после установки исправлений) сервер уведомляет клиентов о происходящем, и они могут принять соответствующие меры. Но при аварийном отказе хоста клиенты уведомлений не получают. В этом случае клиент ожидает наступления тайм-аута TCP, прежде чем принимает меры по восстановлению соединения, что означает бесполезную трату ресурсов. Клиент SMB может не знать о том, что узел, с которым он взаимодействует, вышел из строя, однако другие узлы в кластере узнают об этом менее чем за секунду, благодаря сообщениям синхронизации IsAlive, которыми обмениваются узлы.

Благодаря этому знанию новая служба-свидетель Witness Service в Windows Server 2012 позволяет одному из узлов кластера выступать свидетелем по отношению к клиенту SMB. Если узел, с которым общается клиент, выходит из строя, то узел-свидетель уведомляет об этом клиента SMB, что позволяет клиенту подключиться к другому узлу, а время прерывания обслуживания сокращается до пары секунд. Диалог выглядит примерно так (с использованием 1 и 0 вместо слов):

Клиент SMB – серверу A: «Я хочу установить соединение».

Сервер A: «Соединение установлено. Я являюсь частью кластера, в котором также есть серверы B, C и D».

Клиент SMB – серверу B: «Я установил соединение SMB с сервером A. Прошу наблюдать за сервером A и уведомить меня в случае его отказа».

Сервер B: «ОК. Удачного дня».

Чтобы воспользоваться преимуществами прозрачной отказоустойчивости SMB или службы-свидетеля, ничего делать не нужно. При создании нового ресурса общего доступа на отказоустойчивом кластере Windows Server 2012 функция прозрачной отказоустойчивости SMB включается автоматически. Процесс создания нового ресурса на кластере файловых серверов Windows Server 2012 направляет мастер. Вначале требуется решить, какой тип ресурса вы создаете. Ответ на этот вопрос помогает установить некоторые параметры по умолчанию для создаваемого ресурса, как показано на экране 1. Для всех типов ресурсов SMB режим Enable continuous availability включен (см. экран 2).

Экран 1. Создание общего файлового ресурса

Экран 2. Включение режима прозрачной отказоустойчивости

Схема SMB «активный/активный»

Ранее я уже говорил о необходимости сокращения паузы в работе подсистемы ввода-вывода при перемещении совместно используемого LUN с узла на узел. Похожая проблема возникает у Windows Server 2008 Hyper-V при перемещении виртуальных машин между узлами. Дело в том, что NTFS не является файловой системой коллективного пользования и не предусматривает возможность одновременного доступа к ней нескольких экземпляров операционной системы без риска повреждения. Эта проблема была решена за счет поддержки общего тома кластера cluster shared volume (CSV) в Windows Server 2008 R2. Благодаря CSV все узлы кластера могут одновременно получать доступ к группе логических устройств (LUN) для выполнения операций чтения и записи, что устраняет необходимость в демонтаже LUN на одних узлах и последующем монтаже на других.

Windows Server 2012 расширяет возможности применения CSV для конкретного типа файлового сервера, а именно, нового масштабируемого файлового сервера. Этот новый вариант предназначен для использования только при коллективном доступе к данным приложений, таких как базы данных SQL Server и виртуальные машины Hyper-V. Для других данных по-прежнему доступен традиционный вариант универсального файлового сервера (см. экран 3).

Экран 3. Выбор варианта файлового сервера

Приняв решение задействовать масштабируемый файловый сервер, вы должны будете выбрать CSV в качестве хранилища ресурсов общего доступа. Поскольку общее хранилище доступно для всех узлов кластера, по отношению к нему все узлы будут выступать в роли хоста. Таким образом, соединения клиентов SMB будут распределены по всем узлам, а не сосредоточены на одном. Отказ одного из узлов не повлечет за собой перемещения LUN, что сведет перерывы в работе к минимуму. Это чрезвычайно важно для хранилищ данных приложений, на обслуживание которых и рассчитан масштабируемый файловый сервер.

Использование масштабируемых файловых серверов имеет дополнительные преимущества. При создании обычного файлового сервера необходимо дать новому файловому серверу кластера NetBIOS-имя и уникальный IP-адрес. Этот IP-адрес должен храниться на том узле кластера, который в данный момент хостирует файловый сервер. При использовании масштабируемых файловых серверов хостами являются все узлы кластера. Таким образом, никаких дополнительных IP-адресов не требуется. Точкой доступа к IP-адресам узлов кластера служит распределенное сетевое имя Distributed Network Name (DNN).

Следует отметить, что, хотя все узлы в кластере способны выполнять одни и те же серверные функции и обслуживать доступ к коллективному ресурсу, при использовании масштабируемого файлового сервера каждый клиент SMB единовременно подключается только к одному узлу. Инициируя соединение, клиент SMB получает список IP-адресов всех хостов в кластере. Из списка клиент выбирает один узел, с которым начинает сеанс связи SMB. Впоследствии клиент использует только этот узел, пока на нем не возникают проблемы. Если они возникли, клиент обращается к альтернативному узлу, за исключением случаев применения службы-свидетеля.

Защита от ошибки соединения: многоканальное подключение SMB

Прозрачная отказоустойчивость SMB и схема SMB «активный/активный» позволяют избежать перерывов в работе, возникающих из-за отказа узла. Однако существуют и другие типы отказов, например ошибка соединения. Для противодействия подобным проблемам можно применять технологию многопутевого ввода/вывода Microsoft Multipath I/O (MPIO) с поддержкой нескольких маршрутов взаимодействия между сервером и хранилищем. В SMB 3.0 реализована функция многоканального подключения SMB, позволяющая клиенту SMB во время одного сеанса устанавливать несколько соединений, что обеспечивает защиту от ошибок подключения и повышает производительность.

Подобно большинству функций SMB 3.0, многоканальное подключение SMB реализуется автоматически. После первоначального установления соединения SMB клиент SMB ищет дополнительные маршруты взаимодействия с сервером SMB. При наличии нескольких сетевых соединений используются эти альтернативные пути. Работа функции многоканального подключения SMB становится очевидной при отслеживании операции копирования файлов, так как сначала используется пропускная способность, эквивалентная одному соединению, при втором подключении полоса пропускания удваивается, при третьем – продолжает увеличиваться, и так далее. При ошибке одного из подключений другие соединения продолжают обслуживать канал соединения SMB без перебоев.

Определить, работает ли на сервере функция многоканального подключения SMB, можно с помощью команды PowerShell Get-SMBConnection, позволяющей вывести список подключений SMB к ресурсу общего доступа. На экране 4 показан результат выполнения этой команды. Как мы видим, используется только одно подключение к серверу.

Эта информация указывает на наличие единственного пригодного к использованию маршрута связи между клиентом SMB и сервером SMB. Если запустить команду Get-SmbMultichannelConnection с клиента, то ее выходным результатом будет список всех возможных путей, по которым можно установить соединение с сервером (см. экран 5).

Однако этот список формируется в результате «отложенной» проверки и не означает, что данный маршрут действительно может быть установлен между IP-адресами 10.1.3.1 и 10.1.2.1 клиента и сервера.

Узнать, какой путь фактически используется между клиентом и сервером, можно по ТСР-подключениям к удаленному порту 445, используемому для SMB. В моем случае проверка подтверждает, что я использую единственный возможный путь, а именно, удаленный адрес 192.168.1.30 (см. экран 6).

В отношении подключения клиента SMB к общему ресурсу SMB, хостируемому кластером по схеме «активный/активный», возникает очевидный вопрос: устанавливаются ли эти несколько вариантов соединений с разными узлами кластера? Ответ — нет. Клиент SMB получает один IP-адрес, принадлежащий одному из узлов в кластере, и все соединения устанавливаются с этим узлом. Все сеансы SMB для данного кластера, инициируемые клиентом SMB, всегда проходят с участием одного и того же узла. Это не вызывает проблем, поскольку кластер высокой отказоустойчивости, как правило, имеет сотни, если не тысячи, подключений клиентов SMB. Нагрузка распределяется равномерно по всему кластеру.

Максимальное увеличение пропускной способности: масштабирование на стороне приема и удаленный доступ к памяти

Еще один аспект SMB 3.0, на который следует обратить внимание, касается крупных магистралей сетевых соединений в современных информационных центрах. Многие информационные центры уже перешли со стандарта 1 Гбит/с на стандарт 10 Гбит/с. Однако по мере такого перехода проблему с производительностью начинает создавать процессор на сервере. Одно TCP-соединение может обрабатываться только одним ядром процессора, которое не способно справиться с 10-гигабитным потоком и таким образом ограничивает пропускную способность. Именно здесь оказывается полезной функция масштабирования на стороне приема Receive Side Scaling (RSS), с помощью которой единый сетевой интерфейс разделяется на несколько принимающих соединений, каждое из которых обслуживается отдельным процессорным ядром. Это позволяет в полной мере использовать имеющуюся пропускную способность. Большинство сетевых адаптеров современных серверов автоматически поддерживают RSS. Определить, поддерживает ли данное оборудование RSS, можно с помощью команды Get-SmbMultichannelConnection (см. экран 7).

Экран 7. Команда Get-SmbMultichannelConnection показывает доступность RSS

Заметим, что в выходных данных команды указано число 4 в качестве значений CurrentChannels и MaxChannels. Это значение по умолчанию для Windows Server 2012 при использовании сетевых карт с поддержкой RSS.

Если теперь проверить состояние многоканального SMB-соединения с сервером (см. экран 8), можно увидеть, что для IP-адреса, используемого SMB, установлены четыре отдельных соединения, что указывает на работу функции RSS.

Может возникнуть вопрос: почему сетевой интерфейс с поддержкой RSS по умолчанию разделен на четыре соединения? В этом можно убедиться с помощью команды PowerShell Get-SmbClientConfiguration, позволяющей просмотреть настройки клиента SMB. В первой строке полученных в ответ данных будет указано число соединений на один сетевой интерфейс RSS. Это значение можно изменить, но оно выбрано не случайно. В Microsoft был проведен большой объем тестирования 10-гигабитных соединений, в ходе которого выяснилось, что четыре соединения дают наибольший выигрыш, тогда как при дальнейшем увеличении их числа этот выигрыш уменьшается. Тем не менее, если у вас есть соединения с пропускной способностью свыше 10 Гбит/с, то увеличение этого значения может дать положительный эффект.

Удаленный прямой доступ к памяти Remote Direct Memory Access (RDMA) – еще одна технология, позволяющая повысить пропускную способность и минимизировать нагрузку на сервер. Сетевые адаптеры с поддержкой RDMA могут обходить большую часть сетевого стека и соединяться напрямую, что позволяет снять нагрузку с хост-серверов. С помощью ранее упомянутой команды Get-SmbMultichannelConnection можно узнать, поддерживает ли сетевой адаптер RDMA. Начальная инициализация соединения SMB предусматривает проверку наличия поддержки RDMA на обоих концах соединения. Если такая поддержка есть, то соединение переключается на RDMA. В этом случае также никакой ручной настройки не требуется.

Мощное решение

SMB 3.0 используется только между операционными системами с поддержкой SMB 3.0, то есть Windows Server 2012 и Windows 8. Для других операционных систем применяется новая общая для них поддерживаемая версия SMB, определяемая в ходе взаимного согласования возможностей. Например, если система Windows 7 подключается к файловому серверу Windows Server 2012, то используется SMB 2.1, поскольку это самая новая из поддерживаемых Windows 7 версий.

Основным побудительным мотивом для внесения большинства изменений в SMB 3.0 было стремление сделать SMB протоколом для корпоративных приложений. Именно в этой сфере реализуется наибольший положительный эффект от применения SMB. Есть также выгоды для постоянных клиентов – например, тех, кто перешел на Windows 8. SMB 3.0 недоступен для версий, предшествующих Windows 8 и Windows Server 2012. Например, новое шифрование SMB устраняет необходимость в сложных инфраструктурах открытых ключей public key infrastructure (PKI) для обеспечения безопасности. В комбинации со многими другими реализованными в Windows Server 2012 усовершенствованиями хранилищ, SMB 3.0 переводит новую операционную систему в разряд мощных решений для хранения данных и открывает перед клиентами еще более широкие возможности.

www.osp.ru

Проблемы с доступом к шарам по SMB over NETBIOS из других подсетей

Только разобрались с обновлением MS16-072, меняющим привычную схему работы GPO, как обнаружились проблемы с еще одним июньским бюллетенем безопасности — MS16-077 и обновлением KB3165191. После установки этого обновления на серверные системы, стало невозможно подключиться по протоколу Netbios over TCP/IP к сетевым шарам с клиентов, расположенных в других ip подсетях.

Проблема в первую очередь проявилась с сетевыми сканерами, которые выполняют сканирование документов и складывают сканы в сетевую папку (SMB) на сервере. Документы перестали сохранятся, а на самом сканере появляется ошибка Cannot connect to server. Также возникли проблемы при подключении Samba клиентов к контроллерам домена (ошибки Access Denied  и No Logon Server Available). Что интересно, проблемы с доступом к Windows шарам возникли только у клиентов, расположенных в отличных от сервера подсетях.

После удаления обновления KB3165191 – доступ восстанавливался.

Посмотрим, что же делает обновление KB3165191. Согласно описанию, обновление накладывает ограничения на соединения NETBIOS из-за пределов локальной подсети. Таким образом, сетевой функционал, зависящий от NETBIOS (такой как SMB over NETBIOS, порты 137-139) не будет работать для клиентов из других подсетей. Обычный протокол SMB (445) порт при этом доступен отовсюду.

sc config lanmanworkstation depend= bowser/mrxsmb10/nsi

sc config mrxsmb20 start= disabled

sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi

sc config mrxsmb20 start= auto

 HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters

Value name: Smb2

Value type: REG_DWORD

0 = отключено

1 = включено