SMB-ресурси через VPN без розривів: як реально виправити «Шлях мережі не знайдено»

Як SMB фактично відмовляє через VPN (режими відмов, що мають значення)

SMB — це не протокол «надійся, що пакети дійдуть». Він підтримує сесії, стан автентифікації, кредити (контроль потоку),
іноді durable handles і leases. Це чудово в локальній мережі, де RTT низький, втрата пакетів рідкісна, а шляхи не змінюються.
Через VPN у вас більший RTT, більше джиттера і кілька місць, де шлях може тимчасово зникнути, ніби ніхто цього не помітив.

Режим відмови 1: MTU‑чорні діри та фрагментація, що «переважно працює»

VPN змінює обмеження на розмір пакета. Якщо PMTUD заблоковано або ICMP фільтрується, шлях може безшумно скидати великі пакети.
SMB працюватиме для списків директорій і дрібних читань, а потім впаде під час великих записів, операцій підписання або операцій з великою кількістю метаданих.
«Шлях мережі не знайдено» часто — це Windows, що перекладає «TCP‑сесія померла і повторне з’єднання не вдалося».

Режим відмови 2: Таймаути NAT і фаєрволів вбивають довгоживучі TCP

SMB працює поверх TCP. Ваш VPN, ймовірно, використовує UDP (WireGuard, багато конфігурацій OpenVPN) або UDP‑инкапсульований ESP (IPsec NAT‑T).
Посередині: NAT‑пристрої, stateful фаєрволи, carrier‑grade NAT, готельне Wi‑Fi‑обладнання, створене з люті.
Якщо таймаут бездіяльності спливає, відношення зникає. Наступний SMB‑пакет потрапляє в чорну діру, клієнт пробує знову, потім скидає, потім перепідключається.

Режим відмови 3: Флапи маршрутів і неоднозначність split‑tunnel

Якщо ви використовуєте split‑tunnel, ви покладаєтесь на те, що маршрут до файлового сервера завжди йде в тунель.
Це велика вправа з довіри, коли змінюється DNS, у файлового сервера кілька IP, коли DFS‑направлення вказують кудись інакше,
або коли клієнт перемикається між Wi‑Fi і Ethernet.

Режим відмови 4: Функції безпеки SMB підвищують чутливість до затримок

SMB‑підпис та SMB‑шифрування — хороші речі. Вони також додають накладні витрати і можуть підсилювати ефекти затримки — особливо при дрібних I/O‑операціях.
Додайте антивірусний сканер, opportunistic locking/leases та балакуче навантаження (файли Office — це суцільний набір дрібних операцій), і
раптом у вас протокол‑вежа, де будь‑яка хиткість спричиняє розрив.

Режим відмови 5: Збої в іменуванні, а не на сервері

«Шлях мережі не знайдено» часто — проблема імені. Сервер працює, доступний за IP і охоче відповідає.
Але клієнт розв’язує fileserver у публічну адресу, або в стару адресу, або іноді в IPv6, іноді в IPv4.
Перепідключення SMB використовує імена, SPN і іноді простори імен DFS. Нестабільний резолвер може виглядати як нестабільна мережа.

Режим відмови 6: Тиск ресурсів на стороні сервера спричиняє скидання сесій

Не ігноруйте сервер. Якщо ваш хост Samba завантажений CPU через шифрування/підписи, або Windows‑файловий сервер мучиться через затримки зберігання,
клієнт бачить таймаути й скидання. VPN звинувачують тому, що він помітний. Сторедж звинувачують тому, що це традиція.
Зазвичай це мікс.

Правило інженерії надійності: ви не зможете налаштувати те, що не вимірюєте. Ось момент, коли перестаємо гадати і починаємо збирати докази.

Факти й історія: чому ця проблема повторюється

• SMB походить із багажу епохи CIFS. Ранні діалекти SMB були дуже «балакучі» на лінках з великою затримкою; багато міфів про «SMB повільний через WAN» беруть звідти початок.
• SMB 2.0 (Windows Vista/Server 2008) — серйозний перепис. Він зменшив кількість команд і покращив пайплайнинг, що зробило поведінку в WAN менш катастрофічною.
• SMB 3.x додав шифрування, multichannel і durable handles. Чудово для датацентрів; через VPN multichannel може здивувати, якщо існують кілька інтерфейсів.
• DFS‑простори імен можуть перенаправляти клієнтів «на льоту». Користувач підключається до \\corp\share, але перенаправлення може відправити його на інший таргет з іншою досяжністю через VPN.
• PMTUD‑відмови старіші за вашу систему тикетів. «Працює для маленьких пакетів, падає для великих» — класичний випадок, коли ICMP фільтрується або спотворюється.
• Таймаути NAT — це політичний вибір, не фізика. Деякі пристрої тримають UDP‑відображення кілька секунд, інші — хвилини; мобільні клієнти регулярно потрапляють у найгірший випадок.
• Таймаути SMB можуть бути довшими, ніж терпіння VPN. Рівень додатку може чекати, поки мережевий рівень вже втратив стан, що робить помилки випадковими на вигляд.
• Windows наполегливо намагається перепідключити мережеві диски. Це корисно, доки ні: ви отримуєте періодичні «шлях не знайдено», зависання Провідника і фантомні запити паролів.
• За замовчуванням безпека з часом посилилася. Вимкнення підпису/шифрування, щоб «покращити продуктивність», іноді працює — поки це не стане наступним зауваженням аудиту.

Одну ідею, часто приписувану James Hamilton (Amazon), можна перефразувати: Спочатку виміряйте; інакше ви просто сперечаєтесь думками. Такий підхід рятує дні.

Швидкий план діагностики (перші/другі/треті)

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

Спочатку: доведіть, чи це ім’я, маршрут чи транспорт

1. Ім’я: чи резольвиться хостнейм шару в очікувані IP(и) під VPN?
2. Маршрут: чи йде маршрут до того IP фактично в тунель (і є стабільним)?
3. Транспорт: чи можна утримати чисту TCP‑сесію до порту 445 без повторних передач і скидань?

Другий крок: полювання на MTU/MSS і чорні діри

1. Перевіряйте path MTU для великих payload‑ів з встановленим DF.
2. Шукайте фрагментацію, ретрансляції і шаблони «TCP previous segment not captured» у захопленнях.
3. Якщо бачите «працює для дрібного, падає на великій копії», вважайте MTU підозрюваним доти, доки не доведено інше.

Третій крок: перевірте таймаути NAT/фаєрволів і VPN keepalives

1. Падає після N хвилин бездіяльності? Це не збіг; це таймер.
2. Падає, коли користувачі перемикаються мережі або прокидаються зі сну? Це втрата стану.
3. Виправте keepalives і адекватні таймаути, перш ніж ламати реєстр SMB.

Четвертий: перевірка здоров’я сервера (CPU, затримка диска, служба SMB)

1. На Samba: насичення CPU, накладні витрати шифрування і затримки диска проявляються як клієнтські таймаути.
2. На Windows‑серверах: журнали подій, статистика SMB‑сервера і затримки зберігання важливіші за інтуїцію.

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

Практичні завдання з командами: доведіть корінь проблеми

Це реальні команди, які можна виконати. Кожна команда містить, що означає вивід і яке рішення приймати далі.
Використовуйте їх як чекліст, а не як шведський стіл.

Завдання 1: Підтвердити DNS‑резолюцію файлового сервера (Linux‑клієнт)

cr0x@server:~$ getent ahosts fileserver.corp.local
10.60.12.25      STREAM fileserver.corp.local
10.60.12.25      DGRAM  fileserver.corp.local
10.60.12.25      RAW    fileserver.corp.local

Значення: Ви отримали один A‑запис (IPv4) і він у діапазоні VPN. Добре.
Якщо бачите публічну IP або несподівану підмережу — знайшли помилку split‑DNS.
Рішення: Виправте DNS (резолвери, що надає VPN, NRPT на Windows, split‑horizon DNS). Не чіпайте SMB до вирішення DNS.

Завдання 2: Підтвердити DNS у Windows (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName fileserver.corp.local | Select-Object -First 5"
Name                           Type TTL  Section IPAddress
----                           ---- ---  ------- ---------
fileserver.corp.local          A    60   Answer  10.60.12.25

Значення: Windows резольвить очікувано.
Якщо відповідь під час сесії змінюється між IP (особливо IPv6 vs IPv4), перепідключення SMB можуть йти не за планом.
Рішення: Стабілізуйте відповіді DNS для VPN‑клієнтів або зафіксуйте імену, що використовується лише для файлових сервісів.

Завдання 3: Перевірити, чи маршрут йде в VPN‑інтерфейс (Linux)

cr0x@server:~$ ip route get 10.60.12.25
10.60.12.25 dev wg0 src 10.60.0.14 uid 1000
    cache

Значення: Трафік використовує wg0. Якщо виходить через wlan0 або eth0, правила split‑tunnel неправильні.
Рішення: Виправте маршрути/політи routing, або підправте AllowedIPs (WireGuard) / pushed routes (OpenVPN).

Завдання 4: Перевірити маршрут у Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix 10.60.12.0/24 | Sort-Object RouteMetric | Select-Object -First 3"
ifIndex DestinationPrefix NextHop     RouteMetric PolicyStore
------- ----------------- -------     ----------- -----------
31      10.60.12.0/24     0.0.0.0     5           ActiveStore

Значення: Маршрут існує і має пріоритет (низький metric). Якщо маршрут VPN має більший metric за маршрут за замовчуванням,
ви отримаєте «іноді працює» залежно від стану інтерфейсу.
Рішення: Виправте метрики інтерфейсів або встановіть явні маршрути для SMB‑таргетів.

Завдання 5: Перевірити TCP‑доступність порту 445 (Linux)

cr0x@server:~$ nc -vz -w 3 10.60.12.25 445
Connection to 10.60.12.25 445 port [tcp/microsoft-ds] succeeded!

Значення: Порт 445 доступний по TCP. Якщо таймаут — маєте проблему з фаєрволом/маршрутом/VPN.
Якщо з’єднується, але SMB усе ще падає — проблема на вищому рівні (автентифікація, діалект, підпис, таймаути).
Рішення: Якщо заблоковано, зупиніться і виправте контролі доступу та маршрути. Не налаштовуйте SMB, щоб компенсувати заблокований порт.

Завдання 6: Перевірка з Windows за допомогою Test-NetConnection

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.60.12.25 -Port 445"
ComputerName     : 10.60.12.25
RemoteAddress    : 10.60.12.25
RemotePort       : 445
InterfaceAlias   : CorpVPN
TcpTestSucceeded : True

Значення: Windows погоджується: TCP відкритий на VPN‑інтерфейсі.
Рішення: Перейдіть до діагностики MTU і SMB‑сесій, якщо користувачі досі бачать розриви.

Завдання 7: Перелічити діалект SMB і можливості (Linux smbclient)

cr0x@server:~$ smbclient -L //10.60.12.25 -U 'CORP\alice' -m SMB3
Password for [CORP\alice]:
        Sharename       Type      Comment
        ---------       ----      -------
        projects        Disk      Projects share
        IPC$            IPC       IPC Service (Samba 4.19.5)
SMB1 disabled -- no workgroup available

Значення: Ви домовились про SMB3 і SMB1 вимкнено (добре). Якщо сервер дозволяє лише SMB1, спочатку виправте це.
Рішення: Якщо SMB3 працює по IP, але не по хостнейму — повертаємось до проблем DNS/SPN/DFS.

Завдання 8: Переглянути активні SMB‑сесії на Windows‑клієнті

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,NumOpens,ContinuouslyAvailable"
ServerName ShareName Dialect NumOpens ContinuouslyAvailable
---------- --------- ------- -------- ---------------------
10.60.12.25 projects 3.1.1   12       False

Значення: Діалект — SMB 3.1.1. Якщо діалект нижчий, ніж очікується, продуктивність і стійкість можуть погіршитися.
Рішення: Якщо бачите повторні перепідключення або скидання NumOpens, корелюйте з логами VPN і захопленнями пакетів.

Завдання 9: Знайти розриви і перепідключення у логах Windows SMB‑клієнта

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-SMBClient/Connectivity' -MaxEvents 5 | Format-Table TimeCreated,Id,LevelDisplayName -Auto"
TimeCreated            Id LevelDisplayName
-----------            -- ----------------
12/28/2025 10:14:22  308 Warning
12/28/2025 10:13:57  310 Warning
12/28/2025 10:13:41  320 Error

Значення: Попередження/помилки в Connectivity часто співпадають з флапами шляху.
Рішення: Якщо це корелює з роумінгом Wi‑Fi або переймовами VPN, спочатку вирішіть проблему зі станом мережі.

Завдання 10: Захопити ретрансмісії й скидання під час копіювання (Linux tcpdump)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.60.12.25 and port 445 -vv
tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:15:01.112233 IP 10.60.0.14.51422 > 10.60.12.25.445: Flags [P.], seq 129:1189, ack 774, win 501, length 1060
10:15:01.342190 IP 10.60.0.14.51422 > 10.60.12.25.445: Flags [P.], seq 129:1189, ack 774, win 501, length 1060 (retransmission)
10:15:02.001005 IP 10.60.12.25.445 > 10.60.0.14.51422: Flags [R], seq 774, win 0, length 0

Значення: Ретрансляції, за якими йде RST, пахнуть втратою пакетів, проблемами MTU або middlebox, що вбиває стан.
Рішення: Якщо під навантаженням зростають ретрансляції, пріоритезуйте MTU/MSS та розслідування втрат/джиттера. Якщо RST з’являється після простою — першим пріоритетом є таймаути NAT/keepalive.

Завдання 11: Виміряти path MTU з встановленим DF (Linux ping)

cr0x@server:~$ ping -c 3 -M do -s 1360 10.60.12.25
PING 10.60.12.25 (10.60.12.25) 1360(1388) bytes of data.
1368 bytes from 10.60.12.25: icmp_seq=1 ttl=63 time=38.1 ms
1368 bytes from 10.60.12.25: icmp_seq=2 ttl=63 time=37.5 ms
1368 bytes from 10.60.12.25: icmp_seq=3 ttl=63 time=37.9 ms

--- 10.60.12.25 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 37.5/37.8/38.1/0.2 ms

Значення: 1360‑байтний payload з DF працює. Збільшуйте доти, доки не упадете, щоб знайти межу.
Якщо бачите повідомлення «Frag needed», PMTUD працює; якщо просто таймаут — щось блокує ICMP.
Рішення: Якщо MTU нижчий за очікуване, обмежте MSS або зменшіть MTU тунелю.

Завдання 12: Перевірити MTU інтерфейсу і MTU пристрою VPN (Linux)

cr0x@server:~$ ip link show dev wg0
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Значення: Типовий MTU WireGuard 1420. Якщо ви робите іншу інкапсуляцію (WG через UDP через щось ще),
1420 може бути все одно надто велике.
Рішення: Якщо path MTU тести показують падіння вище ~1360, зменшіть MTU інтерфейсу (наприклад 1380/1360) або обмежте MSS на краю.

Завдання 13: Застосувати TCP MSS clamp на Linux (edge firewall) і підтвердити лічильники

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -L FORWARD -v -n | head
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in  out  source      destination
   14   840 TCPMSS     tcp  --  *   wg0  0.0.0.0/0   0.0.0.0/0   tcp flags:0x02/0x02 TCPMSS clamp to PMTU

Значення: Пакети потрапляють у правило (лічильник pkts зростає). Це те, що потрібно.
Рішення: Якщо клімпування стабілізує SMB — залиште і документуйте. Якщо ні — переходьте до втрат/джиттера/таймаутів NAT.

Завдання 14: Перевірити час хендшейку WireGuard (на боці сервера)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 0aBc...redacted
  listening port: 51820

peer: 7XyZ...redacted
  endpoint: 203.0.113.44:54321
  allowed ips: 10.60.0.14/32
  latest handshake: 1 minute, 12 seconds ago
  transfer: 1.82 GiB received, 2.10 GiB sent

Значення: Якщо «latest handshake» застарілий під час активної сесії, відбувається руйнування UDP‑доступності.
Рішення: Встановіть PersistentKeepalive на клієнтах за NAT; налаштуйте таймаути фаєрволу.

Завдання 15: Підтвердити, що SMB‑сервер слухає й не зависає (Linux Samba‑сервер)

cr0x@server:~$ sudo ss -ltnp | grep ':445 '
LISTEN 0      128          0.0.0.0:445        0.0.0.0:*    users:(("smbd",pid=1214,fd=45))

Значення: smbd слухає. Якщо його немає — проблема на боці сервера: стан служби або правила прив’язки.
Рішення: Якщо слухає — перевірте логи smbd і навантаження системи.

Завдання 16: Перевірити стан Samba і застряглі процеси

cr0x@server:~$ sudo systemctl status smbd --no-pager
● smbd.service - Samba SMB Daemon
     Loaded: loaded (/lib/systemd/system/smbd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-12-28 09:12:06 UTC; 1h 3min ago
       Docs: man:smbd(8)
   Main PID: 1214 (smbd)
     Status: "smbd: ready to serve connections..."
      Tasks: 5 (limit: 18972)
     Memory: 92.5M
        CPU: 3min 12s

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

Завдання 17: Виміряти затримку диска на сервері (Linux)

cr0x@server:~$ iostat -x 1 3
Linux 6.8.0 (nas01)  12/28/2025  _x86_64_ (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4.31    0.00    2.14    7.55    0.00   86.00

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1          85.0    40.0  6120.0  3200.0   2.10   0.22  2.8

Значення: await низький; диск не є вузьким місцем.
Якщо await — десятки/сотні мс під навантаженням, клієнти можуть тайм-аутитись і перепідключатись.
Рішення: Якщо латентність зберігання погана, виправляйте сторедж (глибина черги, конфлікт доступу, відмовні диски, насичення пулу) перед тим, як звинувачувати VPN.

Завдання 18: Перевірити поведінку Kerberos vs NTLM (Windows‑клієнт)

cr0x@server:~$ powershell -NoProfile -Command "klist"
Current LogonId is 0:0x3e7

Cached Tickets: (3)
#0>     Client: alice @ CORP.LOCAL
        Server: krbtgt/CORP.LOCAL @ CORP.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x60a10000 -> forwardable renewable initial pre_authent name_canonicalize

Значення: Kerberos‑квитки присутні. Якщо доступ до шару не працює тільки по хостнейму, але працює по IP, в грі можуть бути SPN і Kerberos.
Рішення: Підтвердіть коректні SPN для імені файлового сервера і переконайтесь, що VPN‑DNS вказує на контролери домену.

Налаштування мережі, що припиняють розриви (MTU, MSS, NAT, роумінг)

Виберіть нудний MTU і дотримуйтеся його

Інкапсуляція VPN зменшує ефективний MTU. Потім хтось накладає VPN поверх VPN, або підключає PPPoE, або ви працюєте через мобільний хотспот.
Якщо ви не контролюєте MTU, рано чи пізно пройдеться шлях, що безшумно скидатиме великі пакети.

Мій упереджений підхід: якщо ви не можете гарантувати PMTUD по всьому шляху, клімпуйте MSS на краю VPN. Це не гламурно, але запобігає класу інцидентів «великий запис вбиває сесію».
На WireGuard зниження MTU інтерфейсу теж ефективне, але клімпування допомагає, коли клієнти дуже різняться.

Не блокувати ICMP, ніби це 2004 рік

ICMP «fragmentation needed» — частина того, як інтернет залишається функціональним. Блокування його змушує вгадувати MTU і надіятися.
Якщо безпека наполягає, ви все одно можете клімпувати MSS — але розумійте, що це операційний борг.

Ставтеся до NAT як до ворога (тому що він такий)

Якщо VPN на базі UDP, встановіть keepalives для клієнтів за NAT. У WireGuard є PersistentKeepalive не просто так.
OpenVPN має опції keepalive теж. IPsec NAT‑T часто потребує налаштувань DPD.

Симптоми, що кричать про таймаут NAT: падіння після передбачуваного періоду простою, негайне відновлення після перепідключення, і відмови переважно в «гостьових мережах» або на мобільних.

Роумінг і сон: трактуйте як роз’єднання, а не як іскру

Ноутбуки засинають. Wi‑Fi роумиться. IP‑адреси змінюються. SMB‑сесії не люблять це.
Якщо користувачі мобільні, прагніть до:

• VPN, що швидко перепідключається і коректно переукладає ключі
• Keepalive, налаштований для NAT
• Стабільний DNS і маршрути після перепідключення
• Функції SMB як durable handles там, де доступно (залежить від сервера)

Уникайте split‑tunneling для файлових шарів, якщо не дисципліновані

Split‑tunnel — це політичне рішення під виглядом мережевого. Воно може бути прийнятним, але тільки якщо:
діапазон IP для SMB чіткий і стабільний, DFS‑перенаправлення під контролем, а DNS — split‑horizon.
Інакше ви отримаєте найгірший клас інцидентів: періодичні, специфічні для користувача і неможливі відтворити з вашого робочого місця.

Жарт №2: Split‑tunneling як замовити «напівгостре» у ресторані — кожен інтерпретує по‑своєму, і ви пошкодуєте потім.

Налаштування SMB/Samba, що зменшують тривоги

Не «оптимізуйте» шляхом зниження безпеки протоколу

Вимикати підпис або шифрування, щоб SMB «краще працював через VPN», часто — пастка. Ви, можливо, зменшите навантаження CPU.
Але ви також змінюєте поведінку при відмовах, створюєте проблеми відповідності й іноді погіршуєте перепідключення, змінюючи шляхи автентифікації.
Спочатку налаштуйте мережу, потім вирішіть, чи дійсно крипто‑накладні витрати — ваш вузький пляшок.

Віддавайте перевагу SMB 3.1.1, вимикайте SMB1 скрізь

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

Будьте обережні з SMB Multichannel через VPN

SMB Multichannel може відкрити кілька TCP‑з’єднань через кілька NIC. Через VPN клієнти з кількома інтерфейсами можуть робити дивні речі:
один канал йде через тунель, інший пробує іти напряму — і ви отримуєте застої та шторм перепідключень.

Якщо multichannel спричиняє нестабільність, вимкніть його на клієнтах або серверах контрольовано.
Але не робіть цього першим кроком. Доведіть його присутність через інспекцію SMB‑з’єднань і захоплення пакетів.

Особливості Samba: ведіть логи корисними, а не шумними

У Samba ввімкніть стільки логування, щоб можна було корелювати розриви, помилки автентифікації та переговори підпису/шифрування.
Але не ставте debug рівень 10 у проді під час робочих годин, якщо вам не до вподоби заповнені диски і пропущені реальні інциденти.

Розумійте робоче навантаження: Office‑документи vs медіа‑файли vs артефакти збірки

Біль SMB формується характером навантаження. Велике послідовне копіювання чутливе до MTU і пропускної здатності.
Папка з великою кількістю дрібних файлів чутлива до затримки. Office‑документи — метадані й блокування.

Якщо користувачі скаржаться «відкриття папки займає 30 секунд», але «копіювання одного великого файла ок», це латентність + балакучі операції, а не пропускна здатність.
Це вказує на RTT/jitter VPN, затримки DNS і накладні витрати підпису SMB — не на пропускний здатність диска.

Три корпоративні короткі історії (як команди реально обпікаються)

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

Середня компанія розгорнула новий VPN‑клієнт. Пілотна група звітувала про успіх: мережеві диски працювали, перегляд файлів був нормальний,
і черга техпідтримки не виросла. Роллаут накрив всю компанію в понеділок.

У вівторок фінансисти почали отримувати помилки «шлях мережі не знайдено» приблизно о обіді. Інженери — ні.
Перше припущення було передбачуване: «Файловий сервер перевантажений». Команда додала CPU в VM і перемістила її на швидший сторедж.
Нічого не змінилося. Помилки продовжували з’являтися, переважно у фінансистів і HR.

Друге припущення було тонше: «Якщо VPN підключено — DNS правильний». Не було.
VPN поширював список DNS‑серверів, але Windows у деяких клієнтів тримав Wi‑Fi DNS вище за пріоритетом через метрики інтерфейсів.
Тому користувачі резольвили DFS‑простір у таргет, недосяжний через split‑tunnel, періодично.

Виправлення не вимагало потужності. Воно потребувало контролю маршрутів і імен: скоригували метрики інтерфейсів, забезпечили split‑DNS і зафіксували вибір DFS‑цілей для VPN‑клієнтів.
«Нестабільність сервера» зникла.
Постмортем був короткий і болючий: їхнє припущення «підключено означає правильно маршрутизовано» було хибним.

Коротка історія 2: Оптимізація, що відкотилася

Інша організація мала хронічну повільність SMB через IPsec VPN. Інженер вирішив «оптимізувати», збільшивши MTU тунелю
і вимкнувши MSS‑клімпування. Ідея: менше пакетів — краще. В лабораторії це працювало.

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

Захоплення пакетів показало справжнє: великі TCP‑сегменти чорніли десь між ISP і IPsec‑шлюзом.
ICMP «frag needed» не доходив назад (фільтрований middlebox), тож PMTUD не рятував.
Збільшений MTU підвищив частоту надвеликих сегментів, перетворивши рідкісний випадок у щоденний.

Відкат до консервативного MTU і MSS‑клімпування виправив проблему миттєво. Продуктивність навіть покращилася — не тому, що MTU «швидше»,
а тому, що ретрансляцій стало менше. Реальний світ — не чиста лабораторія.

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

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

У них був стандартний рунбук: перевірити DNS через резолвери VPN, підтвердити метрики маршрутів, виконати MTU DF‑ping тест
і перевірити логи підключення SMB. Нічого фантастичного. Просто послідовно.

Одного дня скарги «шлях мережі не знайдено» різко зросли після апгрейду фаєрвола. Рунбук знайшов причину за хвилини:
ICMP type 3 code 4 (fragmentation needed) блокувався новою політикою. Path MTU discovery зламався. Великі SMB‑записи перестали працювати.

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

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

«Шлях мережі не знайдено» з’являється тільки після копіювання великих файлів

Корінь: MTU‑чорна діра / PMTUD‑відмова; надвеликі пакети відкидаються; TCP зупиняється, потім скидається.

Виправлення: Клімпуйте MSS на краю VPN або зменште MTU тунелю; дозволіть ICMP fragmentation‑needed; перевірте DF‑ping і захоплення пакетів.

Мапований диск перепідключається повторно, здебільшого після періодів бездіяльності

Корінь: Таймаут NAT/фаєрволу, що видаляє UDP‑mapping або TCP‑стан; keepalive VPN надто рідкісний.

Виправлення: Налаштуйте VPN keepalive (WireGuard PersistentKeepalive; OpenVPN keepalive); збільште час життя стану на краєвих фаєрволах, де можливо.

Працює по IP, не працює по хостнейму (або DFS‑шляху)

Корінь: Помилка split‑horizon DNS, неправильний порядок суфіксів, або DFS‑реферальності вказують недосяжні таргети; іноді — невідповідність SPN Kerberos.

Виправлення: Виправте DNS для VPN, забезпечте доступність DC, перевірте SPN, контролюйте DFS‑реферали для VPN‑клієнтів.

Лише деякі користувачі падають, і це залежить від місцезнаходження

Корінь: Метрики маршрутів, витоки split‑tunnel, локальний DNS клієнта або особливості MTU у провайдера.

Виправлення: Забезпечте однакову конфігурацію клієнтів (маршрути, DNS, метрики інтерфейсів) і застосуйте MSS‑клімпування в сталому місці.

Відкриття папок повільне; копіювання одного великого файла нормальне

Корінь: Затримка і балакучі операції SMB; іноді антивірус або накладні витрати підпису.

Виправлення: Покращіть RTT/jitter (кращі точки присутності VPN), перегляньте накладні витрати підпису/шифрування на CPU, розгляньте перенесення чутливих робочих процесів з SMB.

Випадкові розриви під час роумінгу Wi‑Fi або сну/пробудження ноутбука

Корінь: Скидання транспорту VPN; зміни IP; застарілі маршрути; SMB‑сесія не переживає мережеві переходи.

Виправлення: Використовуйте VPN‑клієнт з швидким перепідключенням, налаштуйте keepalive і розгляньте «always‑on» VPN; навчіть користувачів, що сон — це роз’єднання.

SMB працює, але продуктивність жахлива після повсюдного ввімкнення шифрування

Корінь: CPU‑вузьке місце на клієнті або сервері через шифрування/підпис; ускладнюється великою затримкою.

Виправлення: Виміряйте CPU, підтвердіть наявність AES‑NI/апаратного прискорення, масштабируйте файлові сервери або вибірково вмикайте шифрування за зонами ризику (після оцінки ризиків).

Шторм розривів, коли клієнти мають кілька інтерфейсів

Корінь: SMB Multichannel намагається використовувати шляхи, що не узгоджені через VPN; асиметричний маршрут.

Виправлення: Підтвердіть через інспекцію SMB‑з’єднань; вимкніть multichannel, якщо він спричиняє нестабільність; забезпечте, щоб усі SMB‑шляхи залишались в тунелі.

Чеклісти / покроковий план

Покроково: стабілізувати SMB через VPN у продуктиві

1. Визначте ціль: перелік файлових серверів, DFS‑просторів, підмереж і чи дозволено split‑tunnel.
   Якщо ви не можете це перелічити — ви не зможете це правильно маршрутизувати.
2. Зробіть DNS детермінованим для VPN‑клієнтів: резолвери, що надає VPN, правильні суфікси і сталий результат.
   Тестуйте як хостнейм, так і DFS‑шлях.
3. Зробіть маршрути детермінованими: явні маршрути для підмереж SMB через VPN; перевірте метрики, щоб маршрут VPN перемагав.
4. Виправте MTU нудним способом: дозвольте PMTUD (ICMP frag‑needed) або клімпуйте TCP MSS на краю VPN. Підтвердіть DF‑ping тестами.
5. Встановіть keepalive для клієнтів за NAT: оберіть інтервал, що переживе типові таймаути NAT (часто 20–30 сек для впертих мереж).
6. Інструментуйте перед налаштуванням SMB: збирайте логи підключень SMB клієнта, логи VPN і захоплення пакетів під час відтворення.
7. Перевірте здоров’я сервера: CPU, пам’ять, затримки диска і стабільність служби SMB. Виправляйте реальні вузькі місця.
8. Контролюйте DFS‑реферали: забезпечте, щоб VPN‑клієнти отримували referrals до досяжних таргетів, бажано в тій же зоні мережі.
9. Оцініть налаштування безпеки SMB на підставі даних: зберігайте підпис/шифрування, поки не доведете, що CPU — вузьке місце і є погодження з безпекою.
10. Розгортайте зміни обережно: канарна група, вимірні критерії успіху (рівень розривів, кількість перепідключень, відсоток успішних копій), план відкату.

Чекліст: що захоплювати під час реального інциденту

• IP клієнта, ім’я VPN‑інтерфейсу і endpoint тунелю
• Резольвені IP для імені шару і DFS‑простору у час збоїв
• Знімок таблиці маршрутів (клієнт) і політик/маршрутів, що надає VPN
• Результати MTU‑тесту (найбільший DF‑ping, що працює)
• Захоплення пакетів навколо моменту відмови (RST? ретрансмісії?)
• Події Windows SMBClient Connectivity або логи Samba у час інциденту
• Метрики CPU сервера і затримки диска у вікні інциденту

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

1) Чому SMB виглядає нормально деякий час, а потім падає?

Тому що багато відмов базуються на таймерах (NAT/фаєрволи) або подіях (роумінг Wi‑Fi, перейом VPN, сон ноутбука).
SMB — станозалежний; коли підлягаючий стан зникає, наступна операція викликає помилку.

2) Чи завжди «шлях мережі не знайдено» — це проблема DNS?

Ні. Часто це DNS, але також може бути вибір маршруту, TCP‑скидання або блокування порту 445.
Розглядайте як «ім’я/маршрут/транспорт», доки не доведете інакше.

3) Чи варто взагалі використовувати SMB через VPN?

Якщо треба підтримувати спадщину — так, але тримайте очікування реалістичними.
Для роумінгових користувачів розгляньте перенесення колаборації на сервіси, призначені для переривчастого зв’язку.
SMB залишайте для робочих навантажень, що цього дійсно потребують.

4) Який MTU слід встановити?

Універсально правильного числа немає. Виміряйте path MTU (DF‑ping) і оберіть консервативне значення.
Якщо не можете гарантувати дію ICMP, клімпуйте MSS і тримайте MTU тунелю скромним.

5) Чи спричиняє шифрування SMB розриви?

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

6) Чому працює по IP, але не по імені?

Доступ по імені запускає DNS‑резолюцію, перевірки SPN/Kerberos і поведінку DFS. Доступ по IP обходить частину цих кроків.
Ця різниця — діагностичний подарунок: зосередьтесь на DNS і ідентичності (Kerberos/SPN), а не на втраті пакетів.

7) Чи варто вимикати SMB Multichannel через VPN?

Тільки якщо доведете, що воно створює нестабільні або асиметричні шляхи.
Multichannel чудово працює в стабільних мережах. Через VPN з кількома інтерфейсами клієнта це може бути хаосом.
Спочатку проведіть валідацію через інспекцію з’єднань SMB.

8) Яка найцінніша зміна для стабільності?

Якщо ви страждаєте від випадкових розривів: keepalive і гігієна MTU/MSS на краю VPN.
Ці дві речі усувають велику частину «таємничих відключень».

9) Чому відкриття папок відчувається гіршим, ніж копіювання файлів?

Перегляд папки запускає багато дрібних SMB‑операцій: метадані, open/close, перевірки атрибутів.
Великий RTT і джиттер множать цей біль. Великі послідовні передачі амортизують затримку краще.

10) Чи можна виправити це лише змінами реєстру Windows?

Іноді ви можете замаскувати симптоми. Але якщо мережа втрачає стан або чорні діри пакети, регістр SMB — лише відкладення проблеми.
Виправте транспорт спочатку.

Висновок: наступні кроки, які ви можете зробити цього тижня

SMB через VPN може бути стабільним, але лише якщо ви ставитеся до нього як до продакшн‑залежності, а не як до зручності.
Повторювані відмови — MTU‑чорні діри, таймаути NAT і дрейф split‑DNS/маршрутів — не містичні. Вони недовимірювані.

Практичні кроки:

1. Пройдіть швидкий план діагностики на одному постраждалому клієнті і захопіть докази (DNS, маршрут, TCP‑доступність, MTU DF‑тести).
2. Впровадьте MSS‑клімпування (або консервативний MTU тунелю) на VPN‑зачепі і перевірте великою копією файлу.
3. Увімкніть і налаштуйте VPN keepalives для клієнтів за NAT; підтвердіть, що розриви після простою зникли.
4. Аудитуйте DFS‑реферали і split‑tunnel маршрути, щоб «ресурс» завжди означав один досяжний таргет.
5. Створіть невеликий рунбук і вимагайте його в тикетах: ні логів — ні припущень.

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