Сетевая папка Windows Server через SMB: настройка общего доступа

«Сетевая папка не открывается, мы не можем работать!» — бухгалтерия в панике, отдел продаж подтягивается. Вы проверяете сервер — служба работает, диск на месте, NTFS-права в порядке. А потом находите: коллега из ИБ закрыл порт 445 «для безопасности» после пятничного аудита. Знакомо?

За этим портом стоит SMB — Server Message Block. Тот протокол, через который Windows Server раздаёт сетевые папки, принтеры и всё, что привыкли видеть в «Сетевом окружении». Протокол, который появился в 1983 году в лабораториях IBM и с тех пор прошёл путь от неуклюжего CIFS до зашифрованного, сжатого и работающего через QUIC транспорта.

Разберёмся, как настроить общий доступ к папкам, не наступить на грабли с правами и не оставить дыр в безопасности.

SMB работает поверх TCP (порт 445) и отвечает за всё, что связано с сетевым доступом к файлам в Windows-среде: от маппинга сетевых дисков до DFS-пространств имён и кластерных хранилищ. Даже Hyper-V использует SMB для live migration виртуальных машин между хостами. Когда говорят «сетевая папка на Windows Server» — подразумевают именно SMB, даже если не произносят этого вслух.

От CIFS до SMB 3.1.1: что изменилось и почему это важно

Когда Барри Фейгенбаум написал первую реализацию SMB для IBM PC DOS, протокол умел базовые вещи — открыть файл, прочитать, закрыть. К моменту, когда Microsoft переименовала SMBv1 в CIFS (1996 год), протокол раздулся до сотни с лишним команд. Работало это ровно так, как звучит — медленно и непредсказуемо, особенно через WAN.

SMB 2.0 в Windows Server 2008 стал радикальным упрощением: 100+ команд сжались до 19. Появилась конвейерная обработка запросов, и работа через VPN-каналы перестала вызывать желание перейти на FTP.

SMB 3.0 принёс Multichannel — агрегацию нескольких сетевых интерфейсов без настройки bonding. А SMB 3.1.1, актуальная версия, добавила pre-authentication integrity (защита от downgrade-атак), сжатие трафика и шифрование AES-256-GCM.

Если Ваш парк серверов — Windows Server 2016 и новее, все клиенты будут согласовывать минимум SMB 3.0. Версия протокола выбирается автоматически: сервер и клиент обмениваются списком поддерживаемых диалектов при установке сессии и останавливаются на высшем общем. Проверить, какая версия используется в конкретном соединении, можно командой Get-SmbConnection на клиенте — столбец Dialect покажет 3.1.1, 3.0.2 или что-то менее приятное.

Зачем отключать SMBv1 и как это сделать

Факт: Уязвимость CVE-2017-0144 в SMBv1 (эксплойт EternalBlue) дала WannaCry заразить 230 000 машин в 150 странах за один день — май 2017.

EternalBlue эксплуатирует ошибку в обработке пакетов SMBv1-сервером. Атакующий отправляет специально сформированный пакет на порт TCP 445 — и получает выполнение произвольного кода с системными привилегиями. Никакой аутентификации не требуется.

Microsoft отключила SMBv1 по умолчанию начиная с Windows Server 2019 и Windows 10 версии 1709. Но если Вы работаете с legacy-инфраструктурой или обновляли сервер «на месте» с предыдущих версий, протокол мог остаться активным.

Проверка:

Get-SmbServerConfiguration | Select EnableSMB1Protocol

Отключение:

Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

Если в сети есть старые МФУ, NAS-устройства или контроллеры, которым нужен SMBv1, — изолируйте их в отдельный VLAN. Включать первую версию протокола на файловом сервере ради одного принтера — сомнительный размен. Кстати, для включения SMBv1 обратно (если уж прижало) используется Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol — но после этого обязательно включайте аудит и контролируйте трафик.

А ещё полезная привычка — проверять, не установлена ли роль SMB 1.0/CIFS File Sharing Support в компонентах Windows. На серверах, мигрировавших с 2012 R2, она иногда остаётся как призрак прошлого.

Создаём сетевую папку: Server Manager vs PowerShell

Роль File and Storage Services есть в Windows Server по умолчанию. Если нужен полный набор инструментов — добавьте компонент File Server через Server Manager → Add Roles and Features. Там же можно доставить File Server Resource Manager (FSRM) — штука полезная, если хотите квотировать дисковое пространство или блокировать сохранение .exe и .mp3 на файловых шарах.

Через GUI путь простой: Server Manager → File and Storage Services → Shares → Tasks → New Share. Wizard проведёт через выбор профиля (SMB Share — Quick или Advanced), указание пути, настройку прав. Профиль Quick создаёт шару с базовыми настройками, Advanced — позволяет сразу задать квоты, классификацию файлов и Access-Based Enumeration. На выходе — готовая шара с автоматически созданной папкой.

Но если серверов у Вас пять, десять, двадцать — wizard начинает раздражать на втором. PowerShell:

# Создаём папку

New-Item -Path "D:\SharedData\Finance" -ItemType Directory

# Создаём шару с правами

New-SmbShare -Name "Finance" `

    -Path "D:\SharedData\Finance" `

    -FullAccess "DOMAIN\IT-Admins" `

    -ChangeAccess "DOMAIN\Finance-Team" `

    -ReadAccess "DOMAIN\Auditors" `

    -EncryptData $true `

    -FolderEnumerationMode AccessBased

Параметр -FolderEnumerationMode AccessBased включает Access-Based Enumeration: пользователь видит только те папки и файлы, к которым у него есть доступ. Мелочь, а избавляет от вопросов «почему мне показывает папку, которую я не могу открыть?».

Share Permissions vs NTFS: вечный источник путаницы

Два уровня прав — два уровня головной боли. Share Permissions контролируют доступ по сети. NTFS Permissions — на уровне файловой системы. Когда пользователь обращается к сетевой папке, применяется пересечение этих прав, причём побеждает то, что строже.

Рабочая схема: выставляете Share Permissions в «Authenticated Users — Full Control» и управляете доступом исключительно через NTFS. Два параллельных набора правил — гарантированный путь к ситуации, когда «у Иванова доступ есть, а у Петровой нет, хотя они в одной группе».

Ещё один нюанс, который регулярно ломает голову: при подключении через UNC-путь (\\server\share) срабатывают оба уровня. Но если зайти на сервер локально — Share Permissions игнорируются, работают только NTFS. Поэтому тестировать права нужно именно через сеть, с клиентской машины, под учётной записью целевого пользователя. Утилита Effective Access во вкладке Security → Advanced покажет итоговый набор разрешений — экономит время вместо ручного разбора наследования.

Безопасность: шифрование, подписи, rate limiting

SMB 3.0+ умеет шифровать трафик на уровне протокола — без IPsec, без VPN, без дополнительных сертификатов. Windows Server 2022 поддерживает AES-256-GCM и AES-256-CCM. Сервер и клиент согласовывают алгоритм автоматически, выбирая доступный с обеих сторон.

Совет: Команда Set-SmbServerConfiguration -RejectUnencryptedAccess $true запрещает серверу обслуживать незашифрованные соединения — одна строка закрывает MITM-сценарии.

Подписывание пакетов (SMB Signing) защищает от подмены данных в транзите. Windows 11 24H2 сделала signing обязательным для всех исходящих SMB-подключений. Если в сети остались устройства со старой прошивкой или Samba ниже 4.6 — они перестанут подключаться. Решение: обновить или добавить исключение через групповую политику.

Ещё одна деталь — rate limiter аутентификации. Windows Server вставляет двухсекундную задержку после неудачной попытки входа. Это не панацея от brute-force, но снижает скорость перебора до уровня «нерентабельно». Настраивается через реестр или GPO, а в связке с политиками блокировки учётных записей даёт неплохой эшелон защиты.

Отдельный момент — Windows Firewall. Порт TCP 445 по умолчанию закрыт для внешних подключений. Не открывайте его наружу — никогда. Если нужен удалённый доступ к файлам, используйте VPN или SMB over QUIC (о нём ниже). Открытый 445-й порт в интернете — это не вопрос «будут ли ломать», а вопрос «через сколько минут».

Аудит обращений к SMBv1 (если он ещё включён):

Set-SmbServerConfiguration -AuditSmb1Access $true

После включения события пишутся в журнал Applications and Services → Microsoft → Windows → SMBServer → Audit. Так Вы узнаете, какие клиенты до сих пор стучатся по первой версии протокола.

Multichannel, сжатие и производительность

SMB Multichannel включается автоматически, если у сервера и клиента есть несколько сетевых интерфейсов или один интерфейс с RSS. Никакого NIC teaming настраивать не надо — протокол сам открывает параллельные соединения и балансирует нагрузку. Допустим, у файлового сервера два 10GbE-порта — SMB Multichannel задействует оба и даст агрегированную пропускную способность 20 Гбит/с без какой-либо настройки со стороны администратора. Если один интерфейс упадёт — трафик автоматически пойдёт через оставшийся. Отказоустойчивость бесплатно.

Проверить активные каналы:

Get-SmbMultichannelConnection

Сжатие трафика (SMB Compression) появилось в Windows Server 2022. Алгоритм XPRESS (LZ77) применяется к файлам при передаче — экономит полосу на медленных каналах. Включается на уровне шары:

New-SmbShare -Name "Archive" -Path "D:\Archive" -CompressData $true

Или для существующей шары:

Set-SmbShare -Name "Archive" -CompressData $true -Force

На 100-гигабитных линках между серверами с NVMe-массивами выигрыш от сжатия минимален — процессорные циклы на компрессию съедят экономию. А вот на гигабитном канале до филиала разница заметна, особенно при передаче текстовых файлов и баз данных.

SMB over QUIC: доступ без VPN

SMB over QUIC — альтернатива классическому TCP-транспорту. Вместо порта TCP 445 используется UDP 443 с обязательным TLS 1.3. Фактически это VPN-туннель, встроенный в сам протокол: весь SMB-трафик, включая аутентификацию, идёт внутри зашифрованного QUIC-соединения.

Зачем это нужно: удалённые сотрудники получают доступ к файловым шарам без корпоративного VPN. Порт 443 открыт в большинстве сетей, включая гостиничные Wi-Fi и мобильные хотспоты. Все привычные функции SMB — signing, compression, multichannel — работают внутри QUIC-туннеля без изменений.

Ограничение: в Server 2022 SMB over QUIC доступен только в Datacenter: Azure Edition. В Windows Server 2025 поддержка расширена на стандартные редакции. Клиентская часть требует Windows 11.

Настройка требует TLS-сертификат на сервере. QUIC-соединение начинается с TLS 1.3 handshake — без валидного сертификата клиент просто не подключится. Для доменных сред подойдёт внутренний CA (AD CS), для внешнего доступа — публичный сертификат. На клиенте подключение выглядит так:

New-SmbMapping -RemotePath "\\fs01.contoso.com\Data" -TransportType QUIC

Или через net use:

net use Z: \\fs01.contoso.com\Data /TRANSPORT:QUIC

QUIC использует UDP, поэтому файрволы, настроенные на пропуск только TCP, заблокируют трафик. Убедитесь, что UDP 443 открыт на всём пути от клиента до сервера.

Scale-Out File Server: когда одного сервера мало

Для Hyper-V кластеров, VDI и нагруженных файловых сервисов есть Scale-Out File Server (SOFS). Это кластерная роль, где CSV-тома (Cluster Shared Volumes) обслуживаются всеми нодами одновременно. Клиент подключается к кластерному имени, а не к конкретному серверу, и получает автоматический failover.

SOFS работает поверх SMB 3.0+ и активно использует Multichannel и SMB Direct (RDMA). Если Вы строите инфраструктуру с Storage Spaces Direct — SOFS становится логичным способом раздать хранилище по сети.

Для VDI-сценариев SOFS особенно хорош: сотни виртуальных рабочих столов обращаются к VHDX-файлам через SMB, а кластер распределяет нагрузку между нодами. При выходе одной ноды из строя клиенты переключаются на другую без разрыва сессии — Continuous Availability в SMB 3.0 обеспечивает persistent handles, которые переживают failover.

Troubleshooting: когда шара не работает

Три команды, которые экономят часы:

# Статус SMB-сервера и его настроек

Get-SmbServerConfiguration

# Список активных сессий — кто подключён прямо сейчас

Get-SmbSession

# Открытые файлы — кто что держит

Get-SmbOpenFile

Event ID 1020 в журнале SMBServer/Operational — клиент отключён по таймауту. Event ID 551 — ошибка аутентификации. Если видите высокую загрузку CPU на srv.sys — скорее всего, signing или encryption перегружают процессор. Решение: RDMA-карты с аппаратным offload или пересмотр политики шифрования для внутренних сегментов.

Классическая проблема: пользователь не может подключиться к шаре, ошибка «Access Denied». Алгоритм диагностики: сначала проверяете Test-NetConnection -ComputerName server -Port 445 — убеждаетесь, что порт доступен. Потом Get-SmbShareAccess -Name "ShareName" — смотрите Share Permissions. Затем icacls D:\SharedData\Finance — проверяете NTFS. В 80% случаев проблема именно в рассогласовании этих двух слоёв.

Для глубокой диагностики есть встроенная трассировка:

netsh trace start scenario=FileSharing capture=yes

# воспроизводите проблему

netsh trace stop

На выходе — ETL-файл, который открывается в Microsoft Message Analyzer или Wireshark с плагином. Трассировка покажет каждый SMB-запрос с таймингами — удобно для отлова проблем с latency, когда шара «вроде работает, но Word открывает файл по 30 секунд». Не забудьте остановить трассировку после воспроизведения проблемы — файл растёт быстро и может съесть диск, если оставить его работать.

Что дальше

SMB никуда не уходит. Протоколу 40 с лишним лет, и за это время он пережил NetBIOS, WannaCry, миграцию в облако — и стал только крепче. QUIC-транспорт, обязательное шифрование, интеграция с кластерными хранилищами — всё это говорит об одном: файловый доступ по SMB остаётся фундаментом Windows-инфраструктуры.

Samba уже работает над поддержкой QUIC в Linux, а Microsoft продолжает добавлять возможности в Windows Server 2025. Вопрос не в том, использовать ли SMB, а в том, какую версию и с какими настройками безопасности. Если в Вашей инфраструктуре до сих пор жив SMBv1 — сегодня хороший день, чтобы это исправить.