Обмін файлами по VPN між офісами: стабільний SMB без постійних відключень

October 15, 2025 • February 3, 2026 • Читання: 6 хв • Views: 11

Було корисно?

Нічого так не викликає ненависті до «IT», як мережевий диск, що відключається посеред збереження. Користувачам байдуже, що у вас «сучасний SD‑WAN» або що панель фаєрвола зелена. Їх хвилює, що Excel відкривався 45 секунд, потім завис, а потім запропонував зберегти копію для відновлення з іменем ~$Budget_FINAL_v7_REALFINAL.xlsx.

SMB між офісами може бути стабільним. Але треба ставитися до нього як до розподіленої виробничої системи, а не просто як до «літерного диска через тунель». Тунель — лише початок: MTU, DNS, маршрутизація, таймаути фаєрвола, діалект/фічі SMB та бекенд сховища спільно створюють відключення, що здаються випадковими. Насправді вони не випадкові — просто їх мало інструментовано.

Що саме ламається, коли SMB переходить через VPN

SMB (протокол файлового обміну Windows) дуже «балакучий». Сучасний SMB3 значно краще за старі часи, але він усе ще виконує багато дрібних запитів/відповідей: negotiate, authenticate, tree connect, create/open, lock, read/write, запити метаданих, перелік каталогу, opportunistic locks, durable handles, leases. Кожен із цих елементів чутливий до затримки, втрат пакетів і скидань стану.

Коли ви переносите SMB з LAN в «LAN‑подібне, але не зовсім» (два офіси з тунелем між ними), ваші режими відмов множаться:

Затримка підсилює балакучість. Перегляд папок і послідовності відкриття файлів перетворюються на моменти «чому він думає?».
Втрати пакетів перетворюються на відключення. Не тому, що SMB кволий, а тому, що станні елементи (тунелі VPN, таблиці NAT, сесії фаєрвола) чутливі до пропадань або перестановки пакетів.
Проблеми з Path MTU викликають затримки, що виглядають як зависання додатків. Jumbo‑фрейми та інкапсуляція VPN — класичне поєднання для «працює з малими файлами, зависає з великими».
Таймаути сесій спрацьовують для файлів, що залишаються відкритими довго. Користувачі залишають файли відкритими годинами. SMB тримає сесію. Пристрій тунелю може — і не тримати.
DNS і автентифікація плутаються між сайтами. Kerberos вимогливий до часу, DNS і SPN. Якщо падає назад на NTLM через латентний канал, ви отримаєте таймаути і запити паролів у користувачів.
Фічі безпеки можуть коштувати пропускної спроможності. Підписування та шифрування SMB — корисні механізми. Вони також множать навантаження на CPU і затримку, якщо їх увімкнено без розбору.

Операційна помилка — вважати, що SMB це «просто TCP/445». Це не так. Це станозалежний прикладний протокол, а досвід користувача визначається найповільнішою частиною системи. Часто ця найповільніша частина — не пропускна здатність VPN, а швидкість IOPS сховища, таблиця сесій фаєрвола або неправильно встановлений MTU.

Є думка Вернера Фогельса, яку варто тримати як компас: Усе ламається постійно (парафразована думка). SMB між офісами — це ваше рішення, які відмови будуть граціозними, а які перетворяться на «шер не доступний».

Цікаві факти та історичний контекст

Трохи контексту допомагає, бо SMB несе десятиліття проєктних рішень. Кілька конкретних фактів, що пояснюють, чому «воно кволо» зазвичай означає «ми використовуємо його поза зоною комфорту».

SMB виник у 1980‑х. Він розроблявся для малих локальних мереж, де затримка фактично «була не суттєвою».
CIFS — це скоріше маркетингова назва для епохи SMB1. «CIFS» зазвичай вказує на поведінку SMB1; це не те, що вам потрібно через WAN сьогодні.
SMB2 (епоха Vista/Server 2008) — значне переписування. Він зменшив балакучість і покращив пайплайнинг, що важливо через VPN.
SMB3 (Windows 8/Server 2012) додав durable handles і multichannel. Durable handles важливі для тимчасових проблем мережі; multichannel може допомогти на серверах з кількома NIC, але також заплутати мережу при асиметричній маршрутизації.
Шифрування SMB з’явилося в SMB3. Воно налаштовується на рівні шарів сесії/шару; може захистити вас у випадку «VPN впав, але шар все ще доступний» — якщо у вас хитра маршрутизація — але воно не безкоштовне.
Opportunistic locks (oplocks) і leases — основа продуктивності SMB. Вони зменшують кількість раунтрипів за рахунок кешування. Водночас можуть створювати «файл заблоковано» драму з погано поводженими додатками, особливо через канали з перериваннями.
DFS Namespaces існує переважно тому, що «ім’я файлового сервера — це ризик». Воно дає непряму адресу: клієнти підключаються до простору імен, а не до конкретного сервера, що дозволяє перенесення і орієнтацію по багатьох сайтах.
Windows давно має Offline Files (Client‑Side Caching). Ця функція рідко використовується, бо її легко неправильно налаштувати, але це одне з небагатьох розумних рішень для «редагування документів через WAN».

Архітектури, що працюють (і ті, що виглядають дешево, але такими не є)

Опція A: Центральний файловий сервер + site-to-site VPN (за замовчуванням)

Найпоширеніше рішення: один сервер у HQ, філії підключаються через IPsec/OpenVPN/WireGuard, користувачі підключають мережеві диски.

Коли працює: затримки помірні (однозначні або низькі десятки мс), VPN стабільний, фаєрвол не агресивно вбиває прості сесії, а сховище достатньо швидке, щоб «відкрити файл» не блокувалося диском.

Коли ламається: більші затримки, втрата пакетів, користувачі відкривають гігантські дерева папок, CAD/Adobe/Outlook PST по шару, або будь‑який додаток, що робить багато викликів метаданих. Також: тунелі, що флапають або занадто часто ренкіють ключі.

Опція B: DFS Namespace + DFS Replication (для домашніх директорій і командних шарів, що терплять eventual consistency)

Якщо у вас два офіси, яким потрібен один і той самий командний шар і строгих одночасних записів не треба, DFS‑N + DFS‑R можуть зменшити крос‑сайтний трафік SMB, зберігаючи локальні репліки. Користувачі здебільшого звертаються до локального сервера.

Компроміс: DFS‑R не є транзакційною розподіленою файловою системою. Конфлікти трапляються. Великі файли реплікуються повільно. Деякі шаблони файлів (багато дрібних файлів, часті перейменування) можуть бути болючими.

Опція C: Файловий сервер у філії з кешуванням (доросла версія «тримати дані локально»)

Поставте сервер (або NAS) у філії і використайте механізм, спроєктований для WAN: BranchCache, сторонні кеші файлів або платформи для співпраці, де «семантика файлового шару» не обов’язкова.

Моя думка: якщо у філії більше ~20 користувачів, які весь день активно працюють з документами, локальний кеш/репліка зазвичай дешевший за те, щоб витрачати години інженерної праці на те, щоб SMB поводився як LAN через WAN.

Опція D: Перестаньте використовувати SMB як інструмент для WAN‑співпраці

Так, серйозно. SMB відмінно підходить у межах сайту. Між сайтами це часто невірна абстракція. Для крос‑офісної співпраці над документами розгляньте платформу синхронізації, DMS або принаймні «локальне редагування з синхронізацією». Залишайте SMB для домашніх дисків, шарів додатків та локальних робочих процесів, де він найкраще працює.

Жарт №1: SMB через хиткий VPN — як стосунки на відстані: можуть працювати, але кожен втрачений пакет стає проблемою довіри.

План швидкої діагностики

Це порядок тріажу, що найшвидше знаходить вузьке місце в реальному середовищі. Не починайте з хаотичного перемикання реєстрових ключів SMB, ніби граєте в whack‑a‑mole.

Перше: тунель чи сервер?

Перевірте стабільність тунелю: ренкі, флапи, DPD/keepalive події, втрата пакетів.
Перевірте здоров’я сервера: CPU, затримки диска, помилки NIC, статистику SMB‑сервера.
Перевірте симптоми на клієнті: відключаються усі користувачі чи тільки певні підмережі/клієнти?

Друге: MTU і фрагментація

Шукайте «малі файли — ок, великі — зависають». Це MTU/MSS, поки не доведено протилежне.
Підтвердіть path MTU наскрізь через інкапсуляцію VPN.
Клацніть MSS на краях VPN, якщо не можете гарантувати PMTUD.

Третє: DNS, AD і час

Kerberos ненавидить розбіжності часу і проблемний DNS.
Переконайтеся, що клієнти у філії резолвлять файловий сервер на очікувану IP‑адресу, а не на прострочений запис або публічну адресу.
Перевірте доступність контролерів домену та відображення сайтів/підмереж у AD, якщо ви в AD.

Четверте: таймаути сесій і таблиці стану

Фаєрволи та NAT‑пристрої вбивають «їдл» сесії, тоді як SMB вважає їх живими.
Пристрої VPN, що часто перебудовують ключі, можуть ламати довгоживучі потоки.
Шукайте шаблони: відключення через точно N хвилин.

Пʼяте: невідповідність функцій SMB

SMB‑підписування/шифрування + слабкий CPU = проблеми.
Multichannel через VPN може дивувати, якщо є кілька шляхів або NAT змінюється.
OpLocks/leases можуть допомогти або створити проблеми залежно від додатків.

Практичні завдання: команди, виводи та рішення

Нижче — реальні завдання, які можна виконувати під час інциденту або в проєкті «зробити це стабільним». Кожне містить команду, приклад виводу, що це означає, і наступне рішення. Комбінація Linux (для VPN/фаєрвола/NAS) і Windows (для клієнтів/серверів SMB) навмисна — ваше середовище ніколи не буває чистим.

Task 1: Prove whether the tunnel is flapping (Linux, WireGuard example)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: zX2...abc=
  listening port: 51820

peer: 8kF...def=
  endpoint: 203.0.113.10:51820
  allowed ips: 10.20.0.0/16
  latest handshake: 18 seconds ago
  transfer: 22.41 GiB received, 19.88 GiB sent
  persistent keepalive: every 25 seconds

Що це означає: «latest handshake» показує нещодавню живість. Якщо це значення стрибає до хвилин/годин під час скарг користувачів, ваша «проблема SMB» насправді — проблема живлення тунелю.

Рішення: Якщо handshake застарілий під час скарг, спочатку виправте маршрутизацію/keepalive/доступність краю тунелю, перш ніж чіпати SMB.

Task 2: Check IPsec rekey churn and DPD events (strongSwan example)

cr0x@server:~$ sudo journalctl -u strongswan --since "2 hours ago" | egrep -i "rekey|deleting|dpd|proposal" | tail -n 20
Dec 27 09:11:03 gw1 charon[1187]: 09[KNL] deleting IKE_SA vpn-to-branch[12] between 198.51.100.2...203.0.113.10
Dec 27 09:11:03 gw1 charon[1187]: 09[IKE] initiating IKE_SA vpn-to-branch[13] to 203.0.113.10
Dec 27 09:11:10 gw1 charon[1187]: 09[IKE] IKE_SA vpn-to-branch[13] established between 198.51.100.2...203.0.113.10
Dec 27 09:12:12 gw1 charon[1187]: 11[NET] sending DPD request
Dec 27 09:12:22 gw1 charon[1187]: 11[NET] DPD response received

Що це означає: Часті цикли delete/initiate можуть розривати TCP‑потоки (привіт, SMB). DPD сам по собі нормальний; постійна реконігація — ні.

Рішення: Якщо ви бачите ренкі кожні кілька хвилин або несподівані видалення, відрегулюйте терміни життя, налаштування повторної автентифікації, NAT keepalive та розслідуйте втрати пакетів вище по ланцюжку.

Task 3: Confirm routing symmetry (Linux)

cr0x@server:~$ ip route get 10.20.5.25
10.20.5.25 dev wg0 src 10.10.0.1 uid 0
    cache

Що це означає: Шлюз відправлятиме трафік до 10.20.5.25 через інтерфейс VPN. Якщо він вибирає WAN інтерфейс, відповіді підуть не тим шляхом і SMB буде «випадково» падати.

Рішення: Виправте таблиці маршрутизації/політику, щоб відповіді для підмереж філії повертались через тунель.

Task 4: Find MTU on the path (Linux ping with DF)

cr0x@server:~$ ping -M do -s 1372 10.20.5.25 -c 3
PING 10.20.5.25 (10.20.5.25) 1372(1400) bytes of data.
1380 bytes from 10.20.5.25: icmp_seq=1 ttl=63 time=18.4 ms
1380 bytes from 10.20.5.25: icmp_seq=2 ttl=63 time=18.7 ms
1380 bytes from 10.20.5.25: icmp_seq=3 ttl=63 time=18.3 ms

--- 10.20.5.25 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Що це означає: 1400‑байтові пакети проходять без фрагментації. Якщо більший розмір викликає «Frag needed», ефективний MTU нижчий, ніж ви думали.

Рішення: Встановіть MTU інтерфейсу VPN відповідно і/або обмежте TCP MSS, щоб SMB не намагався надсилати занадто великі сегменти.

Task 5: Check TCP MSS clamping (Linux iptables example)

cr0x@server:~$ sudo iptables -t mangle -S | grep -i tcp-mss
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Що це означає: MSS‑clamping присутній для пересилених TCP SYN‑пакетів, що допомагає уникнути PMTU чорних дір через VPN.

Рішення: Якщо його немає і у вас є проблеми з MTU, додайте правило на краю VPN (або встановіть MSS явним чином відповідно до інкапсуляції).

Task 6: Measure loss/jitter quickly (Linux, mtr)

cr0x@server:~$ mtr -rwzc 50 10.20.5.25
Start: 2025-12-27T09:20:02+0000
HOST: gw1                           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.0.254                  0.0%    50    0.4   0.5   0.3   1.2   0.2
  2.|-- 10.255.0.2                   0.0%    50   18.5  18.9  17.8  31.2   1.9
  3.|-- 10.20.5.25                   2.0%    50   19.0  19.4  18.2  33.4   2.4

Що це означає: 2% втрат до хоста філії достатньо, щоб SMB відчувався «примарно», особливо для навантажень з великою кількістю метаданих.

Рішення: Розглядайте стійкі втрати/джиттер як мережевий інцидент у першу чергу. Налаштування SMB не виправить фізику.

Task 7: Verify firewall isn’t killing idle flows (Linux conntrack)

cr0x@server:~$ sudo conntrack -L | grep -E "dport=445|sport=445" | head
tcp      6 431992 ESTABLISHED src=10.20.5.25 dst=10.10.1.50 sport=50322 dport=445 src=10.10.1.50 dst=10.20.5.25 sport=445 dport=50322 [ASSURED] mark=0 use=1

Що це означає: Запис стану існує і показує довгий таймаут (тут ~5 днів). Якщо ваш таймаут малий (хвилини), ви будете бачити відключення після періодів бездіяльності.

Рішення: Збільште TCP established timeouts на фаєрволі/пристрої VPN або забезпечте наявність keepalives для довгоживучих SMB‑сесій.

Task 8: On Windows client, confirm SMB dialect and encryption/signing

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | ft ServerName,ShareName,Dialect,Encrypted,SigningRequired"
ServerName ShareName Dialect Encrypted SigningRequired
---------- --------- ------ --------- ---------------
FS-HQ      Projects  3.1.1  False     True

Що це означає: Dialect 3.1.1 — сучасний. Підписування вимагається; шифрування для цього шару вимкнено.

Рішення: Якщо бачите Dialect 1.0 або 2.0 несподівано — виправте стару переговорну логіку. Якщо шифрування увімкнено і продуктивність погана — виміряйте завантаження CPU і розгляньте селективне шифрування.

Task 9: Check SMB client configuration (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbClientConfiguration | Select EnableSecuritySignature,RequireSecuritySignature,EnableMultiChannel,ConnectionCountPerRssNetworkInterface"
EnableSecuritySignature RequireSecuritySignature EnableMultiChannel ConnectionCountPerRssNetworkInterface
---------------------- ------------------------ ---------------- -------------------------------
True                   False                    True             4

Що це означає: Клієнт використовує підписування, якщо сервер вимагає; multichannel увімкнено.

Рішення: Якщо multichannel викликає дивності через VPN (кілька шляхів, NAT), розгляньте тимчасове відключення multichannel на клієнтах або серверах для тесту і приймайте рішення за даними.

Task 10: Check SMB server sessions and disconnect reasons (Windows Server)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbSession | Sort-Object -Descending NumOpens | Select -First 5 | ft ClientComputerName,NumOpens,SessionId,ClientUserName"
ClientComputerName NumOpens SessionId ClientUserName
------------------ -------- --------- --------------
BR-WS-014                27 1125899906842631 CONTOSO\alex
BR-WS-021                19 1125899906842630 CONTOSO\maria
BR-WS-008                12 1125899906842628 CONTOSO\sam

Що це означає: Активні сесії існують; ви можете зіставити скарги на відключення з конкретними клієнтами та кількістю відкриттів.

Рішення: Якщо постраждала лише підмножина клієнтів — зосередьтесь на їх шляху (Wi‑Fi, VLAN, безпека кінцевих точок), а не на сервері.

Task 11: Look for SMB server-side errors (Windows event log query)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName Microsoft-Windows-SMBServer/Operational -MaxEvents 8 | ft TimeCreated,Id,LevelDisplayName,Message -AutoSize"
TimeCreated            Id LevelDisplayName Message
-----------            -- ---------------- -------
12/27/2025 9:17:10 AM 310 Error            The server failed to allocate from the system nonpaged pool because the pool was empty.
12/27/2025 9:16:58 AM 1006 Warning         A connection was disconnected due to inactivity.

Що це означає: «Disconnected due to inactivity» вказує на невідповідність таймаутів. Проблеми з nonpaged pool — натяк на тиск пам’яті/помилки драйверів (менш поширено, але трапляється).

Рішення: Для відключень через бездіяльність — змініть таймаути фаєрвола/VPN і SMB keepalives. Для проблем з пам’яттю — розглядайте як інцидент здоров’я сервера.

Task 12: Test raw throughput vs small I/O behavior (Linux, smbclient)

cr0x@server:~$ smbclient //FS-HQ/Projects -U 'CONTOSO\alex' -c 'lcd /tmp; get bigfile.bin'
getting file \bigfile.bin of size 2147483648 as bigfile.bin (38.2 MBytes/sec) (average 38.2 MBytes/sec)

Що це означає: Великий послідовний трансфер — пристойний. Якщо користувачі все одно скаржаться, що «відкривання папок» повільне, вузьке місце, ймовірно, у метаданих, а не в пропускній здатності.

Рішення: Зосередьтеся на затримці, перелічуванні каталогів, скануванні AV і SMB‑раундтрипах — не «збільшуйте канал».

Task 13: Measure SMB “create/open” latency using a simple loop (Windows client)

cr0x@server:~$ powershell -NoProfile -Command "$p='\\FS-HQ\Projects\latencytest'; 1..20 | % { $t=Measure-Command { Get-ChildItem $p | Out-Null }; '{0} ms' -f [int]$t.TotalMilliseconds }"
182 ms
190 ms
176 ms
415 ms
181 ms
179 ms

Що це означає: Більшість запусків ≈180–190 мс, але сплески до 400 мс трапляються. Користувачі відчувають саме ці сплески, не середнє значення.

Рішення: Розслідуйте втрати/джиттер, насичення CPU тунелю та черги. Розгляньте QoS і підбір апаратного забезпечення тунелю.

Task 14: Confirm DNS resolves the file server consistently (Windows client)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName FS-HQ | ft Name,Type,IPAddress"
Name  Type IPAddress
----  ---- ---------
FS-HQ A    10.10.1.50

Що це означає: Клієнт резолвить на внутрішню IP. Якщо резолвиться на публічну IP або інший сайт, шлях SMB може робити hairpin або пройти через неправильну політику фаєрвола.

Рішення: Виправте split‑horizon DNS і визначення сайтів/підмереж в AD, щоб клієнти філій використовували правильний маршрут.

Task 15: Check time sync (Kerberos sanity) (Windows)

cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 3 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 12/27/2025 9:14:21 AM
Source: DC-HQ.contoso.local
Poll Interval: 10 (1024s)

Що це означає: Клієнт нещодавно синхронізувався з доменним джерелом. Якщо час відстає на хвилини, Kerberos і встановлення SMB‑сесій можуть падати або відбуватися з незручними відкатами.

Рішення: Виправте NTP/ієрархію AD перед тим, як звинувачувати SMB.

Task 16: See if the file server is storage-bound (Linux NAS example)

cr0x@server:~$ iostat -xz 1 5
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.44    0.00    4.11   18.32    0.00   65.13

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await
nvme0n1         55.0   120.0  7200.0  15600.0    0.0     0.0   92.1   18.4

Що це означає: Високий %util і await вказують, що диск зайнятий і запити очікують ~18 мс в середньому. Це збільшить затримку SMB, особливо для навантажень з великою кількістю метаданих.

Рішення: Якщо затримка сховища висока під час скарг — виправляйте сховище (кеш, швидші диски, розділення робочих навантажень, налаштування ZFS/RAID, зменшення синхронного запису) перед тим, як чіпати VPN.

Налаштування SMB, що має значення (і що краще не чіпати)

Вбити SMB1. Не домовляйтеся з ним.

Якщо SMB1 увімкнено десь «для сумісності», воно з’явиться у найневдалий момент: старий сканер, загадковий вбудований пристрій або робоча станція з древньою політикою. SMB1 має відомі проблеми з безпекою і погану продуктивність. І, що важливіше для ваших користувачів: він погано поводиться при затримках.

Правило прийняття рішення: якщо пристрій розмовляє лише SMB1 — ізолюйте або замініть його. Не дозволяйте йому тягнути все середовище в 1996 рік.

Підписування SMB: вимагайте там, де треба, вимірюйте там, де потрібно

Підписування забезпечує цілісність (запобігає фальсифікації). У сучасних доменах воно часто вимагається політикою. Через VPN воно з точки зору конфіденційності часто дублюється (тунель вже шифрує), але воно все ще важливе для цілісності, якщо ви не довіряєте шляху або тунель завершується в дивних місцях.

Операційна реальність: підписування навантажує CPU і може знижувати пропускну здатність. На сучасних CPU це зазвичай непомітно. На маленькому NAS або недоформованій віртуалці це податковий удар по продуктивності, який ви відчуєте.

Що робити: залишайте підписування вимогливим у доменних середовищах, якщо немає сильної причини інакше. Якщо продуктивність падає — виправляйте CPU і offload, а не відключайте підписування як перший крок.

Шифрування SMB: використовуйте вибірково

Шифрування SMB корисне коли:

У вас недовірені сегменти між клієнтом і сервером (не лише «VPN», а кілька маршрутизованих мереж).
Потрібна захист на рівні шару для певного шару (per‑share).
Ви не можете гарантувати покриття VPN для кожного шляху клієнта.

Шифрування SMB не дуже добре, коли CPU сервера вже завантажений і VPN вже шифрує все. Подвійне шифрування може бути прийнятним; а може й вбити систему контекст‑перемикань.

Durable handles і continuous availability: не плутайте фічі

Durable handles дозволяють клієнту перепідключитися після короткого переривання без пошкодження стану відкритого файлу. Це корисно через VPN, бо мікроперерви трапляються: ренкі, роумінг Wi‑Fi, джиттер провайдера.

Continuous availability — інша річ: прив’язана до кластерних файлових серверів і спеціальних налаштувань шару. Якщо у вас немає такої інфраструктури, не чекайте чудес. Ви можете отримати стабільність, але не «семантику кластерного NAS» без додаткової інвестиції.

OpLocks/leases: прискорювач з гострим лезом

У більшості офісних робочих потоків leases зменшують раунтрипи і прискорюють роботу. На шарах, що використовуються бізнес‑додатками, CAD або будь‑якими системами з дивною поведінкою блокувань, вони можуть проявлятися як конфлікти «файл використовується» або затримка видимості змін.

Не відключайте їх глобально через одну проблемну програму. Ізолюйте таке навантаження в окремий шар/сервер і налаштовуйте конкретно там.

Налагодження VPN і мережі для SMB

MTU: тихий вбивця «великі файли зависають»

Інкапсуляція VPN зменшує ефективний MTU. Якщо повсюди залишити 1500‑байтовий Ethernet MTU, але додати накладні витрати IPsec ESP або OpenVPN, ви можете перевищити справжній path MTU. Якщо PMTUD заблоковано (поширено через агресивні фаєрволи), пакети відкидаються замість фрагментації, і TCP зупиняється. Тоді SMB виглядає як «випадкові відключення», часто під час великих записів.

Робіть це: визначте ефективний MTU для тунелю, встановіть його явно на інтерфейсі VPN і обмежте MSS для TCP SYN‑пакетів через тунель. Так, навіть у 2025 році. PMTUD досі може бути пригодою з вибором шляху.

Таймаути стану фаєрвола: налаштуйте під людську поведінку, а не лабораторну

Люди відкривають файл, думають про нього, йдуть на обід і залишають файл відкритим. SMB тримає стан і може відправляти keepalive, але ваш фаєрвол може цього не помічати або мати окрему логіку таймауту VPN.

Якщо користувачі відключаються через точно 30 або 60 хвилин — це не примха SMB. Це таймер. Знайдіть його і виправте.

QoS: пріоритезуйте те, що найбільше болить

SMB — це не лише масивні дані. Це також багато дрібних «контрольних» операцій. Якщо канал завантажений бекапами, відеодзвінками або кимось, хто синхронізує образ VM, виклики метаданих SMB опиняються в черзі за масовим трафіком, і кожне відкриття папки відчувається як смола.

Пріоритезуйте TCP/445 і, при потребі, класи трафіку інкапсульованого VPN. Але робіть це обережно: «пріоритет» не означає «задушити все інше». Це означає «зменшити хвостову затримку для інтерактивних операцій».

Split tunneling: рішення — на основі ризику і пропускної здатності, а не інтуїції

Для site‑to‑site офісних VPN зазвичай хочеться повної маршрутизації між сайтами, але не обовʼязково «весь інтернет через HQ». Хаірпінінг інтернет‑трафіку через HQ збільшує затримку і навантаження, і може конкурувати з SMB. З іншого боку, якщо ваша безпекова позиція вимагає централізованого egress — прийміть це і пропишіть пропускні характеристики відповідно.

Жарт №2: Якщо ваш VPN‑бокс — ще й ваш DNS, DHCP, IDS і кавомашина, не дивуйтеся, що файловий обмін пахне пригорілим.

Реалії бекенду сховища (NAS, Windows, ZFS, VM)

Проблеми з надійністю SMB часто неправильно діагностують як «мережеві», бо симптом — відключення. Але зависання сховища та перевантаження сервера проявляються так само: сервер перестає швидко відповідати, клієнт повторює запити, сесія розривається чимось нетерплячим посеред шляху.

Затримка диска перемагає пропускну здатність в офісному файловому шарі

Офісні шари — це здебільшого дрібні випадкові I/O: метадані, дрібні записи, багато перейменувань і тимчасових файлів. Сервер, що видає 1 Gbps послідовно, але має посередні випадкові IOPS, все одно буде відчуватися повільним. Користувачі не тестують 2 GB копію файлу; вони відкривають папку з 20 000 дрібних файлів і очікують ескізів.

Віртуалізація: шумні сусіди — реальність

Якщо ваш файловий сервер — VM на насиченому гіпервізорі, «випадкові відключення» можуть бути через CPU ready time, затримки сховища від спільного datastore або проблему черги vNIC. Налаштування VPN цього не вирішить.

ZFS і SMB: чудова пара, але розумійте синхронні записи

На NAS з ZFS (або будь‑якому сховищі з фокусом на цілісність) синхронні записи можуть бути дорогими. SMB‑навантаження з певними прапорами і поведінкою додатків можуть примушувати синхронні семантики. Якщо SLOG (окремий лог‑пристрій) відсутній або повільний, операції «збереження» можуть затримуватися. Мережа при цьому може бути в порядку, але додаток таймаутить.

Операційно: вимірюйте await, завантаження CPU, ARC hit rates якщо доречно, і тримайте SMB‑сервіс на стабільному низьколатентному шляху сховища. Помістіть бекапи в інше місце.

Антивірус і індексація контенту: прихований податок

Сканування в реальному часі на сервері при кожному відкритті/читанні може зруйнувати продуктивність. Так само Windows Search на шарі. Через VPN користувачі натискають «відкрити» і чекають, поки сервер просканує, проіндексує і нарешті відповість.

Будьте дисциплінованими: виключайте типи файлів і шляхи там, де доречно, особливо великі бінарні формати, що часто змінюються. Тестуйте разом із командами безпеки, не робіть самовільних рішень. Але не погоджуйтеся на «сканувати все завжди», якщо це ламає бізнес.

Три міні‑історії з корпоративного життя

Міні‑історія 1: Інцидент через неправильне припущення

Налаштування виглядало чистим. У HQ був файловий сервер. Дві філії підключалися через IPsec‑тунель. Всі підключали диски по імені сервера. Мережна команда клялася, що VPN стабільний, бо тунель «up» і ping‑и працюють.

Скарги не відповідали цій картинці. Користувачі у Філії A відключалися по 3–5 разів на день, зазвичай у полуденний час. Філія B була в порядку. Helpdesk підняв це як «SMB непрацює через VPN», і перша інстинктивна дія — тюнінг таймаутів SMB на клієнтах.

Неправильне припущення було в тому, що «тунель up» означає «тунель здоровий». Насправді фаєрвол у HQ робив policy‑based маршрутизацію для деяких підмереж і route‑based для інших. Повернення трафіку Філії A іноді ішло іншим WAN‑шляхом під час балансування навантаження ISP. Асиметрична маршрутизація означала падіння стану в стейтфул фаєрволі. TCP/445 потоки тихо вмирали. SMB повторювався, потім здавався, і додаток панікував.

Виправлення не було в SMB‑тюнінгу. Виправили симетричність маршрутизації і зробили так, щоб таблиця стану фаєрвола бачила обидва напрямки одним шляхом. Після цього відключення майже зникли. Єдині решта проблем були повʼязані з продуктивністю, і це те, що можна запланувати.

Міні‑історія 2: Оптимізація, що спрацювала проти

Інша компанія мала реальну проблему з пропускною здатністю. Вони весь день передавали великі дизайн‑файли з філії в HQ, і канал був насичений. Хтось вирішив увімкнути шифрування SMB (бо «безпека цього хоче»), і одночасно вмикнути стиснення на шарі VPN, щоб «отримати більше пропускної здатності».

В короткому тесті все виглядало добре. Потім послідував продакшн. CPU на VPN‑приладі сів під навантаженням. Операції SMB почали таймаутити. Користувачі відмічали, що збереження іноді завершується, іноді зависає, іноді дає «network name no longer available». Класична інтермітентна відмова, що псує вихідні дні.

Зворотній ефект був передбачуваний у ретроспективі: зашифровані дані погано стискаються, тож VPN‑стискання додало накладних витрат без вигоди. Шифрування SMB додало ще навантаження на CPU кінцевих точок. Комбінований ефект підвищив затримку і джиттер — саме те, що SMB ненавидить. Пропускна здатність не покращилася; хвостова затримка погіршилася. Інтерактивні операції постраждали навіть коли канал не був повністю зайнятий, бо CPU став вузьким місцем.

Кінцеве прагматичне рішення було нудним: вимкнули компресію VPN, зберегли підписування SMB, увімкнули шифрування SMB лише для чутливих шарів і обновили VPN‑залізо, щоб крипто не конкурувало з маршрутизацією. Потім додали QoS, щоб масові передачі не забивали інтерактивний SMB‑трафік.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Ця історія менш драматична — в цьому й суть. Середня фірма мала чотири офіси і центральний файловий кластер. У них було правило: щокварталу вони проводили «WAN file share drill». Не лише столовий план — реальний тест‑вікно, під час якого вимірювали затримку, втрати пакетів, статистику SMB‑зʼєднань і затримку сховища під контрольованим навантаженням.

У них також був нудний стандарт: на всіх VPN‑краях однакові налаштування MTU, правила MSS‑clamp і задокументовані політики таймаутів. Кожного разу, коли хтось міняв фаєрвол, вони застосовували ту саму базову конфігурацію перед cutover. Ні «потім налаштуємо». «Потім» — це коли починають кричати користувачі.

Одного дня провайдер змінив щось вище по ланцюжку і PMTUD перестав працювати на одній лінії. Протягом годин моніторинг зафіксував зріст TCP‑повторів і затримок відкриття SMB. Helpdesk майже не отримав звернень, бо команда проактивно зменшила MTU на тому тунелі і відрегулювала MSS‑clamping до того, як користувачі серйозно помітили проблему.

Практика не була ефектною. Вона була повторюваною і передбачуваною. І саме тому врятувала день.

Поширені помилки: симптом → причина → виправлення

Це шаблони, що зʼявляються знов і знов. Трюк — перестати ставити їх у розряд таємниць.

1) Симптом: «Працює з малими файлами, зависає на великих копіях»

Причина: MTU/PMTUD чорна діра через VPN; фрагментація заблокована; MSS занадто велике.

Виправлення: Визначте ефективний MTU за допомогою DF‑ping; встановіть MTU інтерфейсу VPN; обмежте TCP MSS на краях тунелю; переконайтеся, що ICMP «frag needed» не блокується.

2) Симптом: Відключення через точно 30/60 хвилин бездіяльності

Причина: Таймаут idle фаєрвола/VPN коротший за очікування SMB‑сесії; закінчення часу дії в таблиці NAT.

Виправлення: Збільшіть TCP established timeouts; налаштуйте keepalives/DPD у VPN; перевірте проміжні пристрої (включно з CPE провайдера), чи не вбивають вони потоки.

3) Симптом: Повільне «відкриття файлу», але швидке копіювання великого файлу

Причина: Затримка і балакучість метаданих; сканування AV; перелік каталогів; висока затримка сховища для дрібних I/O.

Виправлення: Виміряйте latency відкриття і await сховища; налаштуйте виключення AV; зменшіть розмір папок; розгляньте локальне кешування/DFS‑реплікацію для цього шару.

4) Симптом: Проблема лише в одному офісі, інші в порядку

Причина: Асиметрична маршрутизація; локальна втрата ISP; проблеми Wi‑Fi/VLAN; DNS резолвить на неправильний сервер.

Виправлення: Підтвердіть симетрію маршруту за допомогою ip route get; запустіть mtr з обох сторін; перевірте DNS і відображення сайтів AD.

5) Симптом: «Network name no longer available» під час збережень

Причина: Флап/ренкі тунелю, що викликає TCP reset; фаєрвол викидає стан; сервер ставить паузу (storage stall) настільки довго, що клієнт перериває.

Виправлення: Перевірте логи VPN на предмет ренеготіацій; перевірте conntrack/таймаути стану; моніторьте затримку диска й CPU ready time сервера.

6) Симптом: Запити автентифікації або «access denied» періодично

Причина: Kerberos падає через розбіжності часу/DNS; відкат на NTLM; переривчаста доступність DC через VPN.

Виправлення: Виправте синхронізацію часу; забезпечте доступ клієнтів до локального DC або доступного DC; перевірте SPN; прибирайте проблеми split DNS.

7) Симптом: Пропускна здатність низька лише при увімкненому шифруванні/підписуванні

Причина: Обмеження CPU на сервері/NAS/VPN; відсутність апаратного прискорення крипто; подвійне шифрування.

Виправлення: Виміряйте CPU під навантаженням; масштабируйте; увімкніть апаратне прискорення, де є; використовуйте шифрування вибірково по шарах.

8) Симптом: «Файл заблоковано» випадково між офісами

Причина: Додаток не працює коректно з leases/oplocks; невідповідність очікувань кешування; поведінка eventual consistency (DFS‑R) при конфліктах.

Виправлення: Для цього навантаження: окремий шар, обережна настройка oplock/lease або переробка робочого процесу (не редагувати один і той самий файл з двох сайтів через реплікацію).

Контрольні списки / покроковий план

Покроковий план: стабілізувати SMB між офісами за 10 кроків

Інвентаризуйте шлях. Намалюйте реальний шлях пакета: клієнт → комутатор/Wi‑Fi → роутер філії → ISP → край HQ → фаєрвол → VLAN сервера → сервер. Включіть NAT‑пристрої.
Виміряйте базову затримку, джиттер і втрати. Використайте mtr і прості цикли відкриття файлу в години піку.
Зафіксуйте MTU/MSS. Виберіть MTU, що переживає інкапсуляцію. Встановіть його. Обмежте MSS. Перевірте DF‑pingами.
Підтвердіть симетрію маршрутизації. Переконайтеся, що шляхи відповіді використовують той самий тунель, а не «якийсь дефолтний маршрут сьогодні».
Виправте DNS і відображення сайтів AD. Переконайтеся, що клієнти філій резолвлять файлові сервери правильно і мають доступні контролери домену.
Узгодьте таймаути. Таймаути TCP established фаєрвола, idle‑таймери VPN і DPD/keepalive повинні підтримувати багатогодинні відкриті сесії.
Інструментуйте сервер. Слідкуйте за disk await, CPU, подіями SMB‑сервера і помилками NIC. Доведіть, що сервер не є вузьким місцем.
Контролюйте фоновий трафік. Застосуйте QoS або розклад для бекапів/синхронізацій, щоб інтерактивний SMB не стояв в черзі за масовими потоками.
Припиніть WAN‑ворожі навантаження. Не запускайте Outlook PST через SMB по VPN. Не редагуйте великі CAD‑зборки прямо з віддаленого шару, якщо не любите страждати.
Виберіть довгострокову архітектуру. Якщо затримки/втрати неминучі — розгорніть локальне кешування/репліку або перенесіть співпрацю з SMB на іншу платформу.

Контрольний список: як виглядає «добре»

MTU відомий і верифікований end‑to‑end; немає PMTU‑чорних дір.
Тунель не флапає і не перевстановлює ключі так, що це рве активні TCP‑потоки.
Втрати близькі до нуля на краях філій; джиттер помірний.
Таймаути стану фаєрвола підтримують довгоживучі сесії (години).
DNS детермінований для імен файлового сервера; немає несподіваних публічних резолвів.
Затримка сховища залишається низькою під піковим навантаженням; сканування AV контрольоване.
Діалект SMB сучасний (3.x) і SMB1 вимкнено.

Питання й відповіді (FAQ)

1) Чим краще використовувати для SMB: IPsec чи WireGuard/OpenVPN?

Використовуйте те, що ваша команда може експлуатувати надійно. Для SMB важлива стабільність і передбачувана поведінка MTU більше, ніж бренд. Route‑based VPN зазвичай простіше для розуміння, ніж policy‑based тунелі, особливо при масштабуванні на кілька підмереж.

2) Чи підтримується SMB через VPN для продуктивної роботи офісу?

Так, але з обмеженнями. Якщо у вас послідовно низька затримка і мінімальні втрати — все буде ок. Якщо WAN ненадійний або з високою затримкою, ви будете інженерити навколо фізики — використовуйте кеш/реплікацію або змініть робочий процес.

3) Чому мережеві диски відключаються, коли ніхто нічого не копіює?

Бо «idle» у людському розумінні — це все ще «відкрита сесія» для протоколу. Фаєрволи, NAT і пристрої VPN часом вбивають потоки. Узгодьте таймаути і ввімкніть keepalives, щоб мережа пам’ятала про сесію.

4) Чи вирішить проблему збільшення таймаутів SMB на клієнтах?

Іноді маскує симптоми, але рідко вирішує корінь. Якщо проміжний пристрій вбиває TCP‑стан, клієнт може довше чекати і все одно втратити зʼєднання. Спочатку виправте MTU, втрати, симетрію маршруту та таймаути фаєрвола.

5) Чи варто вмикати шифрування SMB, якщо у нас уже є VPN?

Тільки якщо вам потрібен defense‑in‑depth на рівні застосунку або у вас складна маршрутизація, де трафік може обійти VPN. Інакше тримайте підписування й покладайтеся на шифрування тунелю. Якщо вмикаєте шифрування SMB, виміряйте CPU до і після.

6) Чому перегляд папок повільний, а копіювання файлів швидке?

Перегляд папок запускає багато дрібних операцій метаданих. Через WAN вони обмежені затримкою. Копіювання файлів може бути пропускною та пайплайновою операцією. Виправте затримку/джиттер, зменшіть розмір папок, контролюйте AV або використайте локальні репліки.

7) Чи вирішить DFS наші SMB‑проблеми між офісами?

DFS Namespaces може вирішити проблему іменування і referral‑ів і полегшити міграції. DFS Replication може зменшити крос‑сайтний трафік для підходящих даних. Але воно не зробить «усіх, хто редагує той самий файл з двох сайтів», безпечними.

8) Яка найпоширеніша причина «випадкових зависань SMB» через VPN?

Класично — проблеми MTU/PMTUD, особливо коли хтось увімкнув jumbo‑фрейми локально і забув про накладні витрати VPN. Друга за поширеністю — таймаути фаєрвола/стану, що не відповідають довгоживучим SMB‑сесіям.

9) Чи варто вимикати SMB multichannel для VPN‑лінків?

Тестуйте. Multichannel може допомогти в правильно спроєктованих мережах і нашкодити, коли є NAT, кілька шляхів або асиметрична маршрутизація. Не застосовуйте сліпо: виміряйте поведінку зʼєднання і вирішіть за стабільністю.

10) Чи нормально запускати бази даних або PST файли через SMB між офісами?

«Нормально» — сильне слово. Багато додатків поводяться погано через WAN SMB, бо вони очікують LAN‑латентності і стабільних блокувань. Якщо дуже треба — переробіть: локальний app‑сервер, віддалений робочий стіл у HQ або підтримуваний підхід реплікації.

Висновок: практичні наступні кроки

Якщо ви хочете SMB між офісами без постійних відключень — перестаньте ставитися до нього як до фічі «копіювання файлів» і почніть ставитися як до розподіленого сервісу зі строгими залежностями.

Зробіть наступне:

Запустіть план швидкої діагностики у години піку і зберіть докази: втрати/джиттер, MTU, маршрутизацію, таймаути, затримку сховища.
Спочатку виправте MTU/MSS і таймаути стану. Це дві основні причини «випадкових відключень».
Інструментуйте файловий сервер і сховище, щоб за кілька хвилин відрізнити «мережа повільна» від «диск повільний».
Виберіть архітектуру усвідомлено: центральний сервер, якщо затримка низька й стабільна; DFS/кеш/локальні сервери, якщо ні; або перенесіть співпрацю з SMB, якщо користувачі потребують крос‑сайтового редагування щодня.

Кінцева мета — нудна надійність: шар залишається підключеним, відкриття файлів прогнозоване, і ніхто не дізнається, що таке «SMB session teardown». Тримайте його таким.